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

Назначение: структурированная работа с неопределённостями — превратить «неизвестное» в управляемые действия.

Аудитория: PM, спонсоры, команда.

Статус: устоявшийся (PMBOK Risk Management, ISO 31000:2018, PRINCE2 risk theme).

Не путать с: Issue Management (управление проблемами — уже случившимися событиями), Crisis Management (кризис-менеджмент), Scope Creep (неконтролируемый рост содержания — один из типов риска).

Общее #

Управление рисками проекта (Project Risk Management) — систематический процесс идентификации, анализа и реагирования на неопределённости, способные повлиять на цели проекта. PMBOK определяет риск как «неопределённое событие или условение, которое в случае наступления оказывает положительное или отрицательное влияние на цели проекта» (an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives). Каждый риск, таким образом, описывается тремя компонентами: событие × вероятность × влияние. Уберите любой из трёх — и риска в управленческом смысле нет: случившееся событие с вероятностью 100% — это уже проблема (issue), а не риск; событие с нулевым влиянием — шум, не заслуживающий внимания.

Ключевой момент современного определения: риск — это не только угроза, но и возможность. До шестой редакции PMBOK риск трактовался преимущественно как негативное событие; начиная с PMBOK 6 (2017) и в PMBOK 7 (2021) риск официально разделён на угрозы (threats) и возможности (opportunities). Неопределённость симметрична: интеграция может занять на месяц больше планового — а может пройти на месяц быстрее; новый вендор может подвести — а может предложить условия лучше рынка. Зрелое управление рисками работает с обоими хвостами распределения.

Подход закреплён в трёх базовых стандартах отрасли:

• PMBOK Guide (PMI) — раздел «Project Risk Management» и отдельный стандарт Practice Standard for Project Risk Management; полный цикл процессов описан в 6-й редакции (подробнее — в готовящейся статье «PMBOK», /docs/project-managment/pmbok).
• ISO 31000:2018 — международный стандарт Risk management — Guidelines: принципы, структура (framework) и универсальный процесс менеджмента риска, применимый к любому уровню — от проекта до организации.
• PRINCE2 — тематическая область «Risk» (risk theme) с процедурой identify → assess → plan → implement (подробнее — в готовящейся статье «PRINCE2», /docs/project-managment/prince2).

Различают индивидуальный риск — неопределённость отдельного события, — и совокупный риск проекта (overall project risk): эффект неопределённости на проект в целом. Совокупный риск больше суммы индивидуальных: десятки мелких угроз вместе могут ставить проект под угрозу даже тогда, когда каждая по отдельности проходит порог значимости, — и наоборот, портфель возможностей может спасти проект с провальным базовым сценарием.

Главная идея дисциплины: неопределённость проекта невозможно устранить, но её можно сделать видимой и управляемой. Вместо «надеемся, что всё пройдёт гладко» — явный перечень рисков с владельцами, оценками и планами реагирования. Управление рисками — непрерывный цикл на протяжении всего проекта, а не одноразовое упражнение на старте: риски меняются, закрываются, реализуются и рождаются новые, поэтому реестр живёт вместе с проектом.

Цикл управления рисками #

PMBOK 6-й редакции описывает семь процессов управления рисками, покрывающих полный цикл — от планирования до мониторинга:

Краткое назначение каждого процесса:

1. Plan Risk Management — договориться, как команда будет работать с рисками: какие шкалы вероятности и влияния использовать, какие пороги считать критическими, кто владеет рисками, как часто пересматривать реестр. Без этого этапа каждая встреча по рискам превращается в спор о словах.
2. Identify Risks — систематически собрать угрозы и возможности проекта. Процесс непрерывный: первичная идентификация на старте, затем пополнение на каждой итерации или фазе.
3. Perform Qualitative Risk Analysis — быстро оценить и приоритизировать риски по шкалам вероятности и влияния (матрица «вероятность × влияние»). Обязателен для любого проекта.
4. Perform Quantitative Risk Analysis — где оправдано, перевести приоритеты в числа: деньги, даты, вероятности (EMV, Монте-Карло). Нужен не всегда — для большинства проектов достаточно качественного анализа.
5. Plan Risk Responses — для каждого значимого риска выбрать стратегию (avoid / mitigate / transfer / accept / escalate — для угроз), назначить владельца и конкретные действия; для возможностей — exploit / share / enhance / accept.
6. Implement Risk Responses — выполнить запланированные действия. Отдельный процесс появился именно потому, что планов без исполнения в управлении рисками исторически больше, чем исполненных.
7. Monitor Risks — отслеживать триггеры, переоценивать, проводить аудит, отчитываться и выявлять новые риски.

