Техника Root Cause анализа В повседневной работе я часто пр | Knowledge and bacon - Управление знаниями в IT
Техника Root Cause анализа
В повседневной работе я часто применяю фреймворк Root-Cause: когда нужно распутывать сложные, нелинейные причинно-следственные связи.
И кажется её можно применить и к управлению знаниями, например, если вам нужно понять пробелы в знаниях или вы взялись за стратегию.
Например: задерживаем выпуск релизов ← разработчики постоянно недооценивают задачи ← продакт неверно коммуницирует сложность доработок в спецификации/тикете ← продакты из соседних подразделений, чей код затрагивается не вовлечены в описание задачи ← нет обмена знаниями и общих синков продактов.
Значит, к примеру, нужно сделать карту зон ответственности всех менеджеров, описать соприкосновения областей/контракты и отдельно обратить на них внимание, проводить регулярные сессии обмена знаниями.
Пример довольно абстрактный, в реальности у вас будут стрелки не линейные, а много ответвлений и несколько «root cause», например, разрастающийся скоуп, неправильная приоритизация, добавление фич в релиз на ходу, сложный процесс самого релиза и прочее . Для построения таких цепочек полезно использовать Root Cause фреймворк.
Идея в том, что наша проблема - это не проблема, а симптом, мы не чиним ее саму по себе, а we need to go deeper.
Пишете по центру проблему, от нее рисуете стрелки: вверх последствия, вниз - причины. Итерируем по такому дереву несколько раз, добавляем-убираем. Причин обычно будет несколько, можно сосредоточиться на тех, которые ведут к наибольшему числу последствий. Далее придумываем контрмеру на один root causes и пробуем её. Если добились небольшого улучшения — чиним дальше.
Исходя из найденного в ходе такого исследования можно дальше строить метрики эффективности.
Есть еще хак, а как понять, что это root cause?
Визуально верный признак — если много стрелок идут вверх и ничего вниз.
У Хенрика Книберга есть отличная статья про эту технику, там в том числе есть советы, как делать такой анализ в группе, как избежать проблем излишней персонализации, упрощения и кейса «слишком много стрелочек и квадратиков». На картинке как раз пример из статьи.
Техника отлично подойдет для ретроспектив и выученных уроков.
