Планирование рисков проекта: выявление, оценка и меры реагирования

Планирование рисков — это не попытка предсказать будущее, а системный процесс подготовки к неопределённости. В рамках общей оценки и планирования проектов этот этап отвечает на вопрос: «Что может пойти не так (или лучше, чем ожидалось), и что мы будем делать, если это произойдёт?».

Оценка рисков является частью анализа проекта и помогает понять, какие факторы могут повлиять на сроки, бюджет и результаты. Грамотное планирование мероприятий по управлению рисками превращает неопределённость из угрозы в управляемый параметр.

Без этого этапа план проекта остаётся «оптимистичным сценарием», который рушится при первом же столкновении с реальностью.

Как спланировать управление рисками: 5 шагов

Процесс планирования рисков строится по чёткому алгоритму, который повторяется на протяжении всего жизненного цикла проекта.

Шаг 1. Идентификация рисков

Цель: составить максимально полный список потенциальных событий, которые могут повлиять на проект.

Методы идентификации:

• Мозговой штурм с командой проекта и ключевыми стейкхолдерами.
• Анализ допущений и ограничений (что мы считаем истиной, но что может оказаться ложным?).
• SWOT-анализ (сильные и слабые стороны, возможности и угрозы).
• Изучение уроков прошлых проектов (Lessons Learned) и отраслевых чек-листов.

Важно: на этом этапе мы только фиксируем риски, не оценивая их и не пытаясь сразу решить.

Шаг 2. Оценка вероятности и влияния

Каждый выявленный риск необходимо квалифицировать. Для этого используются два параметра:

1. Вероятность (Probability): каков шанс, что риск реализуется? Например, от 1 до 5 или в процентах.
2. Влияние (Impact): насколько сильно риск повлияет на сроки, бюджет или качество, если он реализуется? Например, от 1 до 5 или в денежном выражении.

Рейтинг риска (Risk Score) рассчитывается по формуле:

Рейтинг риска = Вероятность × Влияние

Например:

• Вероятность = 3.
• Влияние = 3.
• Рейтинг = 3 × 3 = 9.

Это упрощённый способ качественной приоритизации. В реальных проектах шкалы и методы оценки могут отличаться.

Шаг 3. Построение матрицы рисков

Матрица рисков — это визуальный инструмент, который помогает приоритизировать риски на основе их рейтинга. Чаще всего используется матрица 3×3 или 5×5.

Влияние \ Вероятность	Низкая (1)	Средняя (2)	Высокая (3)
Высокое (3)	Средний (3)	Высокий (6)	Критический (9)
Среднее (2)	Низкий (2)	Средний (4)	Высокий (6)
Низкое (1)	Низкий (1)	Низкий (2)	Средний (3)

Границы цветовых зон и пороги, при которых требуется обязательное реагирование, организация определяет самостоятельно с учётом своего риск-аппетита и критичности проекта.

Как правило:

• Критическая зона: требует немедленного плана реагирования и постоянного контроля.
• Высокая/средняя зона: требует наблюдения и превентивных мер.
• Низкая зона: принимается к сведению, активные действия не требуются, если только риски не реализуются.

Шаг 4. План реагирования и меры профилактики

Для приоритетных рисков разрабатывается стратегия реагирования. Низкоприоритетные риски могут приниматься без специальных превентивных действий, если это соответствует установленным порогам.

Для негативных рисков (угроз) существует четыре классические стратегии:

1. Избежание (Avoid): изменить план проекта так, чтобы риск исчез полностью (например, отказаться от использования непроверенной технологии).
2. Смягчение (Mitigate): снизить вероятность или влияние риска (например, провести дополнительное тестирование или заложить временной буфер).
3. Передача (Transfer): переложить финансовые последствия на третью сторону (например, купить страховку или заключить фиксированный контракт с подрядчиком).
4. Принятие (Accept): осознанно принять риск без активных превентивных мер, предусмотрев при необходимости резерв времени или средств на случай его реализации.

Для позитивных рисков (возможностей) стратегии обратные: использование (Exploit), усиление (Enhance), совместное использование (Share) и принятие (Accept).

Шаг 5. Назначение ответственных за риски

Каждый риск в реестре должен иметь владельца риска (Risk Owner). Это конкретный человек, который отвечает за:

• Мониторинг триггеров (признаков наступления) этого риска.
• Активацию плана реагирования, если риск начал реализовываться.
• Информирование руководителя проекта об изменении статуса риска.

Владелец риска не обязательно является тем, кто выполняет работы по смягчению, но он несёт ответственность за то, чтобы реакция произошла вовремя.

Реестр рисков: структура и пример

Реестр рисков — это живой документ, который объединяет все этапы планирования. Он создаётся на этапе планирования и обновляется на протяжении всего проекта.

Профессиональная формулировка риска следует структуре: Причина → Событие → Последствие.

Пример:

• ❌ Плохо: «Разработчик уволится».
• ✅ Хорошо: «Из-за высокой зависимости проекта от одного ключевого разработчика (причина) он может покинуть проект во время разработки (событие), что приведёт к задержке релиза на 2–3 недели (последствие)».

