×

Problem Solving: методики

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

Итак, само определение проблемы подразумевает ее решение. И столкнувшись с проблемой, мы начинаем искать способы воздействия — методики. Любая из них призвана настроить наше мышление в правильное русло, но у каждой свой подход. Изучая новые техники, мы расширяем обзор на проблему и увеличиваем свою эффективность.

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

Root cause Analysis

Root Cause Analysis (RCA) — поиск ключевой причины возникновения проблемы, ее анализ и создание плана по ее разрешению. Если проблема воспроизводится снова, значит, настоящая причина не была найдена.

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

Root cause analysis нацелен на идентификацию происхождения проблемы, используя определенный набор шагов и инструментов:

  1. Определить, что случилось.
  2. Определить, почему это случилось.
  3. Выяснить, что сделать, чтобы это не случилось снова.

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

Чаще всего вы будете сталкиваться с тремя основными факторами:

  1. Физический фактор — материальные, осязаемые сбои (Пример: завершился срок аренды домена).
  2. Человеческий фактор — человек допустил ошибку, либо не сумел ее предотвратить (Пример: никто не проплатил аренду домена).
  3. Организационный фактор — система, процесс, которые используются для принятия решений и выполнения задач, неисправны (Пример: не был назначен ответственный за проплату домена).

Root cause analysis учит обращаться ко всем трем типам — для анализа всех граней негативного воздействия, поиска скрытых недостатков системы и определения направленных на решение проблемы действий. Поэтому очень часты вы будете получать более одного root cause.

RCA включает в себя 5 последовательных шагов:

Шаг 1: Определить проблему

  • Что произошло?
  • Как проявляется проблема?
Шаг 2: Собрать информацию
  • Действительно ли проблема существует?
  • Как долго проблема существует?
  • На что эта проблема влияет?

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

Шаг 3: Определить возможные причинные факторы

  • Последовательность каких действий приводит к проблеме?
  • При каких условиях она возникает?
  • Есть ли другие сопутствующие проблемы?

Чем больше мы определим причинных факторов, тем лучше. Часто мы выводим один-два и останавливаемся. Но разве нам хочется застрять на наиболее очевидных факторах? Поэтому копаем глубже!

Шаг 4: Определить Root cause(s)

  • Почему проблема возникла?
  • В чем состоит истинная проблема?

Шаг 5: Предложить и внедрить решение

  • Как избежать повторения проблемы?
  • Как будет имплементировано решение?
  • Кто будет за него отвечать?
  • Какие риски?

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

CATWOE

Полезная методика при сборе информации о проблеме. Может быть использована в процессе RCA. Главный принцип заключается в декомпозиции проблемы на различные зоны влияния. Аббревиатура, собственно, и несет в себе идентификацию зон влияния, а именно людей, процессов и среды.

Области использования: умеренно сложные и сложные проблемы.

CustomersКто они, и как проблема на них повлияет?
ActorsКто вовлечен в проблему? Кого потребуется привлечь для ее решения? Что может повлиять на успешность их действий?
Transformation ProcessКакие процессы либо системы затронуты проблемой?
World ViewКакова общая картина? Существуют ли более глобальные последствия?
OwnerКто владеет процессом или ситуацией? Какую роль он(и) сыграют в решении?
Environmental ConstraintsЕсть ли ограничения, которые могут повлиять на конечный успех?

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


Никто свои страданья не сочтет
Столь малыми, чтоб добиваться больших.
Из честолюбия.

Любой алгоритм анализа и решения проблемы начинается с фундаментального — действительно ли то, что мы считаем проблемой, таковой является? Формулировать ответ рекомендуется письменно. Тем самым вы формализируете и структурируете мысли, находите более емкие и точные определения, чем если бы строили образ проблемы в воображении. А задавать течение мыслей помогут следующие методики.

5 Why

Одна из наиболее популярных методик по определению причин проблемы. Очень часто весь RCA сводится к ней одной. Преимущества в простоте и скорости.

Области использования: простые и умеренно сложные проблемы.

Модель «5 Почему» использует 6-шаговый флоу:

Шаг 1. Собрать команду
В обсуждении должны участвовать те, кто имеет непосредственное отношение к проблеме.

Шаг 2. Определить проблему
Если она не была определена ранее. Определение должно быть коротким, с которым согласны все члены команды.

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

