Анализ рисков за 30 минут: фреймворк

TL;DR: Анализ рисков — это не документ для проверяющих, а инструмент принятия решений. Матрица 2×2 «вероятность × влияние», метод pre-mortem и реестр рисков позволяют любому руководителю провести анализ рисков за 30 минут и получить план действий. RuForge включает оценку управления рисками в диагностику домена «Принятие решений» — пройдите оценку и узнайте свой уровень зрелости.

---

Почему большинство рисков не видят заранее

Катастрофы в проектах редко бывают неожиданными в ретроспективе. Чаще всего, разбирая постмортем провального запуска или крупного сбоя, участники признают: «Мы об этом знали, но не думали, что это случится». Это не невежество — это когнитивная ошибка под названием «оптимистический сдвиг» (optimism bias).

Исследования Нобелевского лауреата Даниэля Канемана показывают: люди систематически недооценивают вероятность негативных событий и переоценивают свою способность с ними справиться. В управленческом контексте это проявляется так: команда, влюблённая в свой проект, видит риски, но оценивает их как «маловероятные» или «управляемые» — без реального анализа.

Вторая причина «слепых зон» — отсутствие структуры. Риски обсуждаются хаотично, на ходу, без единого формата. В итоге каждый участник держит в голове свой список рисков, никто не видит полной картины, и никто не несёт ответственности за конкретный риск.

Третья причина специфична для крупных российских компаний: анализ рисков превратился в бюрократическую функцию. Риск-менеджеры пишут реестры для совета директоров, а операционные руководители эти реестры не читают. В результате реальные операционные риски не управляются, а репутационные — документируются.

Фреймворк ниже создан для практического применения: 30 минут работы команды, конкретный результат, чёткое распределение ответственности.

Матрица 2×2: вероятность × влияние

Матрица рисков 2×2 — самый быстрый способ структурировать риски и расставить приоритеты. Оси: вероятность события (высокая/низкая) и влияние на проект или бизнес в случае реализации (высокое/низкое).

«
ВЛИЯНИЕ
Низкое Высокое
ВЕРОЯТНОСТЬ +———+———+
Высокая

Управлять	КРИТИЧНО

(зона 2)	(зона 1)

+———+———+
Низкая

Мониторить	Готовить

(зона 4)	сценарии

	(зона 3)

+———+———+
«

Зона 1 — КРИТИЧНО (высокая вероятность + высокое влияние):
Это риски первого приоритета. Для каждого нужен митигационный план (как снизить вероятность или влияние) и ответственный. Примеры: задержка ключевого поставщика в производственном проекте; уход ключевого разработчика на этапе MVP; изменение регуляторики для финтеха.
Зона 2 — УПРАВЛЯТЬ (высокая вероятность + низкое влияние):
Риски, которые скорее всего реализуются, но не разрушат проект. Нужен стандартный процесс управления, но не антикризисный план. Примеры: небольшие задержки в согласованиях; незначительный перерасход бюджета на 5–10%; единичные жалобы клиентов.
Зона 3 — ГОТОВИТЬ СЦЕНАРИИ (низкая вероятность + высокое влияние):
«Чёрные лебеди» — маловероятны, но если реализуются, могут уничтожить проект. Для них нужны сценарные планы: «что делаем, если это произойдёт». Примеры: резкое изменение валютного курса для импортёра; отзыв лицензии; техногенная авария.
Зона 4 — МОНИТОРИТЬ (низкая вероятность + низкое влияние):
Не тратьте на них ресурсы. Просто держите в поле зрения.
Практический пример — запуск нового продукта в IT-компании:

Риск	Вероятность	Влияние	Зона	Ответственный
Задержка разработки на 2+ недели	Высокая	Высокое	1	CTO
Уход ключевого бэкенд-разработчика	Средняя	Высокое	1/3	HR + CTO
Низкая конверсия на лендинге	Высокая	Среднее	2	CMO
Изменение алгоритмов App Store	Низкая	Высокое	3	CPO
Технические проблемы в день запуска	Средняя	Среднее	2	DevOps

Pre-mortem: убиваем проект до старта за 45 минут

Pre-mortem (предсмертный анализ) — метод, разработанный психологом Гэри Кляйном и популяризированный Даниэлем Канеманом. Используется в Amazon, Google, крупнейших консалтинговых компаниях.