В PMBOK 7 (2021) процессная модель заменена принципами и доменами исполнения, но семистадийный цикл 6-й редакции остаётся общепринятой рабочей моделью: он напрямую отображается на процедуры ISO 31000 (identification → analysis → evaluation → treatment) и PRINCE2 (identify → assess → plan → implement). Практический ритм цикла: полная ревизия реестра — на контрольных точках фаз или раз в итерацию, точечные обновления — еженедельно, реакция на сработавшие триггеры — немедленно.

Идентификация рисков #

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

Техники идентификации:

• Мозговой штурм — команда и ключевые стейкхолдеры свободно генерируют риски по категориям; самый быстрый способ получить первый десяток-два рисков.
• Метод Дельфи — независимые экспертные оценки в несколько раундов без обсуждения между раундами; защищает от «затягивания» мнений авторитетными участниками.
• SWOT-анализ — риски ищутся в квадрантах Weaknesses и Threats, возможности — в Strengths и Opportunities.
• Чек-листы — типовые риски отрасли и организации из прошлых проектов; быстрый старт, но чек-лист покрывает лишь то, что уже случалось.
• Анализ допущений и ограничений — каждое допущение плана («данные будут предоставлены в марте», «API вендора стабилен») — это риск, спрятанный в слово «допускаем».
• Интервью и анализ документов — WBS (декомпозиция работ выявляет неопределённости отдельных пакетов), реестр стейкхолдеров, план проекта, контракты, оценки стоимости и сроков, протоколы встреч.

RBS (Risk Breakdown Structure) — иерархическая декомпозиция рисков по категориям, зеркальный аналог WBS. Классическая структура PMBOK:

RBS дисциплинирует мозговой штурм: группа проходит по категориям одну за другой, вместо того чтобы десять минут обсуждать «что опять сломается у вендора» и забыть про юридические риски.

Правило формулировки риска. Риск записывается по схеме «причина → событие → следствие»: «Поскольку команда впервые работает с технологией X (причина), возможно, производительность интеграции не будет достигнута (событие), что потребует четырёх недель на оптимизацию (следствие)». Формулировки вида «проблемы с интеграцией» бесполезны: из них не следует ни причина, ни величина следствия, ни триггер.

Источники идентификации не исчерпываются стартовой сессией: lessons learned завершённых проектов, опыт соседних команд, регулярный вопрос на стендапах «что может пойти не так в ближайшем спринте», а также мониторинг хода самого проекта — отклонения CPI/SPI и сжимающийся запас плавающего времени на критическом пути часто указывают на ещё не идентифицированные риски.

Реестр рисков #

Реестр рисков (Risk Register) — центральный артефакт процесса: живой документ, в котором риски фиксируются, оцениваются, получают владельцев и планы реагирования, отслеживаются и закрываются. Главная ценность реестра — не «список страхов», а план действий с владельцами: строка реестра, у которой нет ответственного и конкретного следующего шага, — это запись в дневнике тревог, а не управление рисками.

Шаблон реестра — набор полей, заполняемых по мере прохождения цикла:

Пример фрагмента реестра IT-проекта (для компактности колонки «причина», «триггер» и «дата» опущены — причина и следствие вплетены в описание; вероятности даны уровнями шкалы из раздела «Качественный анализ»):

Обратите внимание на R-06: реестр содержит и возможности — это прямое следствие современного взгляда на риск. Реестр ведёт PM, но владельцы рисков распределены по команде: у технических рисков — техлид, у продуктовых — PO, у внешних — PM или спонсор.

