Почему полезно быть почемучкой Чаще всего проблемы похожи на | EASY — управление задачами, проектами и удалёнными командами
Почему полезно быть почемучкой
Чаще всего проблемы похожи на айсберг — видна только поверхность, но не первопричина. Пытаясь решить проблему поверхностно, мы не получаем ожидаемого результата и начинаем считать себя либо неудачниками, либо «ну штош, жизнь такова и никакова иначе».
Ха! Как бы не так. Нужно всего лишь докопаться до сути, чтобы решить проблему по-настоящему.
Дотошный основатель Toyota Сакити Тоёда для решения производственных задач компании разработал метод «5 почему». И он оказался настолько хорош, что разлетелся по всему миру и проник во многие сферы: психологию, управление проектами и обычную жизнь.
Смысл метода очень прост: если задать вопрос «Почему?» пять раз, то ответы приведут к первопричине проблемы, а значит и решение априори будет эффективней поверхностных попыток.
Как докопаться до себя
Сформулируйте проблему.
Задайте вопрос: «Почему это произошло?»
Ответьте.
Снова спросите себя: «Почему это произошло?»
И так до тех пор, пока вопроса «Почему?» больше не возникнет.
Вы увидите, как простые вопросы-ответы сложатся в логическую цепочку и приведут к первопричине.
Пример
Проблема: Не отправили дайджест новостей о проекте вовремя.
Шаг 1. Почему мы не отправили дайджест вовремя?
В прошлый раз мы обещали пользователям, что выкатим одну новую фичу, но не успели реализовать её до указанного срока.
Шаг 2. Почему не успели?
Потому что новый разработчик был сильно загружен и не справился к сроку.
Шаг 3. Почему новый разработчик загружен и не справляется с дедлайнами?
Потому что не успел вникнуть в проект.
Шаг 4. Почему новый разработчик не вник в проект, если у него на это было два месяца?
Потому что у нас проблемы с онбордингом.
Шаг 5. Почему у нас проблемы с онбордингом?
Потому что его как такового нет — новенькие долго вливаются в работу, а команда тратит много рабочего времени на их онбординг, работа проседает.
И вот за пять шагов мы пришли из состояния «мы всего лишь не отправили дайджест вовремя» в «капец, неужели из-за онбординга мы теряем так много ресурсов команды впустую?!».
Причём не обязательно задавать именно пять вопросов, до сути можно докопаться и за три и за восемь.
Лайфхак: если обсуждать всей командой, то скорее всего вы выявите более объективные и значимые причины.
Важно помнить: результат метода сильно зависит от способности исследователя отыскать причину.
В примере на третий вопрос можно было бы ответить и так:
«Потому что менеджер вовремя не подключил второго разработчика»
«Потому что разработчик вовремя не делегировал эту задачу»
Тогда и первопричина была бы совсем другой, например, в недостатке разработчиков в команде.
Пользовались когда-нибудь таким методом в работе?