5 Whys — ретроспектива-расследование: от симптома к корневой причине за пять шагов

Если Plus / Delta и Start, Stop, Continue — это форматы для регулярного ретро на спринт, то 5 Whys — другой жанр: это не «как прошёл цикл», а «почему случилась эта конкретная проблема». Формат не для еженедельной встречи команды, а для разбора инцидента, повторяющегося бага или сорванной цели спринта, когда «починили и снова сломалось» уже надоело.

Откуда взялся метод

5 Whys придумал Тайити Оно — инженер и архитектор Toyota Production System в 1950‑е. Метод закрепился как часть Toyota Way и до сих пор обязателен в lean‑производстве. Сам Оно приводил пример: Остановился станок. «Почему?» — перегорел предохранитель из‑за перегрузки. «Почему?» — подшипник плохо смазан. «Почему?» — насос плохо качает масло. «Почему?» — на валу насоса износ. «Почему?» — в насос попадает стружка из‑за отсутствия фильтра. Корневая причина отсутствие фильтра, а не «перегоревший предохранитель» (просто замена не решила бы корневую причину).

Главная идея метода не остановиться на первом «потому что», за которое цепляется глаз. Первый ответ почти всегда про симптом или последствие, а не про причину. Пять уровней «почему?» эмпирическое правило, проверенное десятилетиями. Для большинства технических и процессных проблем именно на 4–5 шаге появляется системная причина, на которую можно повлиять изменением процесса, инструмента или соглашения, а не «будем внимательнее в следующий раз».

Пять колонок шаблона

Why 1 — симптом, что произошло

Первая колонка — карточка с самой проблемой в формулировке наблюдаемого факта: «прод упал в пятницу в 18:45», «оплата висит у клиента 12 минут после нажатия кнопки», «спринт закрыли с 40% невыполненных задач». Без оценок («плохо», «ужасно»), без виноватых («Вася не успел»), без предположений о причине («наверное, из‑за релиза»). Просто факт. Эта карточка задаёт рамку расследования. Всё, что появится дальше, должно быть связано с ней цепочкой «потому что».

Why 2 — первый «почему?»

Команда задаёт вопрос «почему это произошло?» и кладёт ответ в следующую колонку. Это самый опасный уровень. На нём проще всего сбиться в сторону симптома («потому что у Васи не хватило времени») или в сторону предположения («наверное, в коде была гонка»). Хороший ответ описывает наблюдаемую причину — то, что команда видела или может проверить логами: «релиз ушёл без миграции БД», «новый клиент превысил лимит на запросах», «таск был оценён в 3 SP, а оказался 13».

Why 3 и Why 4 — глубже на уровень

Третий и четвёртый «почему?» — те самые, где у команды обычно появляется ощущение «а‑а, вот оно». На этих уровнях обычно вылезают процессные пробелы: «у нас нет автоматической проверки миграций в CI», «алерт на превышение лимита приходит постфактум, а не до», «оценка задач делается одним человеком без второго мнения». Если на этом уровне команда упирается в «ну, у нас просто нет такого процесса» — это уже почти корневая причина, осталось дожать до конкретного действия.

Why 5 — корневая причина

Пятая колонка — та самая, ради которой формат и затевался. Хорошая корневая причина системная. Касается процесса, инструмента или договорённости команды. То, что можно изменить. «Васе не хватило опыта» — это не корневая причина, это симптом отсутствия онбординга или ревью. «Релиз был в пятницу вечером» — не корневая причина, а вопрос политики деплоев. На пятой колонке команда формулирует не предположение, а конкретное действие на устранение системной причины: «вводим обязательный smoke‑тест миграций в CI», «настраиваем алерт на 80% от лимита, а не на 100%», «деплои в пятницу после 16:00 запрещены без согласования с лидом».

Когда стоит выбрать этот формат

• Случился инцидент (упал прод, потеряли клиента, поехали финансовые показатели) и нужен разбор «почему», а не «как мы себя чувствуем по этому поводу».
• Проблема повторяется («этот баг возвращается третий спринт», «оценка задач промахивается в 2 раза стабильно», «накатывать релизы стало больно»). Регулярное ретро не вытаскивает причину и нужен фокус.
• Сорвана цель спринта, вместо общего разбора спринта возьмите конкретный сорванный goal и пройдите по 5 Whys — это часто эффективнее, чем «обсудим всё подряд».
• Готовится крупный пост‑мортем (postmortem). 5 Whys удобно использовать как первый шаг blameless‑постмортема для сбора корневых причин не превращая встречу в поиск виноватых.
• Спор «надо чинить» против «надо переписывать». 5 Whys показывает, что реально чинит проблему, а что только отложит её до следующего инцидента.

Как провести расследование за 45 минут

1. Подготовка (3 минуты)

Откройте шаблон 5 Whys — пять колонок уже настроены. Запишите в название доски формулировку проблемы как наблюдаемого факта. Пригласите тех, кто реально видел проблему или участвовал в инциденте (продакт, разработчики, девопс, поддержка) всех, кто релевантен. Если расследование закрытое отключите гостевой доступ в настройках доски.

2. Сверьте формулировку проблемы (5 минут)

Перед началом прочитайте проблему вслух и убедитесь, что вся команда понимает её одинаково. Это критично. На разных уровнях «почему?» легко уехать в сторону, если стартовая точка размыта. Если кто‑то из команды по‑другому видит исходный факт обсудите это сейчас, а не на третьем шаге. Положите первую карточку в колонку «Why 1» — это и есть якорь расследования.

