5 почему в разработке: как докопаться до корневой причины

Проблемы в разработке повторяются. Баги, дедлайны, инциденты в проде. Мы чиним симптомы, а через месяц всё повторяется. Метод «5 почему» помогает найти корневую причину и закрыть проблему навсегда.

Что такое «5 почему»

Задайте вопрос «почему?» пять раз подряд. Каждый ответ становится новой проблемой, к которой вы снова задаёте вопрос. Последний ответ — корневая причина.

Технику придумал Сакити Тойода, основатель Toyota. Она стала частью производственной системы компании. Тайити Оно, создатель производственной системы Toyota, описал метод так: «основа научного подхода Toyota. При задании вопроса почему пять раз определяется характер проблемы, решение становится понятным».

Метод прижился за пределами автопрома. Сейчас используется в кайдзен, бережливом производстве, шести сигмах. В некоторых компаниях применяют вариации. Например, в Semco используют технику «трёх почему» для принятия решений.

Суть проста: люди борются с последствиями, а не причинами. Звучит знакомо для IT? Инциденты, постмортемы, баги. Мы часто лечим симптомы вместо первоисточника.

Пример из разработки

Сервис стал отдавать ответы медленно. 99-й перцентиль вырос с 100мс до 5 секунд.

1. Почему выросла 99-я перцентиль?
   Медленные запросы к базе данных. По планам исполнения запросов видим full scan вместо использования индексов.
2. Почему запросы делают full scan?
   В запросах появилась выборка по новым полям, по которым нет индексов.
3. Почему нет индексов по новым полям?
   Последняя миграция добавила поля в таблицу, но не создала индексы.
4. Почему миграция без индексов прошла в прод?
   Код-ревью миграции смотрели только на корректность SQL, не на производительность. На stage не создавали нужной нагрузки для проверки.
5. Почему не смотрели на производительность?
   Нет чек-листа для ревью миграций. Не прикладываем план запроса. QA тестируют на корректность работы, но не на скорость.

Корневая причина: процесс ревью и тестирования миграций не включает проверку производительности.

Решение:

• добавить в чек-лист ревью: план запроса для новых полей
• настроить линтер для миграций с предупреждением об отсутствующих индексах
• провести обучение команды по анализу планов запросов
• расширить тест-кейсы у QA тестами на производительсность

Никогда не идите вслепую по пути «наказать QA» или «написать больше тестов». Взгляните в корень проблемы и улучшайте процесс в целом, а не отдельные аспекты работы.

Где применять в IT

Инциденты и постмортемы

Классический кейс. После инцидента команда пишет постмортем. Без метода «5 почему» получится: «разработчик ошибся, нужно быть внимательнее». С методом — найдёте проблему в процессах, мониторинге или архитектуре.

Пример:

1. Почему упал сервис?
   Containter был остановлен из-за OOM.
2. Почему OOM?
   Утечка памяти в новом функционале.
3. Почему утечка не обнаружилась?
   Нет лимитов на memory в staging, только в production.
4. Почему нет лимитов в staging?
   Когда настраивали окружение, не добавили, «чтобы не мешало разработке».
5. Почему решили не мешать?
   Был случай, когда жёсткие лимиты сломали локальную разработку. Решили убрать везде вместо того, чтобы разделить конфиги.

Корневая причина: нет разделения конфигов для staging и локальной разработки.

Решение: добавить лимиты в staging, оставить мягкие ограничения локально.

Код-ревью и техдолг

Почему код-ревью занимает три дня? Почему техдолг растёт? Почему разработчики не пишут документацию?

Пример:

1. Почему разработчики не пишут документацию к API?
   Нет времени, сроки горят.
2. Почему нет времени?
   Оценки задач не включают время на документацию.
3. Почему не включают?
   Product manager считает, что документация — это «не фича» и не приносит ценности.
4. Почему PM так считает?
   В компании нет метрик, которые связывают качество документации с онбордингом новых разработчиков или количеством вопросов в поддержку.
5. Почему нет метрик?
   Никто не предлагал измерять влияние документации.

Корневая причина: нет измеримого влияния документации на бизнес-метрики.

Решение: провести эксперимент — задокументировать один сервис и измерить время онбординга новичков.

Карьера и личная эффективность

Метод работает не только для команд. Применяйте его к себе.

Пример:

1. Почему я не успеваю учить новое?
   После работы нет сил.