Шаг 4. Оставшиеся «Почему?»
На полученный ответ снова задайте «почему?». Продолжайте, пока основная проблема не будет найдена. Цифра 5 — величина не абсолютная. Вопросов может быть как больше, так и меньше. Вместе с тем, вы можете составлять несколько полос запросов — на каждый полученный ответ выводить свой флоу.

Шаг 5. Превентивный план
Команда выявила первопричину — самое время обсудить список мер, дабы избежать повторения проблемы в будущем

Шаг 6. Анализ
Самый важный этап. Следите, насколько эффективными были предпринятые меры: помогли ли они избавиться или снизить влияние проблемы. Если мы не смогли добиться поставленной цели, необходимо повторить процесс, чтобы убедиться, что первопричина была найдена правильно.

Советы:

  1. Старайтесь переходить быстро от ответа к следующему вопросу. Это позволит определить общую картину произошедшего прежде, чем ваше сознание составит суждение о проблеме.
  2. Когда вопрос «Почему?» не дает полезного ответа и вы не можете продолжать, скорее всего, вы дошли до первопричины.

Будьте внимательны во время разбора сложных и критических проблем. «5 Почему» может увести вас по пути одной-двух логических цепей, в то время как в действительности их значительно больше. Для таких проблем более эффективными могут оказаться Cause and Effect Analysis или Failure Mode and Effects Analysis, которые я рассмотрю ниже.

Drill Down

Существуют проблемы с множеством фактором и комплексом причин. Велика вероятность запутаться, выявить ошибочные причины и составить некорректный план, выступая с шашкой наголо. Поэтому разумнее будет их разбивать. Для разбивки сложносоставных проблем есть очень простая, но действенная методика — Drill Down, которую можно использовать при выявлении причин в RCA.

Области использования: сложные проблемы.

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

Если у вас недостаточно знаний о проблеме, вернитесь к рассмотренной ранее методике CATWOE, чтобы взглянуть на нее с разных перспектив. Кроме того, Drill Down будет еще эффективнее в связке с «5 Why».

Cause and Effect Analysis

Чем больше составных частей у проблемы, тем сложнее решение. Как составить диаграмму, при анализе которой мышление будет двигаться по заданной цепи, не упуская важных частей? Возможно, стоит прибегнуть к метафоричной модели. Одной из таких является «Fishbone Diagrams», также известная как Cause and Effect Analysis.

Области использования: сложные проблемы.

Шаг 1: Определить проблему

Запишите проблему, с которой столкнулись. Если необходимо, определите вовлеченных лиц, опишите детали — где и когда она произошла. Это и есть голова нашей «рыбы». Проведите от нее горизонтальную линию — «скелет». На него-то мы и будем нанизывать факторы, оказывающие влияние. Главное — корректное определение проблемы. И снова же советую обращаться к «CATWOE».

Шаг 2: Изучить основные факторы

Не ограничивайте воображение в выборе факторов. Системы и оборудование, организация и документация, люди и нелюди, черная и белая магия — все это в большей или меньшей степени может оказывать влияние на проблему. Чем больше вы охватите, тем выше вероятность добраться до истины.

В качестве стартовой точки возьмите фреймворк МакКинзи 7S. В его основе теория, согласно которой для успешной работы организации необходимо следить за функционированием 7 взаимосвязанных элементов: Strategy, Structure, Systems, Shared values, Skills, Style and Staff.


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

Failure Mode & Effects Analysis (FMEA)

Изучение всех возможных негативных сценариев на этапе планирования — главное оружие в нашем арсенале. Во-первых, мы решаем проблему значительно дешевле, чем она могла бы стоить впоследствии. Во-вторых, растем профессионально. Плюс ко всему, намного лучше вникаем в рабочие процессы. Давайте рассмотрим схему на примере root cause.

Области использования: умеренно сложные и сложные проблемы.

Process step: Как и прежде, первым шагом будет определение задачи.

Potential Failure Mode: Выявляем потенциальные проблемы, которые могут возникнуть в процессе.

Potential Failure Effects: Какое воздействие потенциальные проблемы могут иметь?

Severity: Оцениваем «тяжесть» проблемы по десятибалльной шкале.

Potential Causes: Для каждой failure выводим root cause(s) (а определить их поможет RCA).

Occurrence: Оцениваем вероятность возникновения по шкале, где 10 — наиболее вероятно.

