Реестр рисков ИТ-проекта: образец и пример заполнения
«Мы не знали, что API изменится»
Вы спланировали бюджет, расписали WBS, распределили роли, а через месяц ключевой разработчик уходит, API изменили, заказчик затягивает согласование — план рухнул.
В ИТ-проектах риски подстерегают на каждом шагу. Если вы управляете ими «в голове» — вы ими не управляете, вы просто надеетесь, что всё обойдётся. Реестр рисков — это документ, где фиксируются все риски, их оценка и планы реагирования. Это страховка: вы платите небольшую цену (время на заполнение), чтобы избежать огромных потерь.
Что такое реестр рисков
«Список в голове» — это хаос: риски забываются, нет владельцев, нет приоритетов, нет планов, только паника, когда риск наступает. Реестр рисков даёт полную картину всех рисков, у каждого риска есть владелец, матрица показывает, на что тратить время, а планы реагирования готовы к применению.
Обязательные поля реестра рисков
В каждом реестре должны быть такие поля: ID (уникальный номер), описание (причина → событие → последствие), категория (технический, организационный, внешний, ресурсный), вероятность (0–100%), влияние (на сроки, бюджет, качество), рейтинг (вероятность × влияние), владелец (кто отвечает за мониторинг и реагирование), план реагирования (что делаем до наступления риска) и статус (активен, реализовался, закрыт).
Где искать риски
Их можно искать по категориям. Технические риски — изменение API, проблемы с производительностью, несовместимость версий, баги в сторонних библиотеках. Организационные — смена сотрудников, реорганизация компании, конфликты в команде. Внешние — изменение законодательства, санкции, проблемы с поставщиками. Управленческие — задержка утверждения бюджета, смена приоритетов, слабая поддержка спонсора. Ресурсные — уход ключевого разработчика, нехватка компетенций, недоступность оборудования.
Источники рисков: мозговой штурм с командой (пройдите по каждой категории), исторические данные (что шло не так в прошлых проектах), экспертные интервью (спросите архитектора, DevOps, безопасников) и допущения (каждое допущение — потенциальный риск). Подробнее — в статье Допущения в ИТ-проекте.
Пример заполнения реестра рисков
Возьмём проект по внедрению модуля «Командировки и авансовые отчёты».
R-001. Руководство заказчика неактивно → затягивание согласований → сдвиг сроков. Вероятность 60%, влияние 21 день, рейтинг высокий, владелец — РП. План реагирования: фиксация сроков в протоколах, эскалация к спонсору при задержке >3 дней.
R-002. Сопротивление пользователей → низкая эффективность внедрения. Вероятность 50%, влияние высокое, владелец — РП. План: обучение, вовлечение лидеров мнения, демо на ранних этапах.
R-003. Изменение API 1С → переделка интеграции → сдвиг сроков. Вероятность 30%, влияние 200 часов, рейтинг средний, владелец — архитектор. План: анализ версии API до начала разработки, резерв 2 недели.
R-004. Уход ключевого разработчика → потеря экспертизы → задержка. Вероятность 40%, влияние 14–28 дней, рейтинг высокий, владелец — РП. План: cross-training, документирование кода, резервный разработчик.
R-005. Задержка поставки серверов → невозможность тестирования → сдвиг. Вероятность 20%, влияние 14 дней, рейтинг средний, владелец — DevOps. План: заказ серверов за 2 недели до начала тестирования.
Матрица вероятности и влияния
Как расставить приоритеты? Высокое влияние + высокая вероятность = критический риск, может сорвать проект. Высокое влияние + средняя вероятность = высокий риск, требует активного управления. Среднее влияние + средняя вероятность = средний риск, требует мониторинга. Низкое влияние + низкая вероятность = низкий риск, принимается без действий, но периодически пересматривается.
Что в понедельник утром
Соберите команду на 30 минут, выпишите 5–10 рисков (пройдите по категориям: технические, организационные, внешние, ресурсные), оцените каждый по вероятности и влиянию, распределите по зонам, для красных и оранжевых напишите конкретный план (кто, что, когда) и обновляйте реестр раз в месяц.
Заключение
Реестр рисков — не бюрократия, а рабочий инструмент. Риск, который вы записали, — это риск, которым вы управляете. Риск, который вы не записали, — это просто сюрприз, который вас убьёт.
Хотите научиться управлять рисками на практике? В модуле 6 курса «Мастер управления IT-проектами» мы на воркшопах составляем реестр рисков для ваших реальных проектов. Подробнее о курсе →