Улитки против геморроя или метод «5-почему?»

Один из, пожалуй, самых известных методов решения проблем – метод «5-почему?». Автором метода называют Саикити Тоёду, человека, заложившего первые камни в фундамент производственной философии компании Toyota. Он говорил, что для устранения проблемы важно устранять ее первопричину. Чтобы найти первопричину стоит задать 5 раз (эмпирическое число) вопрос «Почему?» и с хорошей вероятностью вы к ней придете.
Используя этот метод важно помнить, что существуют разные вопросы «Почему?»:

• «Почему?», проясняющий причину (почему происходит следствие),
• «Почему?», направленный на определение обоснования причинно-следственной связи или «сердца» улитки: «Почему ты думаешь, что причина влечет следствие?».

В реальности нам надо задавать как одно, так и другое «Почему?».

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

ПРИМЕР: Неудавшийся релиз

Контекст: команда разработчиков ПО готовила новую версию своего продукта. В последний день перед релизом прибежал руководитель и потребовал срочно добавить функцию Х, команда в спешке внесла изменения и сразу после релиза новой версии у заказчика система «упала», что в итоге повлекло простои бизнеса.
Команда собралась на ретроспективу и начала обсуждать, что нужно сделать, чтобы избегать подобных ситуаций в будущем. Наивный подход – это запретить то, что непосредственно привело к инциденту, но более правильный путь – выявить истинные причины произошедшего и дальше работать с ними.

Вот так выглядит карта по этому примеру:

Эта картинка нужна не для того, чтобы вы на ней что-то разобрали, а для того, чтобы вы пошли по ссылке и открыли эту карту в новом окне и сверялись с ней. Также вы можете оставить на ней комментарии.

А ещё, рассматривая этот пример, мы с вами увидим разницу между различными «Почему?»: «Почему?», проясняющим причину, и «Почему?», направленным на сердце улитки или на выяснение обоснования.

А ещё будьте осторожны, так как мы с вами будем рассуждать о:

• Причине
• Следствии
• Обосновании
• Причине обоснования

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

Итак, вот «Почему?» проясняющее причину:
— Почему ваша система упала после сразу релиза на стороне заказчика?
— Потому что мы внесли изменения в систему за день до релиза.
Следуя ортодоксальному методу «5-почему», мы можем продолжать («ПУТЬ 1» на диаграмме):
— А почему вы внесли изменения в систему за день до релиза?
— Потому что прибежал руководитель продукта, громко кричал, ругался и заставил нас это сделать.
— А почему руководитель продукта кричал, ругался и заставил вас за день релиза внести изменения?
— Потому что, по его мнению, мы сделали совсем не то, о чем он нас просил и заказчику новый релиз будет бесполезным. И чтобы новый релиз представлял хоть какую-то ценность для заказчика, он потребовал включить хотя бы вот эту фичу Х, которую мы внесли за день до релиза.

Пока эту дискуссию поставим на паузу, вернемся к «Улитке 1» и посмотрим, как выглядит «Почему?» к её «сердцу» или «Почему?», проясняющее обоснование:
— А почему внесение изменений в систему за день до релиза повышает риск того, что система разваливается?
— Потому что в этом случае мы не успеваем протестировать систему полностью. В данном случае мы упустили критичную ошибку

Здесь мы уже можем пойти в сторону, выясняю причину «сердца Улитки 1» («ПУТЬ 1» на диаграмме):
— А почему вы не смогли полностью протестировать систему?
— Потому что полное тестирование у нас занимает около двух дней, а у нас в запасе было меньше одного дня. Соответственно мы просто не смогли проверить работоспособность всех модулей, а проверили только критические.
Так начинается построение «Улитки 1.1», но пока еще нам не понятно ее обоснование, давайте прояснять:
— Да, но почему вы тогда не сдвинули сроки релиза, чтобы успеть протестировать систему?
— Мы следуем итеративной инкрементальной методологии разработки, в рамках которой фиксированная длина каждой итерации для нас закон!
— То есть, сроки релиза согласованы и сдвинуть их нельзя?
— Да, всё именно так.

Здесь можно начать задавать вопрос: «А почему вы следуете этой методологии» и это будет «Почему?», направленное на выяснение причины обоснования «Улитки 1.1», а если мы зададим вопрос: «А почему у вас полное тестирование занимает несколько дней?» то это будет «Почему?» проясняющее причину. Уместный вопрос, кстати, давайте его зададим и получим в ответ («Улитка 1.2»):
— Быстрые автоматизированные тесты покрывают малую часть функционала. Основное тестирование проводится вручную силами трех тестировщиков.

И опять, я здесь могу продолжить задавать «Почему?», проясняющий причину, а могу показать вам ещё один
пример «Почему?», направленного на выяснение причины обоснования («ПУТЬ 3» на диаграмме и «Улитка 1.2.1»):
— А почему вы проверяете систему силами только трех тестировщиков? У вас же в команде куда больше людей.
— Да, у нас в команде есть еще 4 старших разработчика и два архитектора. Это «дорогие» сотрудники и это будет расточительством использовать их для решения «дешевых» задач ручного тестирования, поэтому мы их сразу же переключаем на задачи следующей итерации, которые соответствуют их квалификации.
— Интересно, если бы разработчики и архитекторы всё же помогли тестировщикам в ручном тестировании системы, то помогло бы это избежать проблемы после релиза? И второй вопрос: я понимаю, что эти сотрудники «дорогие», но во сколько вам обошелся этот инцидент? Смогли ли вы окупить потери из-за этого инцидента той работой, которой занимались ваши «дорогие» сотрудники вместо помощи тестировщикам?
— Я не знаю, тут надо подумать и посоветоваться…