Current controls: Существующие меры для пресечения возникновения проблемы.

Detection: Оцениваем уровень детекции существующими мерами по шкале, где 10 — наименьший уровень. То есть, значение 10 будет значить, что существующие меры совершенно не способны справиться с проблемой.

RPN (Risk Priority Number): Приоритет риска. Высчитывается по формуле RPN = Severity * Occurrence * Detection.

Action Recommended: Поинты для снижения вероятности возникновения (Occurrence) или повышения уровня детекции (Detection).

Responsible: Ответственный(е) за выполнение.

Actions Taken: Предпринятые меры.

Предпринятые меры — не завершение процесса. Каждый action проходит ту же стадию оценки на Risk Priority Number до тех пор, пока проблема не будет считаться решенной.

Главная задача — разобрать проблему на потенциальные точки сбоя по приоритету (RPN). Сбой с самым высоким RPN является целевым. Весь процесс делится на основные десять шагов, но является цикличным:

Kaizen

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

Kaizen нацелен на продуктивность, эффективность и снижение потерь. Потери включают в себя несколько форм:

  • Movement — бесполезные действия;
  • Time — потраченное без пользы время;
  • Defects — сбои, влекущие повторную работу;
  • Over-processing — излишняя работа;
  • Variations — излишние варианты при удовлетворительном стандартном.

Я предлагаю следующий подход использования системы Kaizen:

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

2. Раз в месяц (периодичность может видоизменяться) потратьте некоторое время для обнаружения областей, где у вас происходят потери (вы можете начать процесс с себя, а убедившись, что методика работает, перенести ее на команду). Записанные в журнал идеи используйте в качестве входных данных, а таблицу Forms of Waste — как чеклист. Подумайте над тем, как избавиться от потерь.

3. Спланируйте, когда будут сделаны изменения. Не бросайте все карты сразу на стол — польза от изменений должна быть отслежена и проанализирована. Иначе как вы узнаете, что именно принесло пользу? Не упускайте из внимания влияние ваших изменений на другие области.

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

Я начал с того, что Kaizen, скорее, можно отнести к философии, чем инструменту. Поэтому и его реализаций насчитывается великое множество. К примеру, вы можете структурировать и собственное развитие по Kaizen:

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось4
До обраногоВ обраному7
LinkedIn



31 коментар

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

«Kaizen» часто згадувався у книжці Сазерленда по Scrum.

Для решения задач какой сложности используется RCA?

Интересная статья.
Мне приходилось заполнять RCA форму в которой была использована методика 5 Why, было интересно почитать какие еще методики существуют.

Задолго до вас была разработана методика, которая благодаря задейстованию одновременно всех бродкаст-каналов является самой популярной на сегодня тактикой решения проблем ASAP, независимо от того как долго они копились под ковром.

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

не дай бог попасть на проект где это заимплеменчено

Спасибо за статью!

Интересно, а что происходит до того, как

столкнувшись с проблемой, мы начинаем искать способы воздействия — методики

как Вы определяете, что столкнулись с проблемой?

как Вы определяете, что столкнулись с проблемой?

Да это проблема.

Ходит как проблема, плавает как проблема, крякает как проблема.

Единственно проблема нет чётких критериев «как проблема».

Разумеется. А между прочим, критерий есть: проблема — это противоречие, которое намерены решить. Например, когда расхождение желаемого с действительным пытаются решить... завуалировав действительное в отчётах. Соответственно, пока не появилось намерения решить, и проблемы не было. А было противоречие.

То есть, способ решения проблемы может прямо зависеть от способа, метода или даже цели ее определения?

Больше скажу, пока нет решения — проблему создавать запрещено. Решение по дефолту — наказать того, кто её создал.
Пример: у полиции проблем с преступностью нет. Проблемы создают те, кто заявляет о преступлении.

Проблема — это не всегда что-то плохое, это скорее разрыв между состоянием А и состоянием Б, который необходимо преодолеть

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

Если не известны А и Б, значит нет проблемы) Хотя это, конечно, зависит от постановки задачи: ведь проблемой может быть отсутствие проблемы, но и в этом случае, кажется, состояние Б — известно))
Гораздо чаще бывает так, что А и Б — известны, но вот почему не получается достичь Б — сложно определить. Минимальная польза методик, возможно, сотоит в том, что они позволяют более широко посмотреть на систему, выйти за привычные рамки. Например, очень условно, можно искать проблемы в коде, или грешить на чью-то квалификацию — определять тривиальные причины. Но реальная причина может быть в том, что кому-то не выгодно завершать проект. И ставить подобные вопросы, даже самому себе, — бывает очень сложно.

