Матрица рисков в PM-системе: как приоритизировать проекты по угрозам, а не по эмоциям

Утро понедельника. Руководитель портфеля из восьми проектов открывает почту и видит три эскалации подряд. Один заказчик пишет, что «всё горит», второй требует срочного звонка, третий уже написал директору. Менеджер идёт туда, где громче кричат. Тушит один пожар, потом второй, потом третий. Через месяц выясняется: реально критичным был четвёртый проект, про который никто не кричал. Там тихо копился риск срыва сроков, и в итоге сдвиг составил больше 40%. Именно такой порог методические рекомендации Минэкономразвития квалифицируют как высокую степень влияния на проект — для государственных проектов он закреплён нормативно; в коммерческих компаниях порог устанавливается индивидуально, исходя из специфики портфеля и аппетита к риску.

У менеджера из этой истории просто не было инструмента, который бы вытащил тихий риск на поверхность раньше, чем тот стал проблемой.

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

В этой статье разберём, как собрать матрицу рисков прямо внутри PM-системы — из задач, дедлайнов и статусов, которые уже есть. Без отдельного Excel, без многочасовых воркшопов. И покажем, где матрица работает хорошо, а где она вас подведёт, если доверять ей слепо.

Почему «самый громкий проект» — не самый рискованный

Когнитивные искажения в управлении портфелем — задокументированная проблема, а не метафора. Availability bias заставляет нас переоценивать риски, о которых мы только что слышали. Эффект якоря фиксирует внимание на первой полученной цифре — даже если она неточная. В результате проект с активным и тревожным заказчиком получает ресурсы, а проект с молчаливой командой и реальным риском срыва — нет.

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

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

Проблема занижения приоритета сложных рисков признана даже на нормативном уровне. Приказ Минэкономразвития № 585 прямо фиксирует правило: если риск влияет одновременно на несколько параметров проекта — сроки, финансирование, целевые показатели — оценка ставится по последствию с наибольшим ущербом. Правило введено специально, чтобы многомерный риск не «усреднялся» и не терял свой реальный вес.

Без матрицы у менеджера нет защиты от собственных искажений. С матрицей появляется хотя бы структурный барьер между эмоцией и решением.

Проблема усугубляется в портфелях, где проекты ведут разные команды без единой системы задач. Риски одного проекта не видны соседней команде, информация не агрегируется на уровне портфеля, и руководитель принимает решения на основе фрагментарной картины. Матрица рисков работает только тогда, когда данные о рисках живут в одном месте, а не разбросаны по почте, мессенджерам и личным таблицам.

Из чего состоит матрица рисков проекта — и чем она отличается от «таблицы страхов»

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

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

В России пороги влияния закреплены нормативно. Вот как они выглядят по Приложению № 2 к методрекомендациям Минэкономразвития:

Задача с риском сдвига сроков больше 40% автоматически попадает в красную зону — без обсуждений. Порог закреплён нормативно, и он работает как предохранитель: независимо от «ощущений» менеджера, риск получает верхний приоритет.

По шкале вероятности Приказ № 585 закрепляет четыре уровня: очень низкая, низкая, средняя, высокая. Для коммерческих проектов чаще используют пятиуровневую шкалу (1–5), что даёт матрицу 5×5 с диапазоном баллов от 1 до 25.

В глоссарии Shtab по матрице рисков зоны интерпретируются так: зелёная (1–6 баллов) — мониторинг и принятие риска, жёлтая (7–12) — снижение, красная (13–25) — обязательные стратегии: avoid, transfer или aggressive mitigate. Риск в красной зоне без стратегии реагирования — это не управление рисками, это их игнорирование.

Матрица без реестра — картинка. Реестр без матрицы — список, из которого непонятно, за что браться первым. Работают они только вместе.

Пошаговая сборка матрицы рисков из задач, сроков и реестра — без отдельного Excel

Шаг 1. Превратить «список опасений» в формализованный реестр

Большинство команд ведут риски в голове или в случайных заметках. Первый шаг — перенести каждый риск в карточку задачи в PM-системе с обязательным набором полей: описание риска, вероятность (балл 1–5), влияние (балл 1–5), владелец риска, связанный проект, план реагирования.