Когда и по какому пути надо двигаться, мне кажется – это уже вопрос интуиции, которая будет постепенно появляться по мере осмысления опыта. Но уже сейчас видно, что метод «5-почему?» в общем случае – не линейный метод и просто устно без инструментов визуализации дискуссии запутаться в этом методе проще простого. И это мы пока еще не затронули того момента, что на вопрос «Почему?» может быть более, чем один ответ! Но об этом чуть позже, а пока давайте вернемся на «ПУТЬ 1» и выясним, что находится в сердце «Улитки 2»:
— А почему требование внести изменения за день до релиза стало причиной для внесения изменений в систему? Неужели никого не смутило это требование?
— Ну смутило конечно… Но он же руководитель… Он требует, а мы делаем…
— То есть, он вообще любую дичь может у вас потребовать, и вы безоговорочно это выполните?
— Нет, ну конечно откровенную дичь мы не будем выполнять…
— А внести изменения за день до релиза при условии, что тестирование занимает минимум два дня – это дичь или не дичь?

*ЗВУКИ СВЕРЧКОВ И ЧУВСТВА ВИНЫ*

— Дичь, конечно. Но мы как-то не умеем с ним спорить. Нам бы придумать какое-то стоп-слово, типа «Серега, перестань!» или еще какой-то механизм права вето, что ли…
— Отлично, давайте так же зафиксируем этот результат.

Обратите внимание, ортодоксальный метод «5-почему?» обещает нам результат в конце, а тут мы еще до конца не дошли, но уже выявили интересные моменты, которые могут помочь команде улучшить свою работу. И это мы еще ветку с автоматизированным тестирование вглубь не копали! Но давайте продолжим идти по «ПУТИ 1» и построим «Улитку 3»:
— А почему руководитель потребовал у вас за день до релиза срочно разработать новую фичу?
— Он пришел к нам как раз за день до релиза, спросил: «Как дела?», попросил показать, что мы собираемся завтра выкатывать. Мы ему показали, и он тут как возбудился! Сказал, что это фигня полная, для заказчика пользы в этом релизе никакой, давайте срочно делать фичу Х, чтобы хоть какая-то польза была.
— Как я понимаю, «польза в каждом релизе» – это тоже закон методологии?
— Ну да.

Здесь мы получаем у улитки «сложный хвост», то есть два утверждения:

• Мы разработали бесполезный функционал
• То, что мы сделали, руководитель увидел лишь за день до релиза

Причиной того, что руководитель потребовал срочно сделать фичу Х стало одновременное выполнение этих двух утверждений. То есть, если бы разработали бесполезный функционал, но руководитель узнал бы об этом после релиза не стало бы причиной его требования срочно вставить фичу Х. Или если бы мы все сделали правильно, то посмотрев на результаты за день до релиза, руководитель тоже бы от нас ничего не требовал. Нам необходимо сразу два этих условия и поэтому мы объединяем их овалом.

Далее у нас получаются две улитки, каждую из которых мы исследуем отдельно. Для начала исследуем «Улитку 3.1»:
— Почему вы разработали функционал, который оказался бесполезным для заказчика?
— Когда мы планировали итерацию, то на сессии планирования мы неправильно поняли руководителя. Точнее, как неправильно? Пока он у флипчарта нам объяснял, нам показалось все понятным, но как только мы начали разрабатывать, то начались вопросы. Мы, конечно, сами как могли на эти вопросы искали ответы, но в ряде ключевых мест мы не угадали.

То есть, здесь причина того, что появился бесполезный функционал – это неверное понимание постановки задачи. Но каким образом неверное понимание к этому привело? Можно же было уточнить вскрывшиеся неясные моменты. Но тут вылез «таракан» ведущего разработчика:
— Мы бы, конечно, уточнили у руководителя, правильно ли поняли задачу, но за важнейшую задачу релиза отвечал наш новый разработчик, и он очень боится показывать свое непонимание.
— Понятно, это он будет со своим психологом прорабатывать. Есть идеи, какое здесь может быть временное решение?
— Мы тут отдельно в команде думали, что у ведущего разработчика хорошие отношения с аналитиком и пусть она его вопросы задает руководителю под видом своих. И в форме: «Я правильно поняла, что …» и дальше описать позицию разработчика, чтобы в случае неверного понимания сам разработчик не чувствовал риска.
— Прекрасно!
Теперь пойдем по другому пути, достраивая «Улитку 3.2»:
— А почему ваш руководитель увидел то, что вы собираетесь выпускать лишь в последний день?
— А вот это хороший вопрос. У нас итерация идет три недели и в принципе, у нас каждую неделю мы завершаем работу над двумя или тремя функциями и нам ничего не мешает устраивать руководителю промежуточные 15-минутные демонстрации хоть через день, хоть каждый день. Мало того, он сам будет рад такому.

Как и все примеры этот пример – вымышленный и в данном случае по результатам анализа инцидента вымышленная мной команда пришла к следующим выводам:

1. За 2 дня до конца релиза мы объявляем заморозку кода и ничего в нем не меняем, кроме найденных в процессе тестирования ошибок.
2. Но если вдруг нас опять это заставят сделать, то к тестированию подключается вся команда, без учета «чинов и званий».
3. Договориться с руководителем о механизме права вето на его решения или по крайней мере механизме предоставления отсрочки выполнения решения (чтобы он сам успел остыть и подумать).
4. Отправить ведущего прорабатывать комплекс самозванца с психологом.
5. Как временное решение его вопросы под видом своих будет задавать руководителю аналитик.
6. Договориться о промежуточных демонстрациях новой версии руководителю по вторникам и пятницам.

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