Управление рисками в ИТ-проекте: матрица вероятности и влияния
«Мы не знали, что API изменится. И никто не знал»
Вы спланировали бюджет, расписали WBS, распределили роли, а через месяц ключевой разработчик уходит в отпуск, API изменили, заказчик затягивает согласование, и план рухнул. В ИТ-проектах риски подстерегают на каждом шагу, и если вы управляете ими «в голове» — вы ими не управляете, вы просто надеетесь, что всё обойдётся. Главный инструмент, который превращает «ой, а я не думал» в «я к этому готов» — это реестр рисков, а внутри него — матрица вероятности и влияния, простая таблица, которая говорит вам, на что тратить время сегодня, а что можно оставить на завтра.
Риск — это не проблема. Проблема — это когда риск уже наступил
Многие путают эти понятия. Риск — это то, что может случиться («ключевой разработчик может уволиться»), а проблема — это то, что уже случилось («ключевой разработчик уволился»). Разница принципиальная: проблему вы тушите, а риск вы предотвращаете или готовитесь к нему, и когда риск наступает, вы не паникуете, а выполняете план. Но чтобы выполнять план, нужно сначала понять, какие риски самые опасные, где реальная угроза, а где просто страшилка, на которую не стоит тратить время. Для этого и нужна матрица вероятности и влияния.
Как работает матрица
По вертикали — влияние, насколько больно нам будет, если риск наступит. По горизонтали — вероятность, насколько велик шанс, что это вообще случится. Пересечение даёт приоритет.
Для ИТ-проекта шкала может выглядеть так: вероятность — низкая (менее 30%), средняя (30–70%), высокая (более 70%). Влияние на сроки — низкое (до 5 дней), среднее (5–14 дней), высокое (более 14 дней). Пересечение даёт четыре зоны. Критическая (красная) — могут сорвать проект, требуют немедленного плана и резервов. Высокая (оранжевая) — требуют активного управления и выделения ресурсов. Средняя (жёлтая) — требуют мониторинга и плана «на всякий случай». Низкая (зелёная) — принимаются без активных действий, но периодически пересматриваются.
Пример из реального ИТ-проекта
Внедряем систему электронного документооборота. Собрали команду, записали риски, оценили.
Уход ключевого разработчика — вероятность 40%, влияние 14–28 дней задержки, зона высокая (оранжевый). Действие: cross-training, документирование, резервный разработчик.
Изменение API 1С — вероятность 30%, влияние 200 часов переделки, зона средняя (жёлтый). Действие: анализ версии до начала, резерв 2 недели.
Сопротивление пользователей — вероятность 50%, влияние снижение NPS и отказ от системы, зона высокая (оранжевый). Действие: обучение, вовлечение лидеров мнения, демо на ранних этапах.
Задержка поставки серверов — вероятность 30%, влияние 14 дней задержки, зона средняя (жёлтый). Действие: заказ серверов за 2 недели до начала тестирования.
Теперь мы знаем, на что тратить время: красное и оранжевое — в первую очередь, жёлтое — мониторим, зелёное — не трогаем.
Как оценивать вероятность и влияние
Первая ошибка — оценка «на глаз» без данных. Вместо «кажется, 50%» используйте исторические данные: сколько раз в прошлых проектах менялся API? Если из 10 проектов API менялся в 3 — вероятность 30%.
Вторая ошибка — все риски оцениваются как «высокое влияние». Если всё высокое — ничего не высокое. Разделяйте: что действительно может убить проект, а что просто неприятно.
Третья ошибка — игнорирование косвенного влияния. Риск может влиять не только на сроки, но и на качество, репутацию, мотивацию команды. Учитывайте это.
Практический совет: оценивайте риски не в одиночку, а с командой. Архитектор видит технические риски, аналитик — риски требований, разработчик — риски кода. Соберите всех — и картина станет полной.
Как связаны риски и допущения
Каждое допущение — это потенциальный риск. «Ключевой разработчик не уволится» — если нарушится, уход приведёт к задержке и потере экспертизы. «Заказчик даст доступ до тестирования» — если нарушится, нет доступа → сдвиг графика. «API останется стабильным» — если нарушится, изменение API приведёт к переделке и перерасходу. «Бюджет утвердят вовремя» — если нарушится, задержка бюджета приведёт к остановке работ. Подробнее о том, как допущения становятся рисками, читайте в статье Допущения в ИТ-проекте.
Что в понедельник утром
Соберите команду на 30 минут и проведите мозговой штурм по категориям рисков. Для каждого риска оцените вероятность и влияние — не пытайтесь быть точными до процента, достаточно грубой шкалы (низкая, средняя, высокая). Распределите по зонам — красное и оранжевое требуют вашего внимания. Для красных и оранжевых напишите конкретный план: кто, что и когда сделает. И обновляйте реестр раз в месяц — риски не стоят на месте.
Заключение
Матрица вероятности и влияния — это не магия, а просто способ не гадать, а знать. Красное — главное внимание, немедленный план и резервы. Оранжевое — второе внимание, активное управление. Жёлтое — мониторинг, план «на всякий случай». Зелёное — забудьте, пересматривайте раз в квартал.
Хотите научиться управлять рисками на практике, а не читать про них? В модуле 6 курса «Мастер управления IT-проектами» мы на воркшопах составляем реестр рисков для ваших реальных проектов. Подробнее о курсе →