Подход, описанный на pm-way.com, предлагает две версии расчёта: вероятность в процентах × влияние в баллах, или вероятность × стоимость мероприятий по минимизации. Второй вариант даёт числовой приоритет в деньгах и используется для расчёта резерва на риски. Для большинства продуктовых команд достаточно первого: балл 1–5 по каждой оси, произведение — приоритет.

Если риск влияет одновременно на сроки и бюджет, балл влияния ставится по худшему из последствий. Не среднее, не сумма — максимум. Это правило из нормативной базы, и оно защищает от систематического занижения сложных рисков.

На этом этапе не нужна идеальная точность. Нужна полнота: лучше занести 20 рисков с приблизительными оценками, чем 5 рисков с «точными» цифрами, которые покрывают только то, что уже обсуждалось на совещаниях.

Шаг 2. Рассчитать приоритет и разнести риски по зонам

У каждого риска теперь есть балл вероятности и балл влияния. Дальше — перемножить, получить число от 1 до 25, присвоить зону. В PM-системе это реализуется через вычисляемое поле: формула вероятность × влияние считается автоматически, цвет зоны присваивается по условию.

Стандартное деление: низкие риски (1–6 баллов), средние (7–12), высокие (13–25).

Правило для случаев с несколькими последствиями остаётся в силе: если риск одновременно грозит срокам на 35% и бюджету на 40%, берётся влияние по бюджету — оно выше. Усреднение искусственно снижает балл опасного риска, и именно от этого правило защищает.

После этого шага у вас есть реестр с цветовой индикацией. Красные риски — те, с которыми нужно что-то делать прямо сейчас. Жёлтые — требуют плана. Зелёные — достаточно мониторить.

Это уже рабочий инструмент.

Шаг 3. Агрегировать риски на уровне проекта — и получить тепловую карту портфеля

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

Технически это реализуется через rollup-поля: поле «количество красных рисков» на карточке проекта считает все связанные риски с баллом 13+. Один из практических подходов — порог в три и более красных риска автоматически переводит проект в «красную зону» и требует внимания руководителя или CTO. Порог не универсален: его стоит калибровать под размер и специфику конкретного портфеля.

Результат — тепловая карта портфеля: шесть или восемь проектов, у каждого цветовая индикация по рискам. Руководитель открывает её утром вместо почты с эскалациями и видит, где реально нужны ресурсы. Проект с тремя красными рисками получает приоритет не потому, что его заказчик громче кричит, а потому что данные показывают именно это.

Связь с бэклогом проекта здесь прямая: риски из красной зоны влияют на приоритет задач. Если риск реализуется — какие задачи сдвигаются первыми? Эту связь стоит прописать явно, а не держать в голове у одного менеджера.

Кейс: как портфель из 6 проектов перестроили по матрице рисков вместо «ощущения горящего дедлайна»

Составной кейс на основе нескольких проектов в финтех-сегменте. Шесть активных проектов, команда около сорока человек. Два проекта стабильно генерировали эскалации: заказчики писали директору, требовали ускорения, приходили на статус-митинги с претензиями. Именно на них уходило большинство управленческого внимания и ресурсов.

Третий проект шёл тихо. Команда не жаловалась, заказчик не беспокоил, дедлайн казался комфортным. Никто не строил риск-реестр по этому проекту.

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

Суммарный балл — выше, чем у обоих «горящих» вместе.

Аналогичную механику описывает кейс BARS Group: в системе управления проектами настроили раздел качественной оценки рисков по схеме «вероятность / влияние» и получили два разреза — наиболее приоритетные проекты и наличие критичных рисков. Приоритизация перешла из субъективного обсуждения в структурный вид. Конкретные метрики эффекта BARS Group в открытых источниках не раскрывает, но сам факт перехода от «обсуждения ощущений» к числовой приоритизации зафиксирован.

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

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

Матрица рисков — грубый фильтр, а не истина в последней инстанции

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

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

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

Тренд 2025–2026 — гибридный подход: простая матрица отсеивает низкоприоритетные риски, а для красной зоны запускаются более глубокие методы анализа. Для рисков с баллом 13+ применяют FMEA (анализ видов и последствий отказов), когда нужно разобрать цепочку причин и последствий по каждому сценарию, или метод «галстук-бабочка» (bow-tie), когда важно одновременно видеть и причины риска, и его последствия, и барьеры между ними. По сути, матрица отвечает на вопрос «где копать глубже», а глубокий анализ уже даёт конкретные решения.