Качественный анализ #

Качественный анализ рисков (Perform Qualitative Risk Analysis) — быстрая приоритизация реестра по двум шкалам: вероятности (наступит ли?) и влияния (если наступит — насколько плохо/хорошо?). Цель — отделить риски, требующие активной работы, от тех, за которыми достаточно наблюдать. Качественный анализ обязателен для любого проекта — в отличие от количественного.

Шкала вероятности — пять уровней с числовой привязкой:

Шкала влияния — уровни 1–5, калиброванные под цели проекта. Для денежного проекта калибровка по стоимости (например: 5 — потеря >10% бюджета), для срочного — по срокам, зрелые организации задают пороги сразу по четырём целям — стоимость, сроки, содержание, качество:

Score риска = уровень вероятности × уровень влияния (1–25). Результат сводится в матрицу «вероятность × влияние» (Probability and Impact Matrix, матрица P×I) размером 5×5:

Матрица делится на зоны — heat map: красную (высокий приоритет), жёлтую (средний) и зелёную (низкий). Жирным в матрице выделена красная зона:

Пороги зон настраиваются в плане управления рисками (шаг 1 цикла) под аппетит к риску организации: для регулируемой промышленности жёлтая зона может начинаться уже со score 5, для стартапа — с 10.

Результаты качественного анализа: приоритизированный реестр, список топ-рисков (top-N, обычно 5–10 записей, идущих в статус-отчёты и на повестку руководства) и watchlist — риски зелёной зоны, за которыми наблюдают, но не реагируют. Качественный анализ повторяют на каждой контрольной точке: вероятности и влияния меняются по мере выполнения проекта — то, что в начале было жёлтым, к финале может стать красным, и наоборот.

Количественный анализ #

Количественный анализ переводит приоритеты в числа — деньги, даты, вероятности. Он дороже качественного, требует данных и экспертизы, поэтому применяется выборочно: для крупных и стратегических проектов, при принятии инвестиционных решений (build vs buy), при обосновании резервов перед спонсором. Для большинства проектов достаточно матрицы P×I — количественный анализ не самоцель, а инструмент для случаев, когда цена решения выше цены анализа.

Ожидаемая денежная стоимость (Expected Monetary Value, EMV) — базовая количественная метрика:

EMV = Вероятность × Влияние (в деньгах)

Пример: риск задержки поставки оборудования с вероятностью 0.3 и влиянием 2 000 000 ₽ имеет EMV = 0.3 × 2 000 000 = 600 000 ₽. Сумма EMV по всем рискам реестра — количественное обоснование contingency reserve (см. раздел «Стратегии реагирования»): вместо «заложим сколько-нибудь на всякий случай» — арифметически прозрачная сумма. Для возможностей EMV считается так же и входит в бюджет со знаком плюс.

Дерево решений (decision tree) — развитие EMV для выбора между альтернативами: строится дерево решений и случайных событий, для каждой ветви считается EMV, выбирается ветвь с максимальной ожидаемой ценностью. Классический пример — «делать своими или покупать»: своя разработка дешевле при успехе, но с вероятностью 0.4 не уложится в срок; готовое решение дороже, но предсказуемо. Дерево заставляет выписать все ветви и вероятности явно, а не держать их в голове.

Метод Монте-Карло — имитационное моделирование совокупного риска: вместо отдельных рисков модель прогоняется тысячи раз со случайными значениями из распределений входных параметров, и на выходе получается распределение результата — бюджета или срока. Практические выходы: оценка «с вероятностью 80% проект завершится не позднее X и не дороже Y» (P80), вероятность уложиться в дату контракта, вклад отдельных задач в разброс. Детали метода — в статье «Статистический анализ».

Анализ чувствительности (sensitivity analysis) — определяет, какие неопределённости сильнее всего влияют на результат. Итог визуализируется торнадо-диаграммой (tornado diagram): горизонтальные полосы, отсортированные по размаху влияния каждого фактора на итог, — самая длинная полоса сверху показывает, где концентрация неопределённости максимальна и где работа с риском даёт наибольшую отдачу.

