Суть модели
Метод «5 почему» — это техника анализа проблем, основанная на последовательном задавании вопроса «Почему?» до тех пор, пока не будет выявлена корневая причина. Обычно достаточно 5 шагов, чтобы дойти от симптома к реальной первопричине.
Ключевая идея:
Устраняя симптом, мы решаем проблему лишь временно.
Но если найти и устранить корневую причину, то ситуация не повторится.
История и авторы
Метод был разработан в компании Toyota в 1930-х годах и стал частью системы Toyota Production System (TPS). Автором метода считается Сакити Тойода, а позднее метод активно развивал Тайити Оно, один из отцов «бережливого производства» Lean manufacturing.
Сегодня техника «5 почему» используется не только в промышленности, но и в бизнесе, образовании, управлении проектами и личной жизни.
Эту технику мы используем в курсе "Решение проблем в бизнесе" и при проведении Стратегических сессий.
Как применять на практике
- Сформулируйте проблему. Опишите её максимально конкретно, например: «Клиент не получил заказ вовремя».
- Задайте первый «Почему?» Почему клиент не получил заказ вовремя? → «Доставка была задержана».
- Продолжайте задавать «Почему?» Почему доставка была задержана? → «На складе не хватило нужного товара».
- Двигайтесь дальше. Почему не хватило товара? → «Поставщик не привез его в срок».
- Дойдите до корня. Почему поставщик задержал поставку? → «Мы не контролировали сроки поставки, и не было запасов». В итоге мы понимаем, что корневая причина — не поставщик, а отсутствие системы контроля и запасов.
Еще 3 примера вы найдете ниже.
Другие техники системного мышления:
Когда полезно использовать
- В анализе ошибок и инцидентов: срыв сроков, брак, жалобы клиентов.
- В управлении проектами — чтобы предвидеть риски.
- В бизнес-процессах — для повышения качества и эффективности.
- В личной жизни — чтобы разобраться с привычками и повторяющимися проблемами.
Выгоды и ограничения
Плюсы:
- Простота и наглядность — не нужны сложные инструменты.
- Помогает докопаться до сути.
- Универсальна — работает в любой сфере.
Минусы:
- Требует честности и дисциплины — легко остановиться на «удобном» ответе, например, «поставщик сорвал доставку».
- Субъективность — может привести к разным результатам у разных людей.
- Иногда одной цепочки недостаточно и нужно дополнять другими методами, например, диаграммой Исикавы (рыбий скелет).
Варианты визуализации
- Простая цепочка вопросов-ответов списком.
- Древовидная диаграмма — если от одного ответа идёт несколько «почему».
- Инфографика в стиле блок-схемы.
- Mindmap — для группового обсуждения.
В каком ПО удобнее оформлять
- Miro, Mural, Figma — для командного мозгового штурма.
- PowerPoint, Keynote — для презентаций.
- Excel, Google Sheets — для систематизации и отчётности.
Примеры применения
Давайте разберём метод «5 почему» на 3 проблемах, с которыми могут столкнуться ИТ-команды:
- прод упал после релиза;
- пользователи жалуются на медленную работу приложения;
- в прод попали пароли в открытом виде.
1. Пром упал после релиза
- Почему система упала после релиза? → Потому что новая версия вызвала критическую ошибку.
- Почему ошибка попала в продакшн? → Потому что её не обнаружили на этапе тестирования.
- Почему тестирование не выявило ошибку? → Потому что не было автотестов на этот сценарий.
- Почему не было автотестов? → Потому что команда не успела их написать к дедлайну.
- Почему команда не успела написать? → Потому что при планировании задачи тесты не были включены в обязательный объём работы.
- Почему автотесты не были включены в обязательные работы? → Потому что они не входят в состав обязательного Definition of Done.
Корневая причина: в процесс планирования доработки и DoD не входит обязательная разработка и покрытие автотестами.
2. Пользователи жалуются на медленную работу приложения
- Почему приложение работает медленно? → Потому что страницы грузятся дольше 5 секунд.
- Почему страницы грузятся так долго? → Потому что база данных отвечает медленно.
- Почему база данных отвечает медленно? → Потому что запросы не оптимизированы.
- Почему запросы не оптимизированы? → Потому что разработчики писали их «в лоб», без анализа нагрузки.
- Почему нагрузку никто не анализировал? → Потому что в команде нет процесса регулярного профилирования и оптимизации.
Корневая причина: отсутствие практики анализа производительности и оптимизации запросов.
3. В пром попали пароли в открытом виде
- Почему пароли оказались в открытом виде? → Потому что один сервис логировал пароли без шифрования.
- Почему сервис логировал пароли? → Потому что разработчик добавил логирование для отладки и забыл убрать его.
- Почему неубранное логирование паролей не было обнаружено? → Потому что не было code review на этот участок кода.
- Почему code review не было? → Потому что команда торопилась закрыть задачу и срезала процесс.
- Почему команда решила срезать процесс? → Потому что сроки были сжаты и не было времени на полный цикл проверки.
Корневая причина: давление на сроки приводит к нарушению стандартов качества и безопасности.
Как видно, метод «5 почему» помогает IT-командам понять, что проблемы не в «плохих разработчиках» или «кривом коде», а в процессах — планировании, контроле качества, культуре работы.