Эту страницу открывают, когда проект начинает зависеть не только от плана, но и от неопределённости: внешние команды, нестабильные решения, сложные согласования, слабая доступность людей, технические сюрпризы или давление по срокам.
Risk log — это живой реестр рисков проекта. Его задача не просто перечислить угрозы, а помочь PM увидеть вероятные точки срыва заранее и управлять ими до того, как они превращаются в инциденты.
Что должно быть в сильном risk log
- формулировка риска как возможного события, а не уже случившейся проблемы;
- причина или источник риска;
- потенциальное влияние на проект;
- вероятность и серьёзность;
- владелец риска;
- меры предотвращения и план реакции;
- текущий статус наблюдения.
Когда особенно нужен
- проект зависит от внешних поставщиков или смежных команд;
- есть жёсткие даты, штрафы или обязательства;
- команда заходит в новые технологии или сложные интеграции;
- по проекту много допущений и слабая определённость;
- руководству важно видеть не только текущее состояние, но и будущие угрозы.
Как вести его правильно
1. Собирайте риски регулярно, а не только на старте проекта. 2. Формулируйте их так, чтобы было видно событие и его влияние. 3. Не путайте риск с уже случившимся blocker или issue. 4. Назначайте владельца и действие, иначе запись ничего не меняет. 5. Связывайте риск с status report и dependency register.
Практический шаблон
Минимальная запись в risk log становится рабочей, если в ней есть:
- формулировка риска в логике «если произойдёт X, это повлияет на Y»;
- вероятность и серьёзность;
- ранний сигнал, по которому риск можно заметить заранее;
- владелец и ближайшее действие;
- план реакции, если риск всё-таки реализуется.
Особенно важен ранний сигнал. Без него risk log часто превращается в статичный список угроз без реального механизма наблюдения.
Как использовать risk log в живой работе
Полезно не просто вести реестр, а регулярно задавать по каждому важному риску три вопроса:
- усиливается ли риск, ослабевает или остаётся без изменений;
- какой факт в проекте говорит об этом;
- нужно ли уже менять план, эскалировать или пересобирать ожидания.
Именно в этот момент risk log связывается не только со статусом, но и с пересборкой сроков, изменениями и ранними сигналами отклонения.
Что ломается без него
- команда постоянно «внезапно» сталкивается с предсказуемыми проблемами;
- эскалации происходят слишком поздно;
- статус проекта выглядит зелёным до самого момента серьёзного отклонения;
- PM реагирует только на уже случившиеся проблемы;
- руководство не понимает, почему проект сорвался, хотя ранние сигналы были видны.
Типовые ошибки
- записывать риски слишком общо: «могут быть проблемы»;
- не обновлять реестр после изменения контекста;
- путать риски с задачами и проблемами;
- не закрывать риски, которые уже не актуальны;
- не использовать risk log в реальных обсуждениях статуса и плана.