Стандартный разбор рисков: команда смотрит вперёд и спрашивает «что может пойти не так?». Проблема: люди слишком оптимистичны, когда думают о будущем своего проекта.

Pre-mortem переворачивает вопрос: «Представьте, что прошёл год. Наш проект провалился. Причём полностью и катастрофически. Опишите, что именно произошло».

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

Протокол pre-mortem (45 минут для команды 5–10 человек):
Шаг 1 — Установка (5 минут):
Фасилитатор говорит: «Представьте: прошёл [N месяцев]. Проект [название] провалился. Не просто не достиг целей — провалился полностью. Ваша задача — написать, что именно произошло. У вас 10 минут, пишите индивидуально, не советуясь».
Шаг 2 — Индивидуальная работа (10 минут):
Каждый участник молча пишет список причин провала. Важно: молча и индивидуально — иначе первый голос доминирует.
Шаг 3 — Зачитывание и сбор (15 минут):
Каждый зачитывает свой список по одному пункту по кругу. Фасилитатор записывает на доске/флипчарте. Не обсуждаем, не оцениваем — просто собираем.
Шаг 4 — Кластеризация и приоритизация (10 минут):
Группируем похожие риски. Голосуем (каждый ставит 3 «голоса»): какие риски критичнее. Топ-3 критических риска — в приоритетную работу.
Шаг 5 — Действия (5 минут):
Для каждого из топ-3: кто ответственный, что делаем на следующей неделе, чтобы снизить вероятность или влияние.
Российский пример: ВТБ при трансформации контакт-центра использовал pre-mortem на этапе дизайна новой платформы. Участники выявили риск, который не попал в официальный реестр: «персонал категорически откажется переходить на новую систему из-за непривычного интерфейса». Это позволило заложить 3-месячную программу обучения до запуска и избежать провала внедрения, типичного для таких проектов.

4 стратегии работы с рисками

После идентификации и приоритизации для каждого риска выбирается одна из четырёх стратегий:

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

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

Шаблон реестра рисков для команды 5–15 человек

Реестр рисков не должен быть сложным. Достаточно таблицы с семью полями:

Поле	Содержание
ID	Порядковый номер (R-001, R-002…)
Описание	Что именно может произойти (конкретно, одним предложением)
Вероятность	Высокая / Средняя / Низкая
Влияние	Высокое / Среднее / Низкое
Зона	1–4 (из матрицы выше)
Стратегия	Снизить / Передать / Принять / Избежать
Ответственный + срок	Имя + дата следующего статуса

Правила ведения реестра:

• Обновляется раз в 2 недели (не раз в квартал)
• Хранится там, где хранится другая операционная документация проекта (Notion, Confluence, Google Docs)
• Максимум 15–20 рисков в активном реестре — больше не управляемо
• Закрытые риски архивируются, не удаляются — это история для следующих проектов

Для создания реестра используйте шаблон в базе знаний RuForge или любой табличный редактор.

Как применять: пошаговый алгоритм

1. Соберите команду — 4–8 человек, которые знают проект. Не больше: большие группы работают хуже в режиме риск-штурма.

1. Проведите pre-mortem (45 минут) — по протоколу выше. Это лучший способ выявить риски честно и быстро.

1. Нанесите риски на матрицу 2×2 (10 минут) — каждый риск оцените по вероятности и влиянию, распределите по зонам.

1. Выберите стратегию для каждого риска зоны 1 и 3 (10 минут) — снизить, передать, принять или избежать.

1. Заполните реестр рисков (15 минут) — 7 полей, максимум 15 строк для проекта на старте.

1. Назначьте ответственных — у каждого риска в зонах 1–2 должен быть конкретный человек и срок следующего статуса.

1. Поставьте регулярный review — раз в 2 недели: какие риски реализовались, какие изменились, появились ли новые.

Итого: 75 минут на первый полноценный анализ рисков для проекта любого масштаба.

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

Частые ошибки при анализе рисков

