#осторожноАнглицизмы #осторожноСексизм

Целевая аудитория для этой статьи — представители ИТ сферы, которым волею судьбы выпала задача управлять рисками в их проекте и/или команде, которые не имеют входных знаний по теме статьи или имеют, но так и не уловили ответа на вопрос — И чё?

Матёрым менеджерам здесь будет скучно, но если вы таки знаете пана Мазоха, тоже заходите!

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

Всё, что уже произошло, либо точно не произойдёт (ну ок… скорее всего не произойдёт) — не риск.

Пример первого: заказчик вас кинул и увёл свой бизнес к конкурентам. Это не риск, это факт.
Пример второго: у кастрированного кота родились котята (да, я в курсе, что коты не могут окотиться).

Пример рисков для первого и второго:

Заказчик может уйти к конкурентам, потому что что-то он часто говорит, что соотношение цена-качество в соседней конторе лучше.

Самочка кастрированного кота (ну мало ли) может привести котят, потому что коты не в курсе про институт брака и живут они, к тому же, в частном секторе.

Итак. Откуда берутся котята риски:

Часто их кто-то приносит. Пример: ваш брат заметил уже второй раз у вас во дворе соседского кота Ваську. И как бы заподозрил измену в котячих рядах.

У кого-то сработала интуиция, или по процессам положено: провели брейн-сторм по рискам. Примера здесь не будет, брейн-сторм говорит сам за себя.

На данном этапе мы имеем:

а) риск
б) его источник
в) дату, когда мы о нём узнали

Не будем дураками и запишем в ексель табличку, чего добру пропадать…

Важная оговорка. Риски бывают не только негативными. Может ваш кот таки порадуется котятам как своим. Ну ок, забыли про котов. Пример: вы думали, что у вас нишевый рынок и подняли приложение на домашней тачке, а тут произошёл бум и на 107м пользователе ваш магазин машет всем лапкой 503й.

г) можно ещё одну колоночку, а можно и пропустить. Ибо это judgment.

У риска есть вероятность его наступления (probability of occurrence) и тяжесть последствий (severity of impact). Эти величины лучше прикидывать небольшим, качественно подобранным коллективом. Привлеките к этому процессу SME, к примеру.

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

д) probability: 0.1 — 0.9 (если возникает вопрос, где 0 и 1, перечитайте параграф “К делу”.
е) severity: 1 — 10.

Шкалы выберите так чтоб вам нравилось, think out of borders!

Теперь ответ на вопрос — а зачем же умножать probability на severity.

ё) rate = probability * severity.

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

Предпосылки для Ж (пункта, а не того, о чём вы подумали).
Можно посоветоваться с каким-нибудь менеджером в вашей компании, СЕО или ещё с кем, либо рискнуть и придумать свою систему классификации рисков. Мне здесь снова нравится red — amber — green. То есть вам нужно систему — как по рейту определить цвет.

ж) эта колонка, которая пока без названия, условно, — будем ли мы что-то с этим риском делать. (Там я дальше статью писала, эта колонка упоминается, поэтому назовём её…) Action needed.

Самое время упомянуть стратегии работы с рисками:
Avoid — Transfer — Mitigate — Accept для негативных рисков
Exploit — Share — Enhance — Accept для положительных.

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

На выходе наш спредшит пополнился ещё одной колонкой. С названием мудрить не будем.

з) стратегия

Упс… Мы забыли о самом важном для трейса риска в будущем — ИД. Ну ничего, ексель добрый, позволяет вставить колонку левее первой (или нулевой… Это был краткий тест на то, разраб ли вы и если да, то какой ЯП юзаете).
Я же пишу лонгрид, поэтому моя колонка с ИД будет под буквой И, что символично!

и) ИД.

Далее по всему списку рисков составляем RACI матрицу по таким правилам:
1 каждый риск должен иметь минимум один I.
2 каждый риск (кроме зеленого Action needed) должен иметь минимум по одному A и R
3 С по желанию
4 не более одного А на каждый риск

Далее нам нужно по стратегиям (кроме Accept) написать список Action Items.
Это уже не удобно делать в той же табличке, поэтому заводим отдельную под каждый риск (ИД в помощь). Не забываем про дедлайны.

Там перечисляем те самые нужные действия.

Сводим все AI в одну RACI матрицу.

Самый важный пункт: КОММУНИЦИРУЕМ это всё. Это очень важный этап. Если вы не заручитесь поддержкой коллег касательно вашей стратегии управления рисками, можете сильно попасть в будущем, когда окажется, что просчитались.

Следующий важный пункт. Это вам не DoD, нельзя раз написать и на весь жизненный цикл проекта забыть. Регулярно возвращаемся, смотрим, выполняются ли Action Items, не меняются ли probability и severity.
Советуемся, валидируем, контролируем, управляем.
Вносим новые риски.

Золотое правило: никогда ничего не удаляем из этого документа. Только добавляем и обновляем!!!

Бонус. Самый крутой риск менеджмент, который я видела воочию: “Вы что??? Тьфу-тьфу-тьфу”. (с) При этих словах, директор небольшой ИТ компании постучала по своей голове.
1 правильно постучала (по верному месту, если вы понимаете, о чём я)
2 не будьте как эта директор, документируйте и обсуждайте риски!

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

Всем проектов с рисками в грин зоне!