Реестр рисков проекта: как отличить риск от уже возникшей проблемы

Путаница в реестре рисков начинается не из-за терминов, а из-за формы записи. В один список попадают будущие сбои, уже найденные дефекты, просроченные материалы и просто тревожные темы вроде «аналитика» или «домен». Потом команда смотрит на реестр и не понимает, что нужно предупреждать заранее, а что уже надо срочно исправлять.

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

Учебный пример. Условная команда запускает промосайт из 7 страниц в пятницу в 18:00. Для запуска критичны три вещи: финальные тексты для блока тарифов из 12 карточек должны прийти до среды 12:00, переключение домена на боевой сервер должно пройти до четверга 15:00, а контейнер аналитики с 6 событиями должен быть опубликован и проверен до пятницы 11:00. В команде есть менеджер проекта, контент-менеджер, разработчик и аналитик. Денежные оценки и вероятности не используем: нас интересует только различие между риском и уже возникшей проблемой.

Событие и последствие

Хорошая запись в реестре рисков описывает не тему, а возможное будущее событие и его эффект на проект. Формула простая: если произойдет X, то пострадает Y. Без этого реестр не помогает действовать. Запись «домен» ничего не объясняет: это зависимость, объект или просто слово. А запись «если домен не переключится до четверга 15:00, сайт не откроется на основном адресе к моменту запуска» уже годится для решения.

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

Полезная привычка: проверять каждую строку вопросом «что именно может случиться?» и «что это сломает?». Если ответа нет, перед вами не риск, а заметка для обсуждения. Ее лучше превратить в конкретную формулировку или убрать из реестра, чтобы он не размывался.

Риск и факт

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

В учебном кейсе до среды 12:00 запись про тексты — риск. В 12:30 команда смотрит статус и видит: из 12 карточек согласованы только 5, остальные не пришли. С этого момента строка больше не должна жить в реестре рисков в прежнем виде. Событие уже произошло. Теперь это проблема: «к сроку не получены 7 из 12 карточек для блока тарифов». Если оставить ее как риск, команда будет делать вид, будто у нее еще есть время только наблюдать, а не принимать решение.

Иногда один и тот же участок работы порождает и проблему, и новый риск рядом с ней. Например, текущая проблема — не хватает 7 карточек. А новый риск может звучать так: «если к пятнице 14:00 не будет согласован сокращенный состав блока, главная страница не пройдет финальную сборку». Это не бюрократия, а нормальная развязка по времени. Факт исправляем как проблему, а следующий возможный сбой держим как риск, пока он еще не случился.

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

Ответственный и ответ

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

В учебном запуске удобно развести роли так: контент-менеджер отвечает за риск по текстам, менеджер проекта — за риск по домену, аналитик — за риск по публикации контейнера. Ответ тоже должен быть сформулирован заранее. Не «разберемся», а конкретно: сократим блок, проведем проверку переключения, подготовим минимальный набор событий для первого релиза.

Обратите внимание на разницу между риском и проблемой у первой строки. Пока среда не наступила, ответ — подготовить запасной вариант блока. После 12:00, если тексты не пришли, ответ меняется: нужно не готовиться, а принять решение, какой состав блока идет в релиз и кто обновит страницу. То есть один и тот же человек может остаться владельцем темы, но тип действия меняется вместе со статусом записи.

Условия пересмотра

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

В нашем примере условия простые и проверяемые. Для текстов — среда 12:00 и факт получения всех 12 карточек. Для домена — четверг 15:00 и успешное открытие сайта на основном адресе. Для аналитики — пятница 11:00 и прохождение чек-листа по 6 событиям. Такое описание убирает спор «еще подождем или уже эскалировать»: команда заранее знает момент смены статуса.

Проверяемый результат в учебном кейсе выглядит так. В среду в 12:30 риск R1 превращается в проблему I1, потому что из 12 карточек готовы только 5. Команда выпускает блок тарифов в сокращенном виде на 5 карточек, а недостающие 7 выводит из состава текущего релиза. В четверг в 14:20 риск R2 закрывается: переключение подтверждено, сайт открывается на основном адресе. В пятницу в 10:40 закрывается риск R3: аналитик публикует контейнер и подтверждает 6 событий по чек-листу. К 17:00 в реестре рисков не остается «висящих» тем: 2 записи закрыты, 1 переведена в журнал проблем и обработана отдельно.

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

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