Ошибка 1: Риск-сессия без pre-mortem.
Стандартный мозговой штурм «назовите риски» даёт список очевидных и безобидных рисков. Критические риски — те, о которых страшно говорить вслух — не озвучиваются из-за группового оптимизма. Последствие: реестр рисков выглядит полным, но пропускает критические угрозы. Исправление: всегда начинайте с pre-mortem, а не с классического штурма.
Ошибка 2: Одинаковая стратегия «снизить» для всех рисков.
В итоге список действий на 30+ пунктов, которые никто не выполняет. Последствие: реестр рисков превращается в декоративный документ. Исправление: для рисков зоны 4 — принять. Для рисков зоны 3, которые нельзя контролировать — передать или принять с планом реагирования.
Ошибка 3: Реестр рисков обновляется раз в квартал.
Рынок, команда и контекст меняются быстрее. Риск, который был в зоне 4 в январе, может стать зоной 1 в феврале. Последствие: решения принимаются на основе устаревшей карты рисков. Исправление: двухнедельный review как регулярная встреча команды, не разовое мероприятие.
Ошибка 4: У рисков нет владельца.
«Команда несёт ответственность» означает, что никто не несёт ответственности. Последствие: риски не управляются, митигационные действия не выполняются. Исправление: у каждого риска в зонах 1–2 — конкретное имя и конкретный срок.
Ошибка 5: Путать риск и проблему.
Риск — это событие, которое может произойти. Проблема — то, что уже произошло. Реестр рисков заполняется предположениями о будущем, а не текущими проблемами. Смешение ведёт к тому, что реестр становится журналом текущих инцидентов. Последствие: теряется проактивная функция управления рисками. Исправление: для текущих проблем — отдельный инструмент (issue log), для рисков — реестр рисков.

Итого

• Большинство рисков известны заранее, но не управляются из-за отсутствия структуры и оптимистического сдвига.
• Матрица 2×2 «вероятность × влияние» — за 10 минут даёт приоритизацию рисков и зоны внимания.
• Pre-mortem убирает групповой оптимизм и выявляет риски, о которых обычно молчат.
• Четыре стратегии: снизить, передать, принять, избежать — правильный выбор разгружает команду.
• Реестр рисков — живой документ с owner’ом и сроком для каждой строки, обновляемый раз в 2 недели.
• 75 минут на первый анализ + 30 минут раз в 2 недели = полноценное управление рисками для большинства проектов.

Часто задаваемые вопросы

Что такое анализ рисков и зачем его делать руководителю?
Анализ рисков — это систематическое выявление событий, которые могут негативно повлиять на результаты проекта или бизнеса, с оценкой их вероятности и последствий. Руководителю это нужно не для отчётности, а для двух практических целей: принимать более качественные решения (когда риски видны, решения учитывают их стоимость) и распределять ресурсы превентивно (вместо того чтобы тушить пожары). В российской практике компании, регулярно проводящие риск-сессии, на 40% реже сталкиваются с крупными проектными провалами, по данным PMI Russia.
Как составить матрицу рисков для проекта с нуля?
Начните с pre-mortem: команда описывает, как проект провалился. Затем каждый риск оцените по двум параметрам: вероятность (высокая/средняя/низкая) и влияние (высокое/среднее/низкое). Нанесите на матрицу 2×2. Всё, что попало в «высокая вероятность + высокое влияние» — критические риски первого приоритета. Для них назначьте ответственного и действия в течение ближайших двух недель. Инструмент — любая таблица или стикеры на доске.
Что такое pre-mortem и как его провести?
Pre-mortem — это управленческий приём, где команда представляет, что проект уже провалился, и описывает причины. Это снимает психологический барьер «не хочется говорить о плохом» и выявляет риски, которые обычно замалчиваются из командного оптимизма. Провести: дайте каждому 10 минут молча написать список причин провала, затем соберите все версии, кластеризуйте и проголосуйте за критические. Занимает 45 минут, работает для команд от 3 до 15 человек.
Как часто нужно обновлять реестр рисков?
Оптимальная частота — раз в две недели, как часть регулярного ритма команды. Это позволяет отслеживать изменения вероятности и влияния рисков по мере того, как проект движется вперёд, а контекст меняется. Ежеквартальный review слишком редок для большинства операционных и продуктовых проектов. Ежедневный — избыточен. Исключение: в период высокой неопределённости (кризис, активная фаза запуска) — еженедельно.

Связанные материалы

• Диагностика принятия решений RuForge — оцените уровень зрелости управления рисками
• База знаний RuForge: домен «Принятие решений»
• Пройти диагностику управленческой зрелости
• Как принимать решения быстро: 3 метода без данных
• P&L для руководителя-нефинансиста