Возможно ли отказаться от использования классического risk registry?
Практика показывает, что во многих проектах (особенно работающих по методологии Agile), традиционный подход с полноценными (выделенными) шагами по идентификации, анализу, планированию, мониторингу и контролю рисков, не пользуется популярностью.
Обзоров традиционного процесса достаточно много (например, habr.com/ru/post/55105) и поэтому не вижу большого смысла пересказывать его содержание в этом посте.
Причиной же такого «халатного отношения» к этому процессу может быть то, что многие не понимают зачем уделять ему отдельное внимание и время. Кто-то может парировать, что «вы просто не умеете его готовить» и что на обновление регистра рисков требуется совсем немного усилий, «минут 10». Так может быть и есть в небольшой сплоченной команде, в которой все друг друга хорошо понимают. Однако нужен ли формальный регистр рисков для такой команды? В других случаях это обычно активность, выполняемая по запросу «сверху», нудный и затянутый процесс, в котором непросто увидеть пользу.
Дополнительно про трудности вокруг классического процесса управления рисками и о способах их преодоления можно почитать например в habr.com/ru/post/128370
Обычно такой процесс выстраивается вокруг risk registry, регламентирующего правила работы с рисками. Насколько нужен такой артефакт в его классическом виде и нельзя ли упростить его?
В первую очередь регистр рисков выполняет функции актуализации и контроля статуса рисков.
Актуализация рисков необходима для того, чтобы все участники и заинтересованные лица имели одинаковое представление о списке потенциальных проектных проблем. При этом существенно, чтобы он был сформирован в порядке приоритета. Определение приоритета (рейтинга риска) обычно происходит путем заполнения таких атрибутов как вероятность (probability/likelihood) & влияние (impact) в регистре рисков, после чего список рисков упорядочивается для того, чтобы определить самые важные. Однако возможно ли адекватно оценить вероятность и влияние для технического риска? На мой взгляд, это проблема такого же рода, как сделать точную оценку для какой-либо задачи. Если известно как ее делать, то можно точно сказать сколько часов требуется на реализацию. А если нет, то это это может быть и день, и два, и более. Поэтому значение этих атрибутов обычно лишь численное выражение «ощущений» участников проекта, некоторая «экспертная оценка». Имеет ли тогда смысл «угадывать» эти показатели и не лучше ли сразу приоритизировать риски относительно (друг друга), т.е. сразу формировать список рисков в порядке приоритета (рейтинга)? При сравнении рисков друг с другом возможно ввести «шкалу» сравнения, которая облегчит определение рейтингов рисков относительно другого (или других). Такого рода «шкалу» для рисков, можно ввести на основании объема имеющейся информации. Например, для рисков связанных с внешними зависимостями:
Для рисков, связанных с реализацией технических задач:
Возможны и другие варианты введения критерия для сравнения рисков.
А есть ли необходимость отдельно контролировать риски в Agile команде? Как мне кажется каждый «зрелый» программист или менеджер прекрасно понимают важность того, что «на грабли лучше не наступать». При этом многие имеют представление о том, с какими потенциальными проблемами можно столкнуться во время выполнения той или иной задачи в рамках их поля деятельности. Поэтому отдельная функция контроля с помощью регистра рисков возможно избыточна.
Вместо этого действия/меры по митигации рисков можно включить в бэклог. Например, если в проекте есть риск связанный с интеграцией внешней библиотеки, то задачу по исследованию сложности интеграции можно включить в бэклог ближайшего спринта. Результаты исследования позволят уточнить и вероятность, и влияние такой задачи на результаты проекта.
Дополнительным преимуществом такого подхода будет то, что функция контроля и обновление информации по рискам будут выполняться автоматически, по результатам спринта.
Применение изложенных выше идей может позволить заменить классический регистр рисков простым списком рисков. Во многих проектах, где мне приходилось работать, такое упрощение происходило «естественным» путем. Было бы очень интересно узнать насколько эти идеи выглядят обоснованными и соответствуют опыту других.
Отдельно хотел бы отметить, что данный пост посвящен только проектных рисках и не касается организационных рисков (управление которыми возможно нуждается в отдельном анализе).
Обзоров традиционного процесса достаточно много (например, habr.com/ru/post/55105) и поэтому не вижу большого смысла пересказывать его содержание в этом посте.
Причиной же такого «халатного отношения» к этому процессу может быть то, что многие не понимают зачем уделять ему отдельное внимание и время. Кто-то может парировать, что «вы просто не умеете его готовить» и что на обновление регистра рисков требуется совсем немного усилий, «минут 10». Так может быть и есть в небольшой сплоченной команде, в которой все друг друга хорошо понимают. Однако нужен ли формальный регистр рисков для такой команды? В других случаях это обычно активность, выполняемая по запросу «сверху», нудный и затянутый процесс, в котором непросто увидеть пользу.
Дополнительно про трудности вокруг классического процесса управления рисками и о способах их преодоления можно почитать например в habr.com/ru/post/128370
Обычно такой процесс выстраивается вокруг risk registry, регламентирующего правила работы с рисками. Насколько нужен такой артефакт в его классическом виде и нельзя ли упростить его?
В первую очередь регистр рисков выполняет функции актуализации и контроля статуса рисков.
Актуализация рисков необходима для того, чтобы все участники и заинтересованные лица имели одинаковое представление о списке потенциальных проектных проблем. При этом существенно, чтобы он был сформирован в порядке приоритета. Определение приоритета (рейтинга риска) обычно происходит путем заполнения таких атрибутов как вероятность (probability/likelihood) & влияние (impact) в регистре рисков, после чего список рисков упорядочивается для того, чтобы определить самые важные. Однако возможно ли адекватно оценить вероятность и влияние для технического риска? На мой взгляд, это проблема такого же рода, как сделать точную оценку для какой-либо задачи. Если известно как ее делать, то можно точно сказать сколько часов требуется на реализацию. А если нет, то это это может быть и день, и два, и более. Поэтому значение этих атрибутов обычно лишь численное выражение «ощущений» участников проекта, некоторая «экспертная оценка». Имеет ли тогда смысл «угадывать» эти показатели и не лучше ли сразу приоритизировать риски относительно (друг друга), т.е. сразу формировать список рисков в порядке приоритета (рейтинга)? При сравнении рисков друг с другом возможно ввести «шкалу» сравнения, которая облегчит определение рейтингов рисков относительно другого (или других). Такого рода «шкалу» для рисков, можно ввести на основании объема имеющейся информации. Например, для рисков связанных с внешними зависимостями:
- если есть достоверная информация, то рейтинг риска меньше
- если есть информация и есть основания считать ее верной (но неподтвержденной), то риск меньше
- если есть информация, но нет оснований ей доверять, то риск больше
Для рисков, связанных с реализацией технических задач:
- если нужно сделать что-то известное (т.е. «мы уже делали это»), то рейтинг риска меньше
- если возможно обобщить и провести с чем-то аналогию (т.е. «это похоже на»), то рейтинг риск меньше
- если что-то неизвестное, то риск больше
Возможны и другие варианты введения критерия для сравнения рисков.
А есть ли необходимость отдельно контролировать риски в Agile команде? Как мне кажется каждый «зрелый» программист или менеджер прекрасно понимают важность того, что «на грабли лучше не наступать». При этом многие имеют представление о том, с какими потенциальными проблемами можно столкнуться во время выполнения той или иной задачи в рамках их поля деятельности. Поэтому отдельная функция контроля с помощью регистра рисков возможно избыточна.
Вместо этого действия/меры по митигации рисков можно включить в бэклог. Например, если в проекте есть риск связанный с интеграцией внешней библиотеки, то задачу по исследованию сложности интеграции можно включить в бэклог ближайшего спринта. Результаты исследования позволят уточнить и вероятность, и влияние такой задачи на результаты проекта.
Дополнительным преимуществом такого подхода будет то, что функция контроля и обновление информации по рискам будут выполняться автоматически, по результатам спринта.
Применение изложенных выше идей может позволить заменить классический регистр рисков простым списком рисков. Во многих проектах, где мне приходилось работать, такое упрощение происходило «естественным» путем. Было бы очень интересно узнать насколько эти идеи выглядят обоснованными и соответствуют опыту других.
Отдельно хотел бы отметить, что данный пост посвящен только проектных рисках и не касается организационных рисков (управление которыми возможно нуждается в отдельном анализе).