Правильные вопросы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

ITIL ITIL Intermediate: Operational Support and Analysis

Учебный курс: эксплуатация и поддержка ИТ-услуг, Service Desk, инциденты, проблемы, операции и запросы пользователей — в ITIL и на практике.
 

Узнайте больше!

Комментарии и мнения

  1. Андрей Яковлев

    Аналитик проблем как раз должен правильно формулировать вопросы. В первую очередь, чтобы самому понять в чем дело. Отвечать, само собой проще, если вопрос задан внятный. Потом, ветвление при поиске любого решения решения (корневая причина — частный случай) неизбежно. Упрощенно, выдвигаются гипотезы (скажем нулевая, и альтернативная) формулируется вопрос, полученные факты двинут процесс, если окажутся в пользу какой-либо из гипотез, либо откинут их (отрицательный, но результат).  Далее все повторяется. Количество шагов зависит от близости к цели на первом этапе (просто если ситуация не улучшилась, то очередной шаг — аналог первого). 5 шагов, видимо, эмпирика. 

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

    Вот поэтому трудно сказать, может ли хороший решатель быть хорошим тренером. 

    0
    0
    1. Игорь Гутник Автор

      Андрей, спасибо!

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

      Но методы как раз очень полезны в том случае, если наступает "творческий кризис". Особенно, если идёт коллективная работа над анализом. Методы в этом случае, конечно же, не решат проблему за нас. Но могут систематизировать нашу работу над проблемой.

      По поводу "эмпирики" цифры 5 — я догадываюсь, что авторы ITIL её не с потолка взяли (хотя, собственно, почему бы и нет 🙂  )

      Но интересно, у кого какой практический опыт на этот счёт. Сколько шагов в среднем требуется, чтобы дойти корневой причины? А сколько максимум?

      По поводу вопроса "может ли ... быть хорошим тренером" — у нас есть свои методы 🙂

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

      0
      0
  2. Андрей Яковлев

    1 "Творческие кризисы" — неизбежны. Не вдаюсь в детали, но это опять физиология. Обойти проблему можно  хорошо организованной командой и достаточно полной Базой Знаний. Так решится 80-90% проблем до поиска корневой причины (приоритет для бизнеса может быть никак не связан с реальной сложностью). В остальных случаях,риск нужно принять, творческий кризис должен кончится (он же не вечный). Менеджмент должен только не забыть.

    2. Я поднял базу знаний по инфраструктуре (FAQ, Wiki, tips & tricks). количество указанных шагов реально в среднем 4-10. Да и авторы решений ведь ход помнят приблизительно. Важно сделать усилие над собой и не ляпнуть: "ну это же было очевидно!". Придерживаться KISS и соблюдать корректность. Но тут у меня обширная техническая экспертиза.  

    3. Анализ кода. Поиск "root cause"  тут непрост, нужно проиграть ход мыслей разработчиков. Формализация затруднена, разве проактивная позиция —  делать правильно и стандартно, в ущерб революционности. Но — по ситуации.

    4. Оргпроблемы. Тут всегда 1 ход в поиске. Решение вот только из-за человеческого фактора совсем не ремонт железок или рефакторинг кода.

    О минимуме и максимуме. Если задача в принципе решаема, то на будущее аналитика причин должна не только найти решение, но и кратчайший путь для подобных  задач. 

    Желание есть, нет сертификатов, есть реализованные проекты от продавливания менеджмента. База есть, самообразованием и курсы в исполнении жителя Королевства Нидерланды. Выставочный проект довел руководство до того, что они не помнят, откуда счастье. Зато (редкость для середняка — тишь да блажь, ИТ отдел постоянный, а уровень сервиса только растет). Неудачи были, сам виноват, объяснял не того конца.

    0
    0

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

НОЯ
27
Учебный курс:
Основы ITIL (очно)