Пример реестра рисков для проекта внедрения CRM

ID	Риск (Причина → Событие → Последствие)	Вер.	Влияние	Рейтинг	Владелец	Триггер	Стратегия	Меры реагирования	Срок	Статус
R1	Из-за высокой зависимости от одного разработчика он может уволиться → задержка релиза на 2–3 недели	2	3	6	Tech Lead	Снижение доступности разработчика < 80%	Смягчение	1. Внедрить парное программирование; 2. Вести актуальную документацию; 3. Заложить буфер 2 недели.	До конца месяца 1	Активен
R2	Из-за устаревшего API старой системы интеграция может занять больше времени → сдвиг сроков фазы разработки	3	3	9	PM	Интеграционный тест не проходит после 3 попыток	Смягчение	1. Провести технический аудит API до старта разработки; 2. При негативном результате — заложить бюджет на middleware.	До начала месяца 2	Активен
R3	Из-за зависимости от одного вендора поставка серверов может задержаться → простой команды	2	2	4	Закупки	Поставщик не подтверждает дату отгрузки за 2 недели до дедлайна	Смягчение	1. Заключить SLA со штрафными санкциями; 2. Предусмотреть альтернативного поставщика; 3. Иметь резервное оборудование.	До начала месяца 3	Активен
R4	Из-за недостаточного вовлечения пользователей они могут саботировать внедрение → низкая адаптация системы	3	2	6	Change Manager	Менее 50% сотрудников проходят обучение до релиза	Смягчение	1. Провести серию обучающих вебинаров; 2. Назначить «чемпионов внедрения» в отделах.	За 1 месяц до релиза	Активен

Вер. = вероятность: 1 — низкая, 2 — средняя, 3 — высокая. Влияние: 1 — низкое, 2 — среднее, 3 — высокое.

Планирование проекта и мониторинг рисков

Планирование проекта и мониторинг рисков неразрывно связаны. Реестр рисков, созданный на старте, бесполезен, если его положить «в стол».

Процесс мониторинга включает:

1. Регулярный пересмотр реестра: с периодичностью, соответствующей масштабу, динамике и уровню риска проекта. Для многих проектов это может быть еженедельный или ежемесячный пересмотр на статусных встречах.
2. Поиск новых рисков: по мере выполнения проекта появляются новые неопределённости, которые необходимо добавлять в реестр.
3. Оценка эффективности мер: сработали ли превентивные меры? Нужно ли скорректировать план реагирования?
4. Закрытие рисков: если риск стал невозможным (например, мы успешно завершили этап, где он мог возникнуть), он закрывается в реестре, а зарезервированные под него ресурсы высвобождаются.

Типичные ошибки при планировании рисков

1. Планирование рисков в одиночку. PM, составляющий реестр без участия команды, может упустить значительную часть технических и операционных рисков.
2. Формулировка риска как проблемы. Риск — это потенциальное будущее событие («Может задержаться поставка»), а не свершившийся факт («Поставка задержалась»).
3. Отсутствие владельцев рисков. Риск, за который отвечают «все», не контролирует никто.
4. Игнорирование позитивных рисков. Упущенная возможность сэкономить или сделать быстрее — это тоже риск, которым можно и нужно управлять.
5. Создание реестра «для галочки». Документ создаётся перед стартом и никогда не открывается до самого конца проекта.

FAQ: частые вопросы о планировании рисков

В чём разница между проблемой и риском?

Проблема (issue) — это негативное событие, которое уже произошло и требует немедленного решения. Риск — это неопределённое событие, которое может произойти в будущем и для которого мы готовим план заранее.

Как часто нужно обновлять реестр рисков?

Для небольшого проекта достаточно короткой командной сессии на старте. В крупных и сложных проектах анализ рисков становится итеративным процессом и продолжается на протяжении жизненного цикла проекта. Минимум — на каждой крупной вехе или при существенных изменениях.

Что делать, если риск всё-таки реализовался?

Владелец риска активирует заранее подготовленный план реагирования. Если риск не был идентифицирован заранее (так называемый «неизвестный неизвестный»), команда переходит в режим управления проблемами (issue management), а после решения ситуации риск добавляется в реестр как урок на будущее.

Сколько времени должно уходить на планирование рисков?

Для небольших проектов достаточно 1–2 часов на воркшоп по идентификации и оценке. Для крупных и сложных проектов это может быть итеративный процесс, занимающий значительную часть фазы планирования и продолжающийся на протяжении всего проекта.

Управляйте рисками проекта в едином рабочем пространстве

Когда реестр рисков живёт отдельно от задач, о нём быстро забывают. Интабия Платформа позволяет интегрировать управление рисками в ежедневную работу команды.

• ✅ Хранение данных в РФ, обработка персональных данных с учётом требований 152-ФЗ.
• ✅ Бесплатно для команд до 5 человек.

Создать рабочее пространство и начать управление рисками →