Почти в каждом проекте есть момент, когда кто-то говорит: «Ну мы же предупреждали». И это, пожалуй, самая неприятная фраза в проектном управлении. Так как она означает, что проблема была не в том, что команда не знала о рисках. Проблема была в том, что знание о рисках никак не повлияло на решения.
Реестр рисков в таком случае превращается не в инструмент управления проектом, а в кладбище тревожных мыслей. А что вообще такое Риск?
Риск — это не «мы можем не успеть»
Во многих командах из моей практики риск формулируется примерно так: «есть риск срыва сроков». Звучит знакомо, но как управленческая единица это почти бесполезно.
Из такой формулировки непонятно, что именно может случиться, почему это может случиться, на что это повлияет, когда нужно начинать действовать и кто вообще за этим следит.
Это не риск. Это тревожный прогноз. Нормальный риск должен звучать конкретнее:
— если API вендора не будет стабилизировано до 15 мая, backend-команда не сможет завершить интеграцию до code freeze, что сдвинет релиз минимум на один спринт.
Вот с этим уже можно работать. Тут есть причина, срок, последствие и понятная зона ответственности.
Хорошая формула риска: Если случится X, то мы получим Y, поэтому заранее делаем Z.
Например: Если до среды команда не получит доступы к тестовому окружению, то тестирование интеграции сдвинется минимум на три дня, поэтому во вторник эскалируем вопрос через владельца инфраструктуры.
Разница: плохой риск просто фиксирует страх. Хороший риск заставляет команду принять решение.
Почему реестр рисков часто не работает
На бумаге всё выглядит правильно: есть таблица, есть вероятность, есть влияние. Но проект всё равно горит. Почему?
Потому что чаще всего реестр рисков живёт отдельно от реального управления проектом.
Он не влияет на roadmap.
Не меняет scope.
Не влияет на релизный план.
Не заставляет пересмотреть сроки.
Не поднимает вопросы к бизнесу.
Не приводит к техническим решениям: feature toggle, rollback, fallback, дополнительный мониторинг.
Не помогает команде сказать: «Вот здесь мы не готовы идти дальше».
В итоге риск вроде бы есть, но он ничего не меняет. А риск, который не влияет на решения, — это просто оформленная тревожность.
Также есть вредная иллюзия, что рисками должен заниматься project manager. В реальности PM может вести реестр, фасилитировать обсуждение и подсвечивать последствия, но источники рисков находятся внутри всей команды:
Разработчик видит технический риск раньше PM.
QA видит риск качества раньше бизнеса.
Аналитик видит риск требований раньше разработки.
Архитектор видит риск масштабирования раньше пользователей.
DevOps видит риск инфраструктуры раньше релиза.
Поддержка видит риск пользовательского негатива раньше продуктовой аналитики.
Поэтому хороший реестр рисков — это не PM-таблица. Это общий инструмент команды. Например:
Технические риски: монолит не выдержит нагрузку, легаси-сервис плохо документирован, интеграция зависит от нестабильного API, нет owner-а у критичного компонента.
Релизные риски: нет rollback-плана, нет feature toggle, не определены критерии go/no-go, нет понятного плана отката миграции.
Риски данных: возможен рассинхрон между сервисами, непонятно, какой сервис является источником истины, нет плана восстановления данных после ошибки.
Продуктовые риски: фича не решает пользовательскую боль, метрики успеха не определены, маркетинг обещает одно, продукт делает другое.
Организационные риски: ключевой эксперт один, подрядчик задерживает поставку, решение зависит от человека, который недоступен, команда перегружена параллельными инициативами.
Как должен выглядеть нормальный риск
Минимальная карточка риска может быть очень простой.
Поле | Что писать |
Риск | Что может случиться |
Причина | Почему это может случиться |
Последствие | На что повлияет: сроки, деньги, качество, пользователи |
Вероятность | Низкая / средняя / высокая |
Влияние | Низкое / среднее / высокое |
Владелец | Кто следит и инициирует действия |
Триггер | Когда риск случится |
План реакции | Что делаем заранее или при наступлении |
Статус | Открыт / наблюдаем / реализовался / закрыт |
Пример:
Поле | Пример |
Риск | Интеграция с вендором может не быть готова к code freeze |
Причина | API нестабилен, спецификация менялась дважды за неделю |
Последствие | Релиз B2B-функционала сдвинется минимум на один спринт |
Вероятность | Высокая |
Влияние | Высокое |
Владелец | Tech Lead backend |
Триггер | До 15 мая нет финальной спецификации |
План реакции | Режем scope, выносим интеграцию во второй этап, готовим заглушку |
Статус | Наблюдаем |
Risk score: полезная штука, если не превращать её в театр математики
Часто риски оценивают через простую формулу: Risk Score = Probability × Impact — и на мой взгляд ее достаточно!
Например, вероятность от 1 до 5 и влияние от 1 до 5. Итоговая оценка — от 1 до 25.
Риск | Вероятность | Влияние | Score |
Нет rollback-плана | 3 | 5 | 15 |
Зависимость от одного разработчика | 4 | 4 | 16 |
Не готова аналитика | 5 | 3 | 15 |
API вендора нестабилен | 4 | 5 | 20 |
Но здесь есть важный момент: risk score — это не точная математика. Risk score нужен чтобы заставить команду договориться, какие риски нельзя игнорировать.
Если риск получил высокий score, он должен менять план. Например: сдвигать сроки, резать scope, добавлять буфер, менять архитектурное решение, запускать spike, подключать эксперта, требовать решения от бизнеса, менять релизную стратегию.
Если высокий риск ничего не меняет, значит, команда не управляет рисками. Она их коллекционирует.
Реестр рисков должен менять поведение команды. Главная проверка любого реестра очень простая: Что изменилось после того, как мы добавили этот риск?
Если ответ — «ничего», реестр не работает. Рабочий реестр рисков должен влиять на реальные решения:
нужно ли менять scope;
нужно ли добавить буфер;
нужен ли feature toggle;
нужен ли rollback;
нужно ли резать релиз;
нужно ли подключать архитектора;
нужно ли идти к бизнесу и менять ожидания;
нужно ли останавливать задачу до уточнения требований;
нужно ли закладывать время на миграцию данных;
нужно ли делать дополнительный мониторинг после релиза.
Например, команда видит риск рассинхрона данных между старым монолитом и новым сервисом. Плохой вариант — просто записать это в таблицу. Хороший вариант — договориться:
что является источником истины;
как проверяем консистентность;
что делаем при расхождении;
кто мониторит;
как откатываемся;
при каком уровне ошибок останавливаем раскатку.
Вот это уже хороший риск менеджмент.
Почему команды игнорируют риски, даже когда их видят
Причина не всегда в некомпетентности. Часто это системная проблема.
Команда может видеть риск, но не иметь полномочий изменить план.
Бизнес может не хотеть слышать плохие новости.
PM может бояться эскалации.
Разработчик может думать: «Ну я сказал, дальше не моя зона».
Тимлид может надеяться, что «как-нибудь проскочим».
Руководство может считать, что признание риска — это слабость команды.
В итоге появляется странная управленческая шизофрения: риск известен, но официально его как будто нет.
Все всё понимают, но продолжают идти по старому плану. А потом случается классическое: «Ну мы же предупреждали». Только пользователям, бизнесу и релизу от этого не легче.
Что в итоге
Реестр рисков нужен не для того, чтобы потом доказать: «мы предупреждали». Он нужен, чтобы команда раньше увидела слабое место проекта и изменила план до того, как риск превратился в пожар.
Если риск не влияет на сроки, scope, архитектуру, релизный план, коммуникацию с бизнесом или техническое решение — это не управление рисками, а документация будущего провала.
И, возможно, главный вопрос, который стоит задавать на проекте не «какие у нас риски?», а «что мы готовы изменить уже сейчас, чтобы через месяц не говорить: “ну мы же предупреждали”»?
Еще больше статей про проектное управление:
https://habr.com/ru/companies/viju/articles/1028914/ - Большинство проектов тормозит не разработка, а вежливость: никто не говорит нет
https://habr.com/ru/companies/viju/articles/1031294/ - Проектный менеджмент умер: почему проекты больше не ведут, а только синхронизируют)