3. Пять «почему?» — шаг за шагом (25–30 минут)

На каждом уровне задавайте один вопрос: «почему это произошло?» и кладите ответ в следующую колонку. Важное правило: переход на следующий уровень только после согласия команды, что текущий ответ действительно ближайшая причина, а не другой симптом. Если ответов несколько (а они часто есть), то кладите все карточки и продолжайте «почему?» от каждой. Доска может разветвляться — это нормально. Расследование живое и одна проблема часто упирается в несколько корней.

4. Выделите корневые причины (5–7 минут)

К концу пятого уровня посмотрите, какие карточки в колонке «Why 5» команда считает системными (теми, на которые можно повлиять). Их обычно 1–3 штуки. Закрепите эти карточки голосованием (включите голоса на доске) или просто отметьте их визуально. Если в колонке «Why 5» вместо процесса всё ещё человек попросите команду задать «почему?» ещё раз. Например: «почему у Васи не хватило опыта?» обычно даёт «потому что в команде нет онбординга для новых разработчиков», а это уже системная причина.

5. Сформулируйте действия (5 минут)

Для каждой выбранной корневой причины нужно сформулировать конкретное действие с владельцем и сроком. Используйте structured action items RetroPoint. Они не теряются после ретро, привязываются к ответственному и при необходимости прокидываются в 1‑2‑1‑комнату. Закройте встречу проговариванием действий вслух — это страховка от «забыли, кто что делает».

Типичные ловушки

• Поиск виноватых. Метод заточен под blameless‑разбор. Вопросы «почему?» направлены на процесс, а не на человека. Если на уровнях 2–3 появляются имена и обвинения — это сигнал переформулировать ответ в процессную причину. «Вася сломал прод» → «у нас нет процедуры code review для миграций».
• Останавливаемся на третьем «почему?». Большинство команд бросает расследование, когда первый правдоподобный ответ уже найден. Это всегда искушение. Третий уровень обычно звучит убедительно. Дожимайте до пятого, именно там обычно лежит то, что можно реально починить.
• Один человек ведёт расследование. 5 Whys работает только в группе. Один взгляд легко уезжает в свою привычную интерпретацию. Если у вас одиночное расследование, то позовите хотя бы одного коллегу для второго мнения.
• Уходит в гипотезы. На каждом уровне «почему?» должно быть основано на наблюдаемом факте (лог, метрика, переписка, документ, прямое свидетельство). Если ответ звучит как «наверное» — это сигнал собрать данные, а не идти дальше.
• 5 уровней — догма. На практике корневая причина иногда появляется на 3‑м уровне, иногда — на 7‑м. «5» — это эмпирическое правило, а не закон. Дойдите до уровня, где причина системная и на неё можно повлиять.
• Корневая причина без действия. Найти причину и не починить — это потеря смысла встречи. Не закрывайте ретро без 1–3 конкретных действий с ответственными.

Чем отличается от других форматов

От Start, Stop, Continue и Plus / Delta формат отличается принципиально - это не ретро на цикл, а разбор конкретной проблемы. На обычном ретро 5 Whys плохо работает, так как слишком узкий фокус. На разборе инцидента наоборот, узость фокуса и есть инструмент.

От Mad, Sad, Glad тем, что не затрагивает эмоции. Если в команде есть напряжение по поводу инцидента и его сначала надо проговорить, то лучше провести Mad / Sad / Glad как разогрев и только потом запускать 5 Whys. Иначе разбор уйдёт в выяснение отношений уже на втором «почему?».

От Sailboat и Three Little Pigs масштабом разбора. Парусник и три поросёнка смотрят на устойчивость практик в целом, а 5 Whys копает в одну точку. Если на паруснике обнаружились повторяющиеся «якоря» — возьмите самый тяжёлый из них и проведите по нему 5 Whys отдельно.

От рыбьей кости Исикавы (fishbone diagram) простотой. Fishbone хорош на сложных производственных проблемах с десятками возможных причин в разных категориях. 5 Whys на проблемах, где одна цепочка причинно‑следственных связей. В IT и продуктовых командах 5 Whys выручает чаще так как быстрее и не требует строить категории заранее.

Что почитать ещё

5 Whys хорошо ложится в практику blameless‑постмортемов (культура, в которой инциденты разбирают без поиска виноватых, а с фокусом на улучшение системы). Подробнее об этом подходе можно прочитать у Джона Олспоу в статье «Blameless PostMortems and a Just Culture» на блоге Etsy (есть в архивах) и у SRE‑команды Google в книге «Site Reliability Engineering» (доступна бесплатно онлайн).

Самая короткая и точная книга по самому методу — «Toyota Production System: Beyond Large‑Scale Production» Тайити Оно, 1988. В ней нет ни одной формулы, зато есть пара десятков примеров расследований, на которых формат и обкатывался. На русском есть издание «Бережливое производство Toyota».

Попробуйте на ближайшем инциденте

Откройте страницу техники 5 Whys и нажмите «Создать доску по этому шаблону». Пять колонок уже настроены, цвета подобраны от тревожного «симптом» к спокойному «корень». Если хочется сравнить с другими форматами, загляните в каталог ретроспективных техник или к разбору Start, Stop, Continue. Он короче, но не про инциденты. А если RetroPoint для вас в новинку, то начните с обзорного материала о сервисе.