Ограничение всех количественных методов — «garbage in, garbage out»: если вероятности и влияния взяты «с потолка», Монте-Карло выдаст красивое, но фиктивное распределение. Количественный анализ дополняет, а не заменяет качественный: сначала матрица P×I показывает, какие риски вообще заслуживают чисел, затем числа уточняют решение.

Стратегии реагирования #

Для каждого риска из красной (и значимой части жёлтой) зоны выбирается стратегия реагирования. Наборы стратегий для угроз и возможностей зеркальны друг другу.

Угрозы (threats) #

Возможности (opportunities) #

Контингентные планы и резервы #

Реагирование оформляется тремя уровнями планов:

• Превентивные действия — выполняются до наступления риска (это и есть mitigate/avoid в действии).
• Контингентный план (contingency plan) — заранее подготовленные действия, запускаемые по триггеру: «если к 15 сентября API не пройдёт нагрузочный тест — переключаемся на план Б».
• Fallback-план — план второго эшелона, если контингентный план не сработал или риск реализовался в худшем сценарии.

Планы оплачиваются резервами, и здесь проходит классическая граница (частый вопрос сертификаций PMP и PRINCE2):

Практическое следствие: если contingency reserve исчерпан, а риски продолжают реализовываться, PM не «тихо занимает» у management reserve — он выходит на спонсора с изменением baseline через процедуру управления изменениями. Смешение резервов в одну «копилку на всякий случай» лишает проект обоих: копилка тратится первой и не защищает ни от известных, ни от неизвестных событий.

Мониторинг и контроль #

Monitor Risks — процесс, в котором цикл замыкается и оживает: реестр без регулярного пересмотра мёртв быстрее, чем кажется. Состав мониторинга:

• Переоценка рисков (risk reassessment) — на контрольных точках: актуальны ли ещё формулировки, изменились ли вероятности и влияния, не пора ли переносить строки между зонами. Типично: полная ревизия реестра раз в фазу/итерацию, точечные обновления еженедельно.
• Риск-аудит (risk audit) — периодическая проверка ответов на два вопроса: исполняются ли планы реагирования и эффективны ли они. Аудит часто выполняет внешняя сторона — PMO или независимый рецензент.
• Статус-отчёты по рискам — топ-риски с динамикой (новые / выросшие / закрытые) в регулярной отчётности проекта; канал и формат отчётности фиксируются в плане коммуникаций.
• Отслеживание триггеров — у каждого значимого риска есть наблюдаемый триггер и владелец, который за ним следит; сработавший триггер запускает контингентный план.
• Burn-down рисков (risk burn-down chart) — график сокращения совокупной экспозиции риска (суммы score или EMV) во времени; наглядный ответ спонсору «становится ли проект безопаснее».
• Выявление новых рисков и закрытие отработанных: реализовавшиеся риски переходят в статусы «реализовался» и передаются в управление проблемами (issue management) — с корректирующими действиями; потерявшие актуальность — закрываются с фиксацией уроков.

Мониторинг рисков опирается на показатели хода проекта. Метрики earned value management — CPI (индекс стоимости) и SPI (индекс сроков) — работают как ранние сигналы: устойчивое снижение SPI при неизменном scope часто означает не «плохо работаем», а нереализованный риск оценок, который пора перевести из неявного в явный — строкой реестра. Аналогично контроль критического пути: сжимающийся float задач критического пути — прямое указание, что вероятность риска сроков растёт, хотя ни один триггер ещё не сработал.

Обратная связь замыкается lessons learned: закрытые риски с оценками «как оно вышло на самом деле» калибруют шкалы вероятностей и влияний следующих проектов — организация начинает видеть риск до того, как он увидел её.

Риски в Agile-проектах #

Распространено мнение, что «в Agile рисков нет» — они есть, но работа с ними встроена в сам ритм итераций. Agile-подход риск-адаптивен: вместо большого фронтального анализа на старте — короткие циклы, каждый из которых сжигает часть неопределённости.