2. Почему нет сил?
   Рабочий день длится 10-12 часов.
3. Почему так долго?
   Часто переключаюсь между задачами и не успеваю сфокусироваться.
4. Почему переключаюсь?
   Нет блока времени без встреч. Календарь разбит на 30-минутные слоты.
5. Почему так?
   Принимаю все приглашения на встречи без фильтрации.

Корневая причина: нет системы фильтрации встреч.

Решение:

• бронировать слот 2-3 часа в день в календаре для глубокой работы
• отключить не критичные уведомления
• совместно с командой улучшать процессы планирования и работы над задачами (т.к. скорее всего проблема у каждого участника команды)

Как не испортить метод

Ошибка 1. Искать виноватого

«Почему проект провалился? Потому что разработчик X плохо написал код». Тупик.

Правильные вопросы:

• Почему код прошёл ревью?
• Почему не было тестов?
• Почему архитектура позволила одному компоненту уронить всё?

Фокус на процессах, а не людях. Люди делают ошибки. Процессы должны их ловить.

Ошибка 2. Остановиться на симптоме

«Почему медленно работает API? Потому что нет кэша». Повесили кэш. Через месяц снова медленно, но в другом месте.

Нужно докопаться до архитектуры, выбора структуры базы данных, паттернов доступа к данным.

Ошибка 3. Использовать в одиночку

Один человек видит проблему со своей стороны. Соберите команду.

Разные роли видят по-разному:

• Разработчик скажет про код
• DevOps про инфраструктуру
• QA про тесты
• PM про требования

На постмортемы приглашайте всех причастных. Иначе получите однобокое решение.

Ошибка 4. Буквально следовать «5 вопросам»

Иногда достаточно трёх вопросов. Иногда нужно семь. Номер пять это ориентир, не догма.

Критерий остановки: ответ указывает на конкретное действие, которое вы можете выполнить. «Нужно быть внимательнее» не действие. «Нужно добавить автоматическую проверку в CI» действие.

Практический алгоритм

1. Сформулируйте проблему. Чётко, без эмоций. «Релизы откладываются» вместо «мы катастрофически не успеваем».
2. Соберите факты. Сколько раз? Когда? Какие метрики изменились? Без данных уйдёте в гипотезы.
3. Соберите команду. Разные роли дают разные перспективы.
4. Задавайте вопросы. Публично, на доске или в документе. Визуализируйте цепочку.
5. Проверяйте гипотезы. Каждый ответ это гипотеза. «Действительно ли QA был в отпуске? Проверим календарь».
6. Найдите действие. Корневая причина должна вести к конкретному изменению в процессе, системе или культуре.
7. Зафиксируйте результат. Добавьте в документацию, онбординг, чек-листы.

Пример шаблона для постмортема

Проблема: [описание]

1. Почему [проблема]?
   Ответ: [ответ1]

2. Почему [ответ1]?
   Ответ: [ответ2]

3. Почему [ответ2]?
   Ответ: [ответ3]

4. Почему [ответ3]?
   Ответ: [ответ4]

5. Почему [ответ4]?
   Ответ: [корневая причина]

Действие: [что конкретно меняем]
Ответственный: [кто]
Срок: [когда]

Ограничения метода

«5 почему» не работает для сложных системных проблем. Если проблема имеет несколько независимых причин, метод уведёт в одну ветку.

Когда использовать альтернативы:

• Проблема имеет несколько независимых причин
• Нужен анализ множества факторов одновременно
• Сложные системные взаимосвязи

Альтернативы:

• Диаграмма Исикавы (рыбья кость)
• Системный анализ
• Mind mapping

Для большинства задач в разработке метод работает отлично: инциденты, процессные проблемы, повторяющиеся баги. Он простой, быстрый и не требует специальных инструментов.

Итог

Метод «5 почему» это про культуру. Культуру не искать виноватых, а улучшать процессы. Культуру докапываться до сути, а не лечить симптомы.

В разработке это особенно важно. Системы становятся сложнее, команды растут. Без системного подхода к проблемам вы утоните в рутине, закрывая одни и те же инциденты раз за разом.

Начните с малого. На следующем постмортеме или ретро задайте вопрос «почему?» ещё раз. И ещё раз. Пока не найдёте причину, которую можно изменить действием.

Если же поиск причины затрагивает людей, важно не скатиться в обвинения. Читайте статью «Как давать негативную обратную связь».

Теги:

• management
• productivity