Всем привет!
Меня зовут Роман Сергеев, я - менеджер по внедрению и развитию продуктов и систем в ИТ «Ренессанс страхование». В этом материале я расскажу о том, как правильно метод использовать «5 почему?» и как провести мини-тренинг по этому инструменту для своей команды (scrum команды, команды проекта).
Начнем с того, зачем вообще нужен этот метод (если эта часть неинтересна, можно сразу переходить к ограничениям и типовым ошибкам).
Представьте, что у вас есть проблема: «Исходные оценки трудозатрат, которые команда дала для задач проекта, сильно отличаются от фактических». На практике часто вижу ситуацию, когда многие только увидев проблему, начинают сразу предлагать решения. На одной из реальных ретроспектив примерно на такой же вопрос сразу были предложены варианты:
«Необходимо улучшить навыки оценки».
«Необходимо улучшить знания предметной области».
«Необходимо использовать более эффективные подходы к оценке».
Сами по себе эти варианты могут быть вполне полезны. Но вот если прежде, чем предлагать варианты решения, задать вопрос «А почему исходные оценки отличаются от итоговых?» (как это и было сделано на упомянутой выше ретроспективе), то можно получить ответ «Потому что требования менялись несколько раз».
И в этом случае помогло бы улучшение навыков оценки или использование более эффективной методики? Нет, так как требования все равно бы изменились, а вместе с ними и оценка.
Отсюда вывод – чтобы решить проблему, необходимо бороться с причиной, а не следствиями (спасибо, капитан Очевидность). И метод «5 почему» помогает в поиске корневой причины проблем.
Суть метода проста. Если в примере выше мы задали вопрос «Почему?» один раз, то метод предлагает задать этот вопрос 5 раз (спасибо, капитан, еще раз).
Почему именно 5?
Эмпирическим путем пришли к тому, что 5 вопросов должно хватить. Если получится быстрее найти причину, то нет необходимости вымучивать искусственные вопросы и ответы. Если за 5 подходов не получилось найти корневую причину, можно задать и больше вопросов, это не запрещается.
Теперь переходим к самому интересному и тому, про что часто забывают (или не знают): как правильно отвечать на вопросы «Почему». Ответы на вопросы должны удовлетворять следующим требованиям:
Ответ должен быть основан на фактах и должен быть реальной причиной, а не гипотезой или другим следствием проблемы.
Участники обсуждения должны быть экспертами в том вопросе, который они обсуждают, и должны обладать полной информацией, необходимой для обсуждения.
Для ответа на «почему» должен работать «обратный проход» - причинно-следственная связь в вопросе и ответе должна работать в обе стороны. Если на вопрос «почему произошло А?» мы отвечаем «потому что произошло В», то должна сохраняться логическая связь и в утверждении «Произошло В, поэтому происходит А». Возвращаясь к исходному примеру «Исходные оценки отличались от фактических потому, что менялись требования», то «обратный проход» будет таким «Требования менялись, поэтому фактические оценки отличаются от исходных».
Рассмотрим типовые ошибки
Ответ на вопрос является гипотезой. Участники не знают точного ответа, но они предполагают, в чем она может быть, и фиксируют свою догадку. В чем тут риск? Все просто. Если не угадаешь, то вместо истинной причины найдешь что-то другое. Оно, возможно, окажется тоже важным, но те решения, которые будут приняты, не устранят реальную причину исходной проблемы. Поэтому каждый раз, получив ответ, необходимо спросить себя «А мы уверены, что это действительно факт, а не догадка?».
Не проверяется «обратный проход». Например, на вопрос «почему аналитики пишут непонятные и неоднозначные требования» дается ответ «Аналитики не являются экспертами в предметной области» (и в нашем примере считаем, что это факт, а не гипотеза). Посмотрим, как работает обратный проход - «Аналитики не являются экспертами в предметной области, поэтому они пишут непонятные и неоднозначные требования». Логично ли это утверждение? В подавляющем большинстве случаев ответом будет «нет», так как для того, чтобы писать однозначные и понятные требования надо знать принципы написания однозначных и понятных требований, и они не зависят от знаний предметной области. Соответственно, надо искать другую причину.
Работа с несколькими ответами на вопрос «Почему?». На один вопрос «почему» может быть несколько ответов, и возникает «ветвление». Если время встречи не ограничено, то можно успеть разобрать до конца с помощью «5 почему?» каждую «ветку». Если же время ограничено, то тогда есть смысл расставить приоритеты для каждой «ветки» и в первую очередь разбирать наиболее приоритетные из них.
Если вы, задав очередной «почему?», понимаете, что не можете дать на него ответ, который удовлетворяет описанным выше требованиям – это признак того, что, либо вы нашли корневую причину, либо вы дошли до ограничений вашей экспертизы, и, если причина проблемы еще не найдена, надо привлекать дополнительных участников для обсуждения.
И еще один важный момент, о котором стоит помнить. После того, как корневая причина проблемы найдена, надо найти способ ее решения/устранения. И после того, как этот способ найден, для него также должен работать «обратный проход».
В нашем примере с изменяющимися требованиями вариантом решения проблемы могло бы быть что-то типа «Необходимо составить план работы с изменениями». «Обратный проход» для него будет примерно такой – «если у нас будет план работы с изменениями, тогда мы все изменения будем фиксировать, оценивать и приоритезировать как отдельные задачи, и тогда наши исходные оценки не будут так сильно отличаться от итоговых». Таким образом, мы последовательно смотрим, как наше решение закрывает все причины, выявленные на каждом шаге «почему?».
Как сделать тренинг для команды?
Как показала практика, хоть метод «5 почему?» простой, и кажется, что про него можно легко и быстро рассказать за 5 минут, но тренинговый формат позволяет сразу опробовать метод на практике, и в ходе этой практики участники часто совершают типовые ошибки. Соответственно, лучше, чтоб эти ошибки совершались не на реальных задачах, а на тренинге, где их тут же можно обсудить и скорректировать.
Я для обычно использую следующую структуру:
Для создания осознанного запроса на обучение можно показать группе пример типовой проблемы, с которой она может столкнуться в рабочем процессе. После этого предложить сформировать решение. Дальше предложить ответить на вопрос «почему?», получить ответ, и сформировать решение уже для найденной причины. После этого сравнить ответы в первом и втором случае и обсудить, какой из них был бы эффективнее.
Основная часть. Рассказываем о методе и его ограничениях. То, что я описал выше:)
В той части, где рассказываем про типовые ошибки, можно не сразу объяснять, почему эти ошибки являются ошибками и какие будут последствия, а сначала задать этот вопрос группе. После получения ответов при необходимости дополнить их теорией.
После разбора теории необходимо отработать этот метод на практике. Я делю участников на группы (2 или 3, в зависимости от количества участников), даю каждой группе задание разобрать с помощью «5 почему?» проблему, которая актуальна в рабочем процессе. При этом делаю акцент на том, что в ходе выполнения каждая группа должна обращать внимание на «обратный проход», и чтоб ответ на «почему?» был основан на фактах и не являлся гипотезой.
После каждая группа презентует свои результаты, а все остальные смотрят, действительно ли ответы на «почему?» удовлетворяют всем требованиям. Если группа не очень активна, то задача challenge-ить ответы ложиться на тренера, т.к. цель упражнения не столько в активности группы, а в том, чтоб все увидели и разобрали типовые ошибки.
Роль фасилитатора
Как лучше вести себя фасилитатору в ходе использования этого метода (спасибо моей коллеге - Маше Фоминой - за все, что написано ниже).
При подготовке к тренингу, ретроспективе или любой другой активности в scrum-командах с использованием техники «5 почему» фасилитатору важно сконцентрироваться и продумать несколько вариантов развития встречи. Очевидно, что групповая активность может быть разной, соответственно, и фасилитатору нужно уметь правильно реагировать на изменения и направлять команду на достижение цели встречи.
Вот несколько простых рекомендаций, которые помогут провести встречу эффективнее:
1. Для создания атмосферы доверия и открытости начать встречу лучше с непринуждённой разминки, в которой будет участвовать каждый член команды, например, попросить участников ответить на вопросы:
«Расскажите 1 факт о себе».
«Никто не знает, что я…»
«Что объединяет меня с партнером по разминке».
Также в качестве разминки можно использовать вопрос, который поможет участникам сфокусироваться на цели встречи, например:
«Что будет наилучшим результатом встречи для меня?».
«Что я готов сделать, чтобы сегодняшняя встреча прошла эффективно?».
Варианты разминок можете выбирать на ваш вкус и с учетом особенностей группы.
2. Для того, чтобы команда лучше представляла задачу, которую ей необходимо решить, можно использовать инструменты визуализации, например, популярные и проверенные «рыбий скелет» или «дерево причин». Это помогает лучше понять проблему, выделить причинно-следственные связи и лучше сфокусироваться на поиске решения.
3. В случае, если обсуждение начинает уходить от исходной темы, и каждый участник фокусируется на чем-то своем, то фасилитатор может вернуть дискуссию в нужное русло с помощью открытого вопроса вида «Как то, что мы сейчас обсуждаем, поможет нам ответить на исходный запрос <далее просто повторяем тему, с которой началось обсуждение>».
4. Бывают ситуации, когда команда не может предложить ни одного ответа на вопрос «Почему?». Варианты пассивности группы могут быть разные: не хватает креативности, коллеги стесняются высказать свое мнение, боятся говорить про истинные причины и многое другое. В этом случае можно использовать анонимный сбор идей (стандартный подход с написанием карточек) с последующим обсуждением и голосованием (если необходимо). Также можно попробовать «сдвигающие вопросы»:
Какая информация могла бы помочь ответить на вопрос?
Если бы вы уже решили эту задачу, то за счет чего вы могли бы это сделать?
Если бы у вас был неограниченный доступ к любым ресурсам и информации, как бы вы могли решить проблему?
Все, что описано выше – обобщение теоретической базы и практического опыта работы с командами (моего личного и моих коллег), надеюсь, эти советы помогут и вам.