Метод «5 почему»: как докопаться до настоящей причины

Метод «5 почему» — способ исследовать причины проблемы: к каждому объяснению задают следующий вопрос «почему это произошло?». Так команда движется от наблюдаемого сбоя к условиям, которые можно изменить, чтобы снизить вероятность повторения.

Пять — ориентир, а не обязательное число вопросов. Иногда достаточно трёх переходов, иногда цепочка длиннее или разветвляется. Главное — проверять ответы фактами: последовательность убедительных предположений ещё не доказывает причинность.

Откуда появился метод и для чего его используют

Практика связана с производственной системой Toyota и работой Тайити Оно. В бережливом производстве вопросы помогают понять, почему возникло отклонение от нормальной работы, вместо постоянного устранения одного и того же симптома. Подробнее об этом подходе — в справочнике Lean Enterprise Institute.

Сегодня метод «5 почему» используют не только на производстве. Он подходит для разбора задержек релиза, повторных обращений клиентов, ошибок в документах и регулярных сбоев сервиса. Результат такого разбора — проверенная гипотеза и действие с владельцем, сроком и способом оценки эффекта. Само заполнение пяти карточек работу не улучшает.

Когда подходит метод «5 почему», а когда нужны другие инструменты

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

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

При аварии сначала восстановите работу и сохраните данные для расследования. Вопросы «почему» не заменяют диагностику, анализ журналов и эксперимент. Метод также не выбирает стратегию компании: он исследует причины уже наблюдаемого результата, а не доказывает, какое будущее решение окажется лучшим.

Как провести разбор за пять шагов

1. Зафиксируйте проблему без обвинений

Укажите, что произошло, где, когда и как часто. Вместо «тестировщик пропустил ошибку» запишите: «После релиза пользователь не смог завершить оплату в определённом браузере». Первое предложение заранее назначает виноватого. Второе оставляет открытыми версии о требованиях, тестовом окружении и изменениях зависимостей.

Договоритесь о границах разбора. Если обсуждаете один релиз, не переносите в эту же цепочку все накопленные претензии к работе команды. Рядом сохраните ссылки на задачу, временную шкалу и исходную метрику. Это общая точка отсчёта, к которой можно вернуться при споре.

2. Задайте первый вопрос «почему?»

Попросите участников назвать ближайшее объяснение события. Затем задавайте следующий вопрос именно к этому объяснению, а не заново ко всей проблеме. Проверка связности простая: прочитайте соседние карточки как предложение «Это произошло, потому что…». Если смысловой переход потерян, уточните формулировку.

Не подсказывайте желаемый ответ вопросом «Это ведь из-за нехватки людей?». Лучше спросить: «На каком этапе возникла очередь и что её удерживало?». У сотрудника, который выполняет работу, и у руководителя могут быть разные сведения. Сохраните обе версии до проверки.

3. Отделите факты от гипотез

Для каждого ответа укажите доказательство или следующую проверку. Подойдут история изменений, переписка, журнал событий, наблюдение за работой. «Все знают» и «кажется» — сигналы, что перед вами предположение. Пометьте его, назначьте владельца проверки и не продолжайте цепочку так, словно оно уже подтверждено.

Спросите, встречалась ли проблема без предполагаемой причины и была ли причина в случаях без проблемы. Это не универсальный тест причинности, но полезный способ обнаружить слишком простое объяснение. Если данных недостаточно, итогом встречи может стать план наблюдений, а не готовое решение.

4. Найдите условие, на которое можно повлиять

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

Не продолжайте вопросы до абстрактного «так устроен мир». Остановиться можно, когда понятен механизм, есть факты и конкретная мера. Если фактор внешний, например задержка поставщика, команда может управлять запасом времени или альтернативным маршрутом, даже если не способна устранить сам фактор.

5. Назначьте действие и проверку эффекта

Запишите, кто меняет процесс, к какой дате и какую метрику команда сравнит после изменения. Разделяйте временное исправление и предупреждение повторения. Перезапустить сервис — восстановить работу; изменить конфликтующее расписание задач и добавить контроль — проверить способ предотвратить следующий сбой.

Пример 1: сорван срок релиза

Учебная ситуация: выпуск перенесли с четверга на понедельник. Команда восстанавливает последовательность событий, а не оценивает старание участников. Возможная цепочка выглядит так:

1. Почему перенесли выпуск? Приёмка обнаружила несовместимость интеграции.
2. Почему несовместимость обнаружили только на приёмке? Раньше сценарий проверяли на заглушке.
3. Почему заглушка не воспроизводила поведение партнёра? Её контракт остался от предыдущей версии.
4. Почему контракт не обновили? Изменения партнёрского API не попадали в проверку зависимостей.
5. Почему проверки не было? В правилах подготовки релиза не был назначен владелец актуальности внешнего контракта.

Это гипотеза для исследования, а не готовый диагноз любого сорванного релиза. Сопоставьте даты изменения API, тестовые сценарии и версию заглушки. Если несовместимость возникла по другой причине, цепочку нужно пересобрать. Не подгоняйте документы под уже удобный вывод.

Возможная мера — назначить владельца контракта и добавить проверку совместимости перед приёмкой. На следующих выпусках команда отслеживает, сколько интеграционных дефектов обнаруживается поздно. Если показатель не изменился, возвращается к данным, а не объявляет метод неработающим после одной попытки.

Пример 2: жалобы клиентов на поддержку

Возьмём тот же сюжет, что в статье про диаграмму Исикавы: клиенты жалуются на работу поддержки. Сначала уточним результат: человек повторно обращается с тем же нерешённым вопросом. Случаи с новой темой в эту выборку не включаем.

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

Но повторное обращение может иметь и другую причину: клиент написал снова, потому что слишком долго ждал. Эта ветвь ведёт к очереди и распределению нагрузки, а не к полноте истории. Разместите её отдельно. Единственное действие «объединить каналы» не обязано устранить обе причины.

На доске с примерами можно рассмотреть обе ветви. Для собственного разбора возьмите обезличенные обращения за одинаковые периоды и отдельно оцените повторные контакты из-за неполного ответа и из-за ожидания. Так команда увидит, какую часть проблемы затрагивает изменение.

Пример 3: сервис сбоит раз в неделю

Учебный симптом: каждое воскресенье сервис отвечает медленнее обычного. Почему? Приложение ждёт доступ к базе. Почему? Длительная операция удерживает блокировку. Почему операция выполняется в этот момент? Еженедельный отчёт запускается одновременно с другой тяжёлой задачей. Почему расписания пересеклись? Их настраивали независимо и не проверяли совместную нагрузку.

На этом этапе не обязательно придумывать пятый ответ. Сначала сопоставьте временные метки, ожидания блокировок и расписание. Совпадение по времени само по себе недостаточно. Проверьте гипотезу в контролируемом окружении или согласованным изменением расписания и сравните длительность запросов.

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

Как сочетать «5 почему» и диаграмму Исикавы

Исикава помогает расширить набор возможных объяснений, а вопросы «почему» — углубить выбранную ветвь. Сначала соберите версии по категориям, затем выберите те, для которых есть наблюдения и доступные проверки. При необходимости вернитесь к карте и добавьте пропущенный фактор.

После подтверждения причины переходите к оптимизации бизнес-процесса: меняйте конкретное правило или передачу работы. Не выбирайте ветвь только потому, что решение по ней дешёвое или удобно руководителю. Сила объяснения определяется данными и механизмом, а не простотой красивой цепочки.

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

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

На доске оставьте четыре области: проблема, цепочки, доказательства, действия. Записывайте одну мысль на карточку и помечайте непроверенные версии словом «гипотеза». Начните с самостоятельных записей, чтобы первая уверенная реплика не задала ответ всей группе. Спорные объяснения сохраняйте рядом, пока не появятся данные.

Такой разбор можно включить в ретроспективу спринта, но не превращать всю встречу в расследование одного случая. Когда требуется дополнительная информация, договоритесь о коротком продолжении. В итоговой карточке должны остаться мера, владелец, срок и дата проверки результата.

Частые ошибки

• Искать виноватого. Вместо «сотрудник невнимателен» исследуйте, какая информация и какие проверки были доступны при выполнении работы.
• Останавливаться на симптоме. Замена детали или повторная отправка документа может быть необходима, но не объясняет, почему возник сбой.
• Задавать ровно пять вопросов. Количество шагов не заменяет доказательства и не делает последнюю карточку корневой причиной.
• Игнорировать ветвления. Несколько факторов могут действовать вместе; сохраняйте отдельные цепочки и их связи.
• Заканчивать обсуждением. Без владельца действия и даты проверки вывод остаётся предположением о будущем улучшении.

Перед закрытием разбора попросите участника, не писавшего цепочку, объяснить её своими словами. Если ему приходится додумывать переходы, уточните их. Сохраните и опровергнутые версии с краткой причиной отказа: на следующем похожем инциденте это поможет не начинать обсуждение с нуля.

Вопросы и ответы

Обязательно ли спрашивать «почему» пять раз?

Нет. Число вопросов зависит от проблемы и доступных фактов. Остановитесь на проверенном механизме, для которого можно выбрать действие, а не на заданном номере карточки.

Для чего используется метод «5 почему»?

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

Может ли быть несколько корневых причин?

Да. В таком случае стройте несколько ветвей и проверяйте их отдельно, включая возможное взаимодействие факторов.

Чем «5 почему» отличается от Исикавы?

Исикава собирает и группирует возможные причины. Последовательные вопросы «почему» помогают подробнее исследовать выбранную причинную цепочку.