14. Управление рисками

Работа с рисками ведется в несколько этапов, которые изображены на этой схеме:

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

Для стимуляция мозгового штурма рекомендуется использовать один из следующих риск-воркшопов:

SEI Taxonomy-Based Risk Identification – таксономия рисков и опросник от Software Engineering Institute
Дисциплина Управления Рисками MSF вер 1.1 – более легковесная версия категоризации софтверных рисков от Microsoft

Риски надо визуализировать, чтобы их знала вся команда (и заказчик) и полноценно участвовала в управлении ими. Самый плохой вариант сделать Excel-файл с рисками (в самом укромном уголке) и при провале проекта сказать: «Этот риск у меня есть в реестре под номером 37». Самый гибкий вариант – сделать доску с рисками и отслеживать их жизненный цикл.

Пример визуализации рисков:

Но рисками важно не переборщить, особенно привлекая к этой работе заказчика, ведь ему и команде может показаться, что проект состоит из одних потенциальных проблем. Очень ярко эта ситуация проявляется в командах, которые до этого не проводили подробный анализ рисков, а просто с завязанными глазами наступали на грабли. Возьмем только три градации для оценки вероятности и угроз (сколько ущерба он принесет) риска, при этом не будем использовать денежные оценки:

Безусловно, максимум внимания необходимо уделить «красным» рискам, мало того, что они наиболее вероятны, но и ущерб от них обещает быть максимальным. Активности, связанные с оперативным мониторингом рисков и коррекцией последствиями рисков очень удобно проводить на ежедневных скрам-митингах: теперь команда будет оперировать не виртуальными проблема, а конкретными рисками.

Матрица рисков для визуализации рисков на одном графике

Матрица риска создается для визуализации рисков проекта. На диаграмме все риски делятся по степени их вероятности и последствий, так что наглядно видно, какой сценарий будет наихудшим.

Матрица риска — это результат анализов и оценок рисков проекта, поэтому она является важным компонентом в управлении проектами. Её удобство состоит в том, что на одном графике:

определены самые серьёзные риски проекта,
ситуация представлена всесторонне,
матрица проста в понимании,
её легко оформить, например, в Excel,
можно работать над мерами по устранению рисков.

Как создать матрицу рисков?

Чтобы создать матрицу, необходимо оценить вероятность возникновения рисков и степень ущерба. Затем отдельные риски вводятся в систему координат в соответствии со значениями на сторонах матрицы.

Оценка вероятности возникновения

Существует пять уровней вероятности, которые отражаются на матрице. Они выражены в процентах:

0-20% — невозможно,
21-40% — маловероятно,
41-60% — возможно,
61-80% — вероятно,
81-100% — весьма вероятно.

Уровень вероятности основывается на количественных данных, которые вы получаете от проекта.

Оценка степени ущерба

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

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

Затем устанавливается эталонное значение: понятное событие, степень ущерба от которого и вероятность наступления вам понятна. От него откладываются другие риски.

Построение диаграммы

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

Для наглядности используются разные цвета: зелёный, жёлтый и красный.

Например, над вашим проектом трудится 5 человек. Каждый из них занимается одной сферой разработки и заменить другого никто в коллективе не может. Кандидатов на рынке труда не так много, потому что ваш проект сложный. В этом случае риск — увольнение сотрудника или его продолжительная болезнь. Это событие застопорит разработку, и вам кажется, что это будет очень высокий ущерб для проекта. Вероятность наступления события зависит как от ваших условий труда и зарплат, так и от амбиций и личности сотрудников. Возможно, вероятность наступления около 21-40%. Таким образом, это средний уровень риска.

Как принимать меры?

На матрице все риски располагаются в разных цветовых зонах:

зелёные — там, где не требуется никаких мер,
жёлтые — риски, которые нужно уменьшить,
красные — это неприемлемые риски, которые прямо угрожают проекту.

Это разделение несколько условно, но делает процесс управления рисками более понятным и прозрачным.

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

Риск из примера выше можно перевести в зелёную зону, если уменьшить вероятность наступления до 0-20%. Сотрудники не захотят уходить без видимых причин, если у них конкурентные зарплаты, хорошие условия в офисе и интересные задачи.

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

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