пятница, 18 июня 2010 г.

5 почему

5 почему (Five Whys) - это одна из методик "бережливого" прозводства (Lean Software Development or Lean Manufacturing).

Методика позитивная, потому что когда что-то идет не так, то вместо того, чтобы искать виноватых, она призывает нас учиться на своих ошибках, и попытаться найти основную (основные) причины возникновения проблемы. Мягче к людям и жестче к обстоятельствам (не помню, правда, откуда этот лозунг, но согласен на 300%).
Формальное описание методики подразумевает внедрение некого процесса, однако, не вижу причин не использовать её и в повседневной жизни. Я, к примеру, еще до того как наткнуться на описание, давно заметил, что просто один раз спросить "почему" в большинстве случаев не достаточно.

"Почему билд упал?" "Вкоммитали неработающий код" "Ааа, понятно....". Кому что стало понятно, правда, не очень ясно. Поэтому обычно я теперь спрашиваю много почему, до тех пор, пока проблема не развернётся в нечто действительно реальное и требующее корректив.

В этом случае я использовал аналитическую часть методики "5 почему", сама же методика идет немного дальше анализа.

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

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

Проблема: После переезда я долго не мог найти бритву и ходил не бритым. И не только бритву. Вообще, мы много чего до сих пор ищем. Поскандалили с женой, конечно, но это не позитивно, ведь причем тут жена. При том же, причем и я.

Итак, я не побрился.
  1. Почему? - Еще не разобрали тот ящик, где лежала бритва
  2. Почему? - Не хватило времени
  3. Почему? - Не могли найти ящик, в котором лежала бритва
  4. Почему? - Бритва лежала отдельно от других принадлежностей (пены с лосьоном)
  5. Почему? - Забыли про бритву, когда складывались и положили в последний ящик, когда уже не знали, где лежала пена и лосьон
С каждым вопросом "почему" мы все больше углубляемся в проблему и взрезаем очередной её слой.

Это была аналитическая часть. Далее для каждой обозначенной проблемы приводим решение.
  1. Сначала разбирать вещи первой необходимости
  2. Записать сколько требуется времени для переезда
  3. Наклеить стикеры с содержимым на ящики
  4. Сгруппировать принадлежности по ящикам, нести ящик туда, где его нужно разбирать
  5. Провести инвентаризацию, вещи будет легко группировать еще до сборов (в какой ящик что положить) и ничего не будет забыто
То есть мы не просто пытаемся решить "основную" проблему, мы выстраиваем 5 линий защиты, которые нам помогут не допустить той же самой ошибки еще раз.

Некоторые пункты выше достаточно трудоемки, действительно. инвентаризация всех вещей, которые у нас есть явно не быстрый процесс. Хотя такой список, я уверен, был бы полезен и по другим причинам, например, до сих пор не понятно, откуда у меня взялась ножовка - то ли сам купил, то ли взял у кого-то. Я также не уверен, куда подевался строительный фен - наверное, кому-то дал попользоваться.

Поэтому важный аспект методики заключается в том, что ответ проблеме должен быть симметричен самой проблеме. Если проблема пустяковая и отняла у нас 15 минут времени, то не стоит тратить более 15 минут на её решение.

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

Очередной плюс методики заключается в том, что она фокусируется только на проблемах, которые действительно вам мешают, то есть вы решаете те самые 20% проблем, которые отнимают у вас 80% процентов времени.

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

У методики есть и минусы. Красивая цепочка вопросов-ответов, приведенная выше, далась нам с женой тяжело.

Открою секрет - мы её притягивали за уши к ответам, которые у нас уже есть. Мы задали гораздо больше почему, чем приведено выше, поэтому хотелось написать только значимые с самыми красивыми выводами. Рассуждения ниже объясняют, почему так получилось. И да, после того как мы нашли бритву, я не стал чаще бриться :)

Основные недостатки заключаются в том, что:
  • если подумать, то зачастую на один вопрос почему существует много ответов; то есть получается этакое дерево ответов; в частности большая часть веток дерева, которое могло быть построено по нашей проблеме, не приводили нас к необходимости инвентаризации; ветки бывают интересными и не очень; наверное, в этом случае важно содержание, а не форма - красивая цепочка почему не самоцель
  • правильных решений проблем методика автоматически не дает, никто вас не страхует от некреативных решений - "забыли бритву?" "окей, надо в следующий раз не забывать"; хотя 5 степеней проработки все же дают лучше результат, чем поверхностный анализ (хоть где-то что-то правильное придумаете)
  • иногда анализ тяжело развить, к примеру, "забыл бритву" "почему? потому что рассеянный" "почему рассеянный? o_O? потому что с улицы бассеянной." - мы упираемся в проблему, причин которых мы не знаем; часто все же бывают решения, например, "весенний авитаминоз" с вполне понятным способом решения проблемы; также можно попробовать найти другую ветку, то есть на более ранних этапах попробовать дать другой ответ почему; и на самом деле цепочка вопросов может быть связана другими способами; в технической поддержке зачастую есть несколько уровней поддержки, проблема передается с одного уровня на другой, пока не будет решена; в этом случае вопросы могут быть "почему первая линия поддержки не решила проблему?", "почему вторая линия не решила проблему?" - опять таки важно содержание, а не форма
  • иногда 6й, 7й и т.д. вопросы вскрывают проблемы поинтереснее; наверное, это просто выражается в неудовлетворенности от ранее данных ответов, что следует воспринимать как толчок для бOльшего количества почему; то есть не надо стремится к формализму, любая методика может нуждаться в адаптации к проблеме
В целом же, любая ретроспектива и корректирующие действия лучше, чем ничего. Проблемы выше все же не настолько критичны, тем более секрет в том, что если с первого раза не удалось сразу решить что-то, то будет второй раз (если он будет), который позволит нам снова взглянуть на ту же ситуацию уже в свете прошлого анализа и корректив, сделанных ранее.

В любом случае, удачного вам анализа.

Комментариев нет:

Отправить комментарий