Реестр рисков проекта: шаблон и пример по записи встречи

Риск ещё не случился, проблема уже есть

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

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

Как собрать реестр по обсуждению команды

1. Выделите фразы с неопределённостью

   В записи ищите «если», «зависит от», «пока не знаем», «может не успеть». Не каждое предположение становится риском. Уточните, к какому результату проекта оно относится.

2. Разложите формулировку на три части

   Причина или условие → возможное событие → последствие. Не пишите фамилию вместо причины: «согласование зависит от одного человека» точнее, чем «риск — Алексей».

3. Согласуйте оценку с командой

   Отдельно оцените вероятность и влияние. Для небольшого проекта можно использовать словесные категории с понятными пояснениями. Не выдавайте субъективный балл за вычисленную вероятность.

4. Назначьте владельца наблюдения

   Этот человек отслеживает сигнал, собирает данные и поднимает вопрос. Он не обязан один устранять все причины и не становится виноватым, если событие произошло.

5. Запишите действие до события и после него

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

6. Назначьте следующую проверку

   Проверяйте запись на важных этапах и при новых данных. Закрывайте риск только с объяснением: зависимость снята, событие уже произошло либо соответствующий этап завершён.

Тестовый доступ для интеграции

Это вымышленный фрагмент созвона. Из него нельзя автоматически заключить, что поставщик обязательно сорвёт срок. Можно завести запись и отдельно подтвердить статус заявки.

Здесь намеренно нет вероятности «70%»: у команды нет достаточных данных для такого числа. После ответа поставщика оценку можно уточнить. Дата и время сигнала позволяют не возвращаться к одному опасению на каждом созвоне без новых фактов.

Реестр должен меняться вместе с проектом

Если доступ выдали, проверьте, что он действительно работает. Само письмо «доступ готов» ещё не подтверждает снятие зависимости. Если риск реализовался, свяжите его с текущей проблемой и выполнением запасного плана. Если вероятность снизилась, сохраните причину изменения.

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

Минимальный реестр для своей команды

ID и дата обнаружения:
Цель или этап проекта:
Если [условие], может [событие], из-за чего [последствие].
Источник: запись / таймкод / подтверждающий документ:
Вероятность и основание оценки:
Влияние и основание оценки:
Владелец наблюдения:
Действие заранее, исполнитель и срок:
Сигнал для запасного плана:
Запасной план и кто его согласует:
Следующая проверка:
Статус и причина изменения:

• Условие можно проверить, а не только почувствовать.
• Неопределённость не выдана за неизбежное событие.
• Понятно, кто следит за сигналом.
• У записи есть дата следующего просмотра.