Да, если А и Б известны, то проще. Иногда бывает, что несоответствие ожиданий результату возникает и из-за неопределенности ожиданий, неопределенного Б. Проблемы только теоретически нет в таком случае, возможно мы ее не понимаем. Определение ожидаемого результата может быть ключем к решению проблемы, например, если выясняется, что ожидаемого результата нет, тогда проблема именно в отсутствии или невозможности определения Б. Такую проблему и решать нужно по-другому, исходя из —

Если не известны А и Б, значит нет проблемы)

признание наличия болезни-первый шаг на пути к ее исцелению...

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

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

Как вы понимаете что чем-то больны? Как минимум два варианта:
— вам чтото не нравится
— чтото не нравится окружающим

В общем смысле, если кому-то, даже всем, что-то не нравится, это говорит только, что им это не нравится. Это совсем не говорит, что что-то нужно менять. Неужели вы будете менять что-то всякий раз, когда кому-то, даже Вам, что-то не нравится? Это же путь к неврастении. А вот спрашивать «почему» целесообразно, согласен. Что после «почему?»

В общем смысле, если кому-то, даже всем, что-то не нравится, это говорит только, что им это не нравится

верно, это сигнал

Это совсем не говорит, что что-то нужно менять

так точно, но сигнал надо не пропустить и понять что его вызывает

Неужели вы будете менять что-то всякий раз, когда кому-то, даже Вам, что-то не нравится?

менять нет, но задать вопрос «почему он так сказал» лишним не будет

Это же путь к неврастении

от чего же? понимание почему что-то происходит ведет к неврастении? по-моему как раз наоборот))

Что после «почему?»

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

Вопрос, как раз, о промежутке между кому-то что-то не нравится и действии. Как понять, что проблема существует, прежде чем приняться менять что-то. Заявление одного или даже всех о недовольстве говорит только, как мы согласились, о их неудовлетворенности, а удовлетворить всех — утопия и не может быть целью. То есть, возвращаясь к моему комментарию, проблема несоответствия А и Б, желаемого и реального результата, решаема только, если эти А и Б известны. Если ожидаемый результат неизвестен, то проблема не может считаться решаемой. Переливание из пустого в порожнее.

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

Как понять, что проблема существует, прежде чем приняться менять что-то

Есть сигнал про что-то (не говорю проблема), вы поспрашивали «почему» и поняли причину, теперь вы задаетесь вопросом — что будет если это не устранить? какой «worst case» сценарий/сценарии и какая вероятность наступления события. Ну и дальше принимаете решение что это проблема или нет. Разве это не обыденный способ реакции на любые события?

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

Вы можете придумать, что будет если тоб что вам сказали — правда? если можете — то результат известен, даже если это выдумка

Либо же как вариант, один из других способов решения проблем

Вы как-то от определения проблем к решениям прыгаете

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

то что вы описали это поиск в глубину а есть еще поиск в ширину

Движение в сторону верных решений, как раз, не смотря, на недовольство кого-то там со стороны.

то, что принятое решение верное — может быть тоже ошибкой а не верным направлением и вызывать новые проблемы)

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

Направление движения в будущее вы выбираете проактивно, реактивно решая по дороге возникающие проблемы/сигналы и корректируете направление движения в будущее, после решения этих реактивных проблем.

Проактивно пишут всяческие миссии компании, инициируют новые продукты, ставят себе цели по саморазвитию на 5 лет, мечтают кем будут когда вырастут...

Да, согласен, такая модель работает. И возвращаясь к тому вопросу — как определить что проблема реально существует, если А и Б, ожидаемый и полученный результат, неизвестны? Тогда никак?

Проактивный векторный подход может быть альтернативой этому никак.

если А и Б, ожидаемый и полученный результат, неизвестны?

Если мы не знаем куда нам идти — любой путь будет правильный, надо просто идти © {Алиса в стране чудес}

Проактивный векторный подход может быть альтернативой этому никак.

никто не спорит

Где-то я уже такое слышал. Про пистолет.

Підписатись на коментарі