De omni re scibili et quibusdam aliis
В менеджерской среде говорят — управлять проектом, значит управлять его рисками. То есть, эта штуковина достаточно низкоуровневая и основополагающая.
Когда я в детстве пытался спросить маму, что будет, если случится та или иная беда, она всегда на меня шикала, не думай и не говори о плохом, накаркаешь. Ошибка мышления в данном случае в том, что руководителю проектов нужно думать о плохом в силу профессии, причём регулярно (не реже раза в неделю).
Риск — это неопределенное событие или условие, наступление которого отрицательно или положительно сказывается на целях проекта
PMBOK
Идентификация рисков
Перед тем, как приступать к идентификации рисков, нужно принять вот, какую мысль. Неизбежно в процессе сессии идентификации в коллективе обнаружится юморист, который будет предлагать риски, вроде землетрясения, наводнения и отказа мирового сообщества от долларов. На самом деле, работа с такими рисками — задача вышестоящего руководства. В рамках же проекта стоит сосредоточиться на рисках, на которые мы более-менее можем влиять.
В рамках идентификации рисков вы садитесь с командой и думаете о плохом. Накидываете все события, которые могут отрицательно или положительно (бывает и такое) повлиять на параметры проекта. Для упрощения процесса, вот вам группы рисков:
- Технические
- Функциональные
- Качество
- Управление проектом и организационные
Разделение на группы достаточно условное. Давайте разберём каждую из этих групп.
Технические риски
Риски, обусловленные техническими факторами. Сюда относятся особенности информационных систем заказчика, с которыми нужно интегрироваться и другие фишки айти-ландшафта. Здесь же ограничения используемых языков программирования, фреймворков, которые могут так или иначе саффектить. Здесь же вероятность различных аварий, как на нашей стороне, так и на стороне заказчика.
Функциональные риски
Риски, обусловленные невозможностью контроля над функционированием команд. Сюда относятся больничные сотрудников и незапланированные отпуска в связи с личными форс-мажорами.
Качественные риски
Трудности тестирования отдельных аспектов системы или системы целиком, риски плохого качества тестирования из-за разных факторов. Сюда же риски, вызванные невозможностью подключения QA к проработке требований.
Риски управления проектом и организационные
Тут менеджерские риски. Медленные согласования, трудности в подготовке проектных артефактов, особенности подготовки документов для госов. Отпуска и больничные сотрудников команды заказчика, трудности с их сбором для проведения совещаний.
Идентифицировав риски, заносите их в реестр. Пока без оценок, только заголовки. Не забудьте озадачить идентификацией рисков коллег, участвующих в проекте, но не являющихся частью команды разработки, вроде аккаунтов и деливери-менеджеров. Девопса привлеките, он тоже может накинуть рисков.
Анализ и приоритизация рисков
Для каждого риска нужно определить вероятность срабатывания и влияние на проект. Для этого строим матрицу, можно 2×2, лучше 3×3:
| Лёгкое влияние | Среднее влияние | Тяжёлое влияние | |
| Маловероятно | Невысокий (0) | Невысокий (1) | Средний (2) |
| Вероятно | Невысокий (1) | Средний (3) | Тяжёлый (4) |
| Весьма вероятно | Средний (2) | Тяжёлый (4) | Тяжёлый (5) |
В соответствии с матрицей проставляем каждому риску вес, от 0 до 5.
Упорядочиваем риски по весу, получаем приоритизированный реестр рисков.
Выработка стратегии и тактики работы с рисками
После того, как мы выявили и приоритизировали риски, надо решить, что мы с ними будем делать. В первую очередь нужно понимать, что существует четыре основные стратегии обработки рисков:
- Уклонение;
- Смягчение;
- Делегирование;
- Принятие.
При уклонении мы принимаем меры, чтобы риск не сработал. При смягчении — чтобы он слабее саффектил на параметры проекта. При делегировании — передаём риск за пределы команды (например, заключаем договор страхования на случай пожара в серверной). При принятии мы признаём, что стратегии нет, риск мы принимаем и готовы к последствиям.
Потом для каждого риска пишем «План А». То есть, что мы делаем, чтобы исполнить стратегию. Делается для всех рисков, кроме тех, для которых стратегия — принятие.
Потом пишем для каждого риска триггер. Это событие, по которому мы определяем, что риск сработал.
Потом для каждого риска пишем «План Б». То есть, что мы делаем, если риск сработает.
Для каждого риска прописываем владельца. Это тот, кто контролирует, сработал ли риск и вообще, отвечает за него. Постарайтесь не для каждого риска писать себя, делегировать контроль рисков команде нормально.
Можно ещё оценить каждый риск в деньгах, но чаще всего это будет пальцепотолковый метод.
Мониторинг рисков
Даже если ни один риск в течение недели не сработал, имеет смысл в пятницу помедитировать над реестром рисков и внести корректировки.
В остальном, мониторинг самоочевиден. Применяете «планы А», следите за триггерами. Если риск сработал, применяете «план Б». Там, где мониторинг несамоочевиден, анализируете отклонение тренда показателя.
Также нужно в ходе мониторинга обязательно выявлять вновь появившиеся риски и вносить их в реестр, оценивать, приоритизировать, но это вы уже умеете.
Если вы всё же решились на пальцепотолковый метод оценки стоимости рисков, нужно делать ещё одно упражнение — в конце месяца стоимость всех не сработавших рисков обнулять, а сработавших — относить на косты проекта.
Разбор выученных уроков
Проект по определению, конечен, как и процесс работы с рисками. И после того, как проект завершён, при написании постмортема нужно с большим вниманием отнестись к выученным урокам по управлению рисками. Где перебдели, где недобдели, где принятый процесс несовершенен.
Если в компании есть проектный офис, имеет смысл озаботиться ведением справочника типовых для данной компании рисков. Завершение проекта — повод пополнить этот справочник.
Заключение
В целом, это всё, что нужно знать об управлении рисками. Вовлекайте как можно больше людей в процесс идентификации рисков, здраво их оценивайте, своевременно мониторьте и не забывайте обновлять реестр рисков и управление рисками можно будет считать освоенным.
