Риск — слово, которое воспринимается в русском языке исключительно в негативном ключе. Тем не менее, в менеджменте это понятие имеет как отрицательную, так и положительную окраску.
Понятие риск подразумевает позитивное или негативное по влиянию на проект событие, которое может произойти или не произойти.
Управление рисками — неотъемлемая часть проектного менеджмента в IT: здесь рассматриваются вероятности наступления событий, которые могут случиться, а могут и нет.
Сила управления рисковыми ситуациями — визуализация резервов, формулирование планов на случай А и В, а также назначение ответственных (снижение нагрузки с менеджера проектов).
В книге Эдварда Йордона «Путь Камикадзе» есть интересная мысль — к любому проекту стоит относиться как к заведомо провальному. И уже исходя из этого принятого априори факта выстраивать стратегию развития, то есть продумывать набор тех действий, которые помогут сделать проект успешным.
Работа с рисками в отрасли информационных технологий
Пример негативного риска — из команды выдернут важного сотрудника.
Пример позитивного риска — что-то могло не случиться, но мы сконцентрировали усилия, все продумали, сделали чуть больше — и это произошло.
Управление рисками сводится к двум понятным парадигмам: мы пытаемся увеличить вероятность возникновения положительных ситуаций из числа тех, которые могут произойти (или нет) и снизить вероятность провальных исходов.
Базовый инструмент работы с рисками — реестр. Рекомендуется вести его как для положительных, так и для отрицательных событий в разных таблицах. А план управления рисками включать в общий план управления проектом.
NB: До 90% значимых угроз должно быть нивелировано, отсюда следует, что 10% рисков может сработать.
К числу таких угроз можно отнести те, о которых мы не догадываемся или которые невозможно взять под контроль, предотвратить или разрешить (например, изменение в законодательстве или всеобщий карантин).
Внедрение управления рисками
На каждом (еженедельном) совещании нужно уделять время для мониторинга текущей обстановки.
Например: «Коллеги, что у нас с рисками? Что-нибудь новое возникло? А может что-то из старого можно вычеркнуть?»
Или спрашивать у людей про плохое: «Что у нас может пойти не так? Я сейчас вас не ругаю и не спрашиваю, почему вы «накосячите». Расслабьтесь и подумайте, что вам может помешать, а что может помешать всем нам, чтобы это вовремя предотвратить».
Как идентифицировать риски
Сесть и посмотреть в «хрустальный шар», используя принципы проектного менеджмента — командность и проактивность. То есть размышлять не в одиночку, а привлекать для этой цели команду.
Задача ставится простая: выписать все, что придет в голову. Даже если это кажется странным и совершенно несбыточным. Достаточно помнить, как весь мир закрыли на карантин на несколько месяцев. Такую ситуацию не мог предугадать никто, тем не менее, она произошла.
Как идентифицировать возможные риски и степень их вероятности:
- Посмотреть документы (например, планы прежних проектов, «извлеченные уроки»);
- Обсудить с коллегами (PM, HR, финансы);
- Обсудить с командой;
- Спросить у заказчика, спонсора;
В качестве примера приведем проект длительностью в полгода, с командой в 7 человек — здесь можно идентифицировать более 100 возможных рисков. Тем не менее, не всеми нужно управлять и не все нужно детально контролировать. Анализ и сортировка рисков происходит на следующем этапе — качественной оценки. Сейчас работает другой принцип — «вали кулем, потом разберем».
Качественная оценка
На этом этапе мы сортируем возможные вероятности по степени значимости: какие из рисков очень значимы, а какие не очень. Оцениваем не в процентах, не в деньгах, а в категориях — большое, среднее, маленькое.
Пример качественной оценки рисков:
| Риск | Вероятность | Влияние | Значимость |
| Уход сотрудника с проекта | низкая | высокое | средняя |
| Недостаточная пропускная способность интернет-канала | средняя | низкое | низкая |
| Отсутствие вовлеченности топ-менеджмента со стороны клиента | высокая | низкое | средняя |
| Изменение требований в конце проекта | высокая | высокое | высокая |
| Отмена командировки в офис клиента | низкая | низкое | низкая |
После того, как закончили проводить качественную оценку — смотрим на последнюю колонку и решаем — какие риски мы оставляем и будем дальше с ними работать.
Очевидно, что берем значимые и не берем самые незначительные.
Что делать со средними рисками? Решаем буквально — либо берем, либо не берем, в зависимости от конкретной ситуации и решения проектного менеджера.
Пример. Если менеджер ведет флагманский (важный для компании) проект, то стоит брать в работу и средние по значимости риски.
Если это обычный проект, такой, которых много — можно брать только значимые риски.
В итоге, из всей той простыни, которую мы идентифицировали ранее, остается небольшая часть, с которой реально можно будет работать.
Количественная оценка
Ключевая задача — рассчитать резервы.
Здесь рождается вероятность и влияние. Вероятность оценивается в процентах, влияние — в деньгах. Произведение одного на другое дает нам значимость.
Ключевой показатель количественно оценки — EMV (Expected Monetary Value) — это ожидаемое денежное значение, другими словами — сколько будет стоить нечто.
EMV = P * I
P — probability — вероятность
I — impact — влияние
Для каждого риска оцениваем его P (вероятность — в процентах) и его I (влияние — в деньгах или времени), в случае если этот риск реализуется.
Если вы корректно оценили вероятность, то все риски разом никогда не сработают. Сработает только часть, с остальной части рисков можно и заимствовать резервы.
Планируем реагирование на риски
После проведения качественной и количественной оценки приступаем к планированию реагирования. Для этого вводим понятия План А и План B.
На языке проектных менеджеров, План А называется Contingency Plan (план непредвиденных ситуаций), План B — Fallback Plan (план отступления).
План А — это то, что мы сделаем прямо сейчас, чтобы риск не сработал, либо сработал но с наименьшими последствиями. Другими словами — действия для снижения вероятности возникновения риска.
План B — этот план вступает в силу, если не сработал План А, то есть событие произошло.
Другими словами, План B делается для остаточных рисков.
Триггер риска
Триггером риска называют симптом, то есть некие действия, по которым можно судить о возможности наступления риска.
Пример: Junior разработчику поставили большую задачу. Менеджер проекта решает, что если в течении двух недель разработчик затягивает сроки, значит это триггер.
Хозяин риска
Пример риска: Junior разработчик может «завалить» кусок работы.
Хозяином этого риска может быть тимлид или технический лидер. То есть тот человек, который увидит симптом (триггер).
Хозяин риска смотрит на триггер и это фактически означает, что План А не сработал, нужно задействовать План B.
Наблюдаем за рисками
Отслеживаем изменения событий в течении проекта на собраниях с командой:
- открываем новые
- закрываем старые
- меняем старые на более свежие
Как не надо делать: единожды идентифицировать риски и больше не следить за ними. Это привьет всей команде отвращение к риск-менеджменту.