• Короткие итерации снижают горизонт прогноза: рискнуть на две недели несравнимо дешевле, чем на годовой водопадный план; каждое планирование спринта обновляет картину неопределённости.
• Рапид-фидбек — работающий инкремент каждые 1–4 недели превращает технические и продуктовые риски из гипотез в проверенные факты: интеграция либо заработала, либо нет.
• Product risk через MVP — минимально жизнеспособный продукт проверяет рыночную гипотезу до того, как в неё вложен полный бюджет; риск «строим не то, что нужно» закрывается earliest возможной проверкой на реальных пользователях.
• Ретроспективы — регулярная ретроспектива команды работает как непрерывная идентификация и обработка рисков процесса: то, что мешает команде сейчас, — инцидент завтрашнего дня, если его не разобрать.
• Стендапы — ежедневная точка эскалации блокеров: блокер — это сработавший триггер самого близкого риска.
• Risk-driven порядок работ — рискованные элементы (spike по непроверенной технологии, интеграция с внешним вендором) ставятся в начало бэклога: неопределённость сжигается рано, когда манёвр ещё дёшев; подход систематизирован в RDD — Risk Driven Development.

Формальные артефакты при этом облегчаются, но не обнуляются: даже в Scrum-проекте имеет смысл компактный реестр топ-10 рисков с владельцами и триггерами — он обновляется на планировании и ревью спринта, а не живёт отдельной «страшной книгой». Логика работы совпадает с классическим циклом: идентификация (ретро, стендапы, планирование) → приоритизация (P×I на бэклоге) → реагирование (spike, MVP, эксперимент) → мониторинг (обзор на каждом ревью). Agile не отменяет управление рисками — оно меняет его каденцию с фазовой на непрерывную.

Плюсы #

• Превращение неопределённости в план. Страх «что-то пойдёт не так» конвертируется в конкретные строки с владельцами, триггерами и действиями — управлять можно только тем, что сформулировано.
• Ранние сигналы. Триггеры и мониторинг дают реакцию до того, как угроза реализовалась в проблему, — когда манёвр ещё дёшев.
• Обоснованные резервы. Contingency reserve, посчитанный из EMV, — арифметически прозрачен для спонсора и защищает бюджет лучше, чем «запас на всякий случай».
• Работа с возможностями. Современный взгляд (PMBOK 6+) заставляет видеть не только угрозы, но и шансы — досрочные поставки, выгодные условия, попутные эффекты.
• Приоритизация внимания. Матрица P×I отсекает зелёную зону и фокусирует команду на том немногом, что действительно решает исход.
• Калибровка организации. Накопленные факты «как оно вышло» уточняют шкалы и оценки следующих проектов — риск-менеджмент становится активом организации, а не ритуалом одного проекта.

Минусы #

• Цена процесса. Реестр, встречи, переоценки, отчёты — реальные часы команды; на малых проектах формальный цикл может стоить дороже самих рисков.
• Ложная точность. Вероятности «на глаз» и Монте-Карло поверх оценок с потолка создают видимость знания, которая хуже честного «не знаем».
• Карго-культ. Реестр ради реестра — строки без владельцев и действий — вырождается в спис страхов и дискредитирует практику.
• Парадокс формализации. Чем больше бюрократии вокруг рисков, тем больше стимулов их не регистрировать («не создавать себе работу»); нужна культура, а не только процедура.
• Игнорирование unknown unknowns. Реестр покрывает только идентифицированное; успокоенность длинным реестром опасна — management reserve существует именно поэтому.
• Субъективность оценок. Качественные шкалы зависят от оценивающего; без калибровки по прошлым проектам матрица P×I отражает тревожность участников больше, чем реальность.

Связанные статьи #

• Статистический анализ — количественные методы оценки проекта: метод Монте-Карло, вероятностные оценки сроков.
• Критический путь — задачи с наибольшим влиянием на срок проекта и их связь с рисками расписания.
• RDD — Risk Driven Development — риск-ориентированный выбор глубины инженерных практик.
• Ретроспектива — регулярный инструмент работы с рисками процесса в Agile-командах.
• План коммуникаций — куда и как регулярно транслируются статус-отчёты по рискам.
• Введение в управление проектом — место риск-менеджмента среди процессов проектного управления.