Недавно, в очередной раз обсуждая техники анализа проблем, используемые в рамках процесса управления проблемами (Problem Management), спорили по поводу количества вопросов, которые нужно/можно задавать, реализуя методику «Пять «Почему?» («5-why»). Суть метода, напомню, заключается в том, что мы берём какое-то явление (проблему) и задаём себе вопрос: «Почему это происходит?». Найдя ответ на этот вопрос («Это происходит, потому что, происходит то»), мы задаём тот же самый вопрос «почему?» про «то» («А почему происходит то?»). И т.д. и т.п. Утверждается [ITIL  SO, 4.4.4.3], что, следуя по этой цепочке, мы «обычно на пятой итерации добираемся до корневой причины».

На самом деле то, как быстро мы доберёмся до корневой причины (root cause, «первопричинность» которой – тема отдельно обсуждения) сильно зависит от того, какие вопросы мы задаём.
Даже если ограничиться простыми инфраструктурными примерами, которые чаще всего разбираются на курсах и в книжках, то можно увидеть, что, идя в обратную сторону по цепочке причинно-следственных связей от проблемы к корневой причине, мы почти на каждом шагу сталкиваемся с ветвлением (ответов на очередной вопрос «почему?» может быть более одного). А если принять в рассмотрение не только технические факторы, то количество ветвлений сильно увеличится.

Именно это свойство ветвления отлично визуализируется с помощью другого метода анализа проблем – диаграммы Ишикавы («рыбий скелет»).
И то, какие ветки на каждом шагу мы идентифицируем и в каком количестве, зависит в том числе от того, как мы сформулируем вопрос. По идее, наличие компетенции в исследуемой области помогает правильно формулировать вопросы, с другой стороны появляется риск замыленности взгляда или неосознанного самоограничения мышления в силу устоявшихся в отрасли/профессии мнений и авторитетов.
Частично на преодоление этой трудности направлены техники, помогающие систематизировать анализ. Например, два первых шага метода Кепнера-Трего (в том числе в варианте этого метода, описанного в ITIL: описать и определить проблему), или построение дерева текущей/будущей реальности (в теории ограничений Э.Голдрадта).

Получается, что повышение эффективности поиска решений достигается  не только за счёт эффективного поиска ответа на вопрос/решения задачи, но и за счет эффективного механизма формулирования вопроса или задачи, для которой нужно найти решение. Вроде бы очевидно (и давно известно: «Правильно сформулированная задача – это половина решения»).

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

С точки зрения развития (повышения эффективности процесса, решения задачи и т.п., развития в своей профессиональной и личной жизни) проблема заключается в том, что не всегда вопросы для нас уже готовы. Мы сами должны их для себя сформулировать. Например, если говорить о динамике развития человека (в т.ч. в профессиональном плане), начиная с достижения какого-то уровня комфорта, жизнь, вроде бы, перестаёт «задавать вопросы». И то, что будет дальше с развитием, в большой степени определяется способностью задавать вопросы самому себе.

Если вернуться (только на секунду!) к ITSM, то именно это и является одной из причин, по которой проактивное управление проблемами иногда «не взлетает», – мы сами в рамках процесса должны определить себе фронт работ.

Сложность генерации вопросов (в т.ч. самому себе) заключается ещё и в осознании риска того, что на вопросы-то придётся отвечать. А они [вопросы] могут быть сложными. А ответы – болезненными. Например, «зачем я читаю эту статью?»  Или, поскольку близится конец года, ещё более «страшные» вопросы (ну, те… которые про смысл…). Т.ч. нужно не только умение задавать вопросы и искать на них ответы, но и в какой-то степени мужество. Готовность идти в зону неизвестного или не комфортного.

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

1. Уметь задавать правильные вопросы
2. Не бояться это делать (в том числе не бояться обнаружить не очень приятные ответы)
3. Уметь отвечать на вопросы из п.1 (не закрывая глаза на не удобные варианты)

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

Вышло несколько философски. Но, тем не менее, интересно, соответствует ли это вашей картине мира?

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

PS
Кстати, мы ищем тренера. Так что, если вас не пугает необходимость не только отвечать на вопросы, но и задавать их (в первую очередь себе), идти туда, где вы ещё не были, или находить неизвестное в, казалось бы, хорошо знакомых местах, обращайтесь, пожалуйста (пишите на адрес info в нашем домене cleverics.ru).

ИНТЕНСИВ С ТРЕНЕРОМ

VAP: Управление поддержкой ИТ-услуг

Строим эффективную ИТ-поддержку, оптимизируем существующую