Ещё одна проблема — статичность. Параметры рисков меняются: подрядчик, который был надёжным, задержал поставку; ключевой разработчик взял отпуск; регулятор выпустил новые требования. Матрица, которую не пересматривают, даёт ложное ощущение контроля. Один опытный PM на конференции сформулировал это так: «Устаревшая матрица хуже, чем отсутствие матрицы, потому что она отключает тревогу, которая могла бы спасти проект».

Команды, которые слепо доверяют матрице, принимают решения хуже, чем те, кто регулярно её пересматривает и дополняет качественным анализом для красной зоны. Матрица полезна ровно до тех пор, пока её воспринимают как инструмент для разговора о рисках, а не как замену этому разговору.

Ошибки, которые превращают матрицу рисков в бесполезную таблицу

1. Оценить риски один раз и забыть

Матрица, построенная на старте проекта и не пересматриваемая, устаревает быстрее, чем кажется. Через два спринта часть рисков уже реализовалась, часть изменила вероятность, появились новые. Минимальная частота пересмотра — раз в спринт или на каждом статус-митинге. Если матрица не меняется неделями — значит, её не обновляют, а не значит, что рисков нет.

2. Занижать влияние «тихих» рисков через усреднение

Когда риск влияет одновременно на сроки и бюджет, команды часто берут среднее значение: «ну не всё же сразу сломается». Нормативное правило из Приказа № 585 требует обратного — брать последствие с наибольшим ущербом. Это неудобно: риск получает высокий балл, и с ним нужно что-то делать. Именно поэтому команды интуитивно усредняют. Именно поэтому тихие многомерные риски систематически теряют приоритет.

3. Не привязывать риск к конкретной задаче и владельцу

Риск без владельца — ничья ответственность. Риск без привязки к задаче — абстракция, которая живёт в таблице и не влияет на реальную работу. Когда риск реализуется, никто не знает, что делать и кто отвечает. Задержка реакции на несколько дней в критичный момент может стоить срыва дедлайна по всему проекту. В PM-системах вроде Shtab каждый риск оформляется как задача с кастомными полями (вероятность, влияние, план реагирования) и привязывается к конкретному проекту — риск не теряется в отдельной таблице, виден в общем потоке работы и имеет назначенного владельца.

4. Не обновлять владельца риска при ротации команды

Эту ошибку совершают реже, но последствия у неё тяжёлые. Человек, назначенный владельцем риска, перешёл на другой проект или уволился. Формально риск по-прежнему в реестре, у него есть балл и зона. Фактически за ним никто не следит. Особенно опасно это для рисков в жёлтой зоне: они не горят, но требуют регулярного мониторинга. Без живого владельца жёлтый риск тихо дрейфует в красную зону, и обнаруживается это уже постфактум.

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

Как связать матрицу рисков с другими методами приоритизации

Матрица рисков не конкурирует с другими инструментами приоритизации — она добавляет к ним третье измерение.

Методика Value vs Effort отвечает на вопросы «насколько ценно» и «насколько дорого». Матрица рисков добавляет третий вопрос: «что случится, если пойдёт не так». Проект с высокой ценностью и низкими усилиями может оказаться в красной зоне по рискам — и тогда его нужно либо защитить дополнительными ресурсами, либо пересмотреть сроки.

Как риск-балл встраивается в портфельный скоринг

Scoring-модели приоритизации проектов обычно оценивают бизнес-ценность и загрузку команды, но не учитывают риски. Матрица рисков закрывает этот разрыв.

Пример формулы: итоговый скоринг проекта = (бизнес-ценность × 0,4) + (загрузка команды × 0,3) + (риск-балл × 0,3). Риск-балл здесь — суммарный балл красных рисков проекта, нормированный к шкале скоринга. Веса 0,4 / 0,3 / 0,3 — один из вариантов; они подбираются под приоритеты конкретного портфеля. В компании, где регуляторные риски критичны, вес риск-балла может доходить до 0,5. В стартапе, где главное — скорость вывода на рынок, бизнес-ценность получит 0,6.

Допустим, в портфеле четыре проекта:

• Проект A: ценность 9, загрузка 7, риск-балл 2. Итог: 3,6 + 2,1 + 0,6 = 6,3.
• Проект B: ценность 6, загрузка 5, риск-балл 8. Итог: 2,4 + 1,5 + 2,4 = 6,3.
• Проект C: ценность 8, загрузка 8, риск-балл 5. Итог: 3,2 + 2,4 + 1,5 = 7,1.
• Проект D: ценность 4, загрузка 3, риск-балл 9. Итог: 1,6 + 0,9 + 2,7 = 5,2.

Проекты A и B получают одинаковый итоговый балл, но профиль рисков у них принципиально разный. Без риск-балла в формуле проект B выглядел бы безобидным середнячком. С риск-баллом видно: он требует внимания, несмотря на среднюю ценность.

Пять методов приоритизации задач в 2026 году описывают скоринг-модели, которые учитывают несколько факторов одновременно. Матрица рисков органично встраивается в такие модели как один из факторов.

Связь с бэклогом работает в обе стороны: задачи из бэклога — источник для идентификации новых рисков. Задача, которая заблокирована или зависит от внешнего подрядчика, — потенциальный риск. Когда разработчик добавляет в бэклог задачу с пометкой «ждём API от партнёра», это сигнал: зависимость нужно оформить как риск с оценкой вероятности задержки и влияния на дедлайн. Если она не попала в реестр, матрица неполная.

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

Часто задаваемые вопросы о матрице рисков в управлении проектами

Мы уже ведём риски в Excel — зачем переносить в PM-систему?

Excel не связывает риск с задачей, проектом и владельцем в одном пространстве. Когда риск реализуется, менеджер открывает таблицу, ищет строку, потом идёт в таск-трекер создавать задачу, потом пишет в чат владельцу. В PM-системе риск уже является задачей с владельцем, привязан к проекту и виден в общем потоке. Rollup-поля автоматически считают количество красных рисков на уровне портфеля. Excel этого не умеет без ручной сборки.

Какой размер матрицы выбрать — 3×3, 4×4 или 5×5?

Матрица 4×4 подходит, если работаете по российским нормативам: Приказ № 585 закрепляет четыре уровня вероятности и четыре уровня последствий. Матрица 5×5 даёт более гранулярную шкалу (диапазон 1–25 баллов) и лучше подходит для крупного портфеля, где важно различать риски внутри одной зоны. Матрица 3×3 — только для экспресс-оценки на старте, когда данных мало. Если портфель смешанный — часть проектов по госконтрактам, часть коммерческие — удобнее остановиться на 5×5: она покрывает оба случая.

Команда не хочет тратить время на реестр — что делать?

Начните с пяти минут на ретро: каждый участник называет один риск, который его беспокоит. Менеджер заносит в карточку с баллами прямо во время встречи. Через три спринта у вас будет реестр из 15–20 рисков, собранный без единого отдельного воркшопа. Когда команда увидит, что матрица предсказала проблему раньше, чем она случилась, сопротивление уходит само.

Чем матрица рисков отличается от SWOT-анализа?

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

Матрица рисков — про ясность, а не про контроль

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

Матрица делает неопределённость видимой и управляемой. Но только при условии, что её регулярно пересматривают, а не вешают на стену как артефакт.

Для старта достаточно четырёх шагов. Завести реестр рисков как задачи в PM-системе с полями вероятности (1–5) и влияния (1–5) — каждый риск отдельной карточкой с владельцем и планом реагирования. Настроить фильтр «красная зона»: проекты с тремя и более рисками с баллом 13+ автоматически попадают в приоритет руководителя портфеля. Включить пересмотр матрицы в повестку еженедельного статус-митинга — не как отдельное мероприятие, а как стандартный пункт: «что изменилось в рисках за неделю». Через месяц после запуска сравнить, как изменилось распределение управленческого внимания: сколько эскалаций пришло и сколько из них совпало с красной зоной матрицы.

Конкретный критерий: если доля эскалаций, совпавших с красной зоной, превышает 70% — матрица работает как предиктор, и её стоит развивать. Если совпадение ниже 50% — пороги нуждаются в калибровке, а реестр — в пополнении. В обоих случаях вы получаете измеримый ответ на вопрос, стоит ли продолжать.