После сбоя команда пишет в отчёте «человеческий фактор» или «недостаточная коммуникация». Через месяц сбой повторяется, потому что причину так и не нашли: описали поверхность. Метод «5 почему» нужен именно для этого: он заставляет спуститься от симптома к причине, которую можно устранить.

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

Что такое метод «5 почему» и где он применяется

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

Сегодня метод используют в производстве, ИТ-эксплуатации, управлении проектами и в разборе обращений клиентов. Он годится для проблем, у которых есть конкретный повторяющийся эффект: срыв срока, брак, инцидент, отток.

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

1. Сформулируйте проблему как факт. Что произошло, где, когда и насколько. «Релиз сорван на 9 дней» годится, «плохо работаем» не годится.
2. Спросите «почему?» и запишите ответ, подтверждённый данными. Ответ из серии «мне кажется» — гипотеза, её нужно проверить, а не записывать как причину.
3. Задайте тот же вопрос к ответу. Повторяйте, пока ответы остаются конкретными и проверяемыми.
4. Остановитесь на причине, которой можно управлять. Если дошли до «рынок изменился», вы вышли за пределы влияния: вернитесь на шаг назад.
5. Проверьте цепочку в обратную сторону. Читайте снизу вверх со словом «поэтому»: если логика рвётся, в цепочке пропущено звено.

Пример: сорванный релиз за пять вопросов

Условный пример для ИТ-команды. Проблема: релиз перенесли на 9 дней.

• Почему перенесли? Приёмка вернула сборку на доработку.
• Почему вернула? Нашли критичные ошибки в оплате.
• Почему ошибки дошли до приёмки? Для модуля оплаты не было автотестов.
• Почему не было автотестов? Их не заложили в оценку задачи.
• Почему не заложили? Требования к модулю менялись после оценки, и пересчёт не проводили.

Первопричина: нет процедуры пересчёта оценки при изменении требований. Корректирующая мера «добавить тестировщика» устранила бы симптом. Мера «пересчитывать оценку при каждом изменении требований» убирает причину.

Пять ошибок, из-за которых метод не работает

• Останавливаются на человеке. «Разработчик не проверил» — это не причина. Вопрос «почему система позволила это пропустить?» выводит на процесс.
• Отвечают предположениями. Без данных цепочка превращается в красивую, но ложную историю. К каждому ответу нужен источник.
• Идут по одной ветке. У проблемы часто две-три независимые причины. Если выбрать одну, остальные вернутся сбоем.
• Формулируют размыто. «Плохая коммуникация» нельзя ни проверить, ни устранить. Конкретика: «заказчик согласовывал изменения в личных сообщениях, а не в трекере».
• Не связывают меру с первопричиной. Меры на уровне симптома дают быстрый эффект и нулевой результат через месяц.

Как выглядит «5 почему» в ИТ, производстве и поддержке

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

• ИТ-эксплуатация. Сервис упал ночью. Почему? Закончилось место на диске. Почему? Логи не ротировались. Почему? Задача ротации не входила в шаблон развёртывания. Почему? Шаблон делали для тестовой среды и не обновили для продакшена. Мера: один шаблон для всех сред и проверка при каждом развёртывании.
• Производство. Брак на линии вырос. Почему? Деталь выходит за допуск. Почему? Изношен инструмент. Почему не заменили вовремя? Нет учёта наработки. Мера: счётчик наработки и порог замены.
• Поддержка клиентов. Клиенты повторно обращаются по одному вопросу. Почему? Ответ первой линии не решает проблему. Почему? В базе знаний устаревшая инструкция. Почему? За актуальность статей никто не отвечает. Мера: владелец у каждой статьи и срок пересмотра.

Во всех трёх случаях первопричина оказалась в процессе, а не в человеке. Это не совпадение: если цепочка закончилась на «сотрудник ошибся», вопрос «почему система это допустила» ещё не задан.

Как оформить результат разбора для отчёта

Цепочка без итогового документа остаётся устным знанием. Минимальная запись разбора содержит шесть полей:

• Проблема: факт с датой, местом и масштабом.
• Цепочка причин: узлы с подтверждениями, развилки отмечены отдельно.
• Первопричина: одна или несколько, сформулированные как состояние процесса.
• Корректирующая мера: убирает конкретную первопричину.
• Ответственный и срок: без имени и даты мера не будет выполнена.
• Критерий проверки: по какому признаку вы поймёте, что мера сработала.

Когда такие записи копятся, видно, какие первопричины повторяются. Если три разных инцидента упёрлись в отсутствие регламента, то правка регламента даст эффект сразу по трём направлениям.

Как проверить, что мера сработала

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

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

5 почему, Исикава и дерево проблем: что выбрать

• 5 почему подходит, когда проблема одна, а причина ожидается в глубине: быстрый разбор инцидента за 30–60 минут.
• Диаграмма Исикавы подходит, когда причин много и их нужно сгруппировать по категориям на воркшопе.
• Дерево проблем подходит, когда нужно связать причины и последствия и затем перейти к целям проекта.

Методы не исключают друг друга: типичная связка — группируете причины по Исикаве, самые вероятные ветки углубляете «пятью почему», а итог оформляете деревом.

Когда одной цепочки недостаточно

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

Если причины нужно сгруппировать по категориям (люди, процессы, оборудование, материалы), используйте диаграмму Исикавы онлайн: категории задают рамку, а метод «5 почему» углубляет каждую ветку. А когда после разбора нужно превратить причины в план действий, пригодится дерево проблем и целей.

Следующий шаг

Повторите это на своей задаче

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

• Без регистрации
• Данные хранятся в вашем браузере
• Бесплатно на этапе беты