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

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

Но на самом деле это не внезапность, а накопление.

В работе PM важно научиться различать два состояния реальности.

Риск — это то, что может произойти.
Проблема — это то, что уже произошло.

И между ними всегда есть промежуток, в котором можно было повлиять на ситуацию.

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

И именно в этом промежутке между «может быть» и «уже случилось» и находится зона ответственности PM.

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

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

Это иллюзия стабильности. Очень часто именно в этот момент проект уже начал отклоняться от плана, просто ещё не проявил это открыто.

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

В какой-то момент становится понятно, что старый план больше не работает. Но это не новая проблема, а старая проблема, которую не остановили вовремя.

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

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

После фиксации реальности проект нужно пересобрать. Старый план перестаёт быть рабочим инструментом и превращается в исторический документ.

Теперь задача PM — определить, что действительно критично для результата. Какие элементы можно упростить. Что можно перенести без ущерба для цели.

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

Любой кризис сводится к ограничению выбора. Невозможно одновременно сохранить:

• исходный объём;
• исходный срок;
• исходное качество.

Что-то неизбежно меняется. Задача PM — не избегать этого выбора, а сделать его прозрачным и управляемым.

В нормальном режиме коммуникация — это обмен информацией. В кризисе — это инструмент управления ожиданиями и решениями и здесь критично не только что сказать, но и как.

Неправильная коммуникация выражается в тревожных формулировках («у нас проблемы», «мы не успеваем»), тогда как правильная строится на фактах, причинах и сценариях.

Например:
PM объясняет, что проект отклонился от плана из-за конкретного этапа и предлагает несколько вариантов: сохранить объём сдвинув срок или сохранить срок сократив часть функционала. В этом случае клиент не теряет контроль над ситуацией.

В обычной ситуации PM координирует процесс. В кризисе он превращается в систему принятия решений, он собирает факты, пересчитывает план, определяет приоритеты, убирает лишнее и выстраивает новый маршрут движения проекта.

Это уже не операционная работа, а управление структурой проекта в изменившейся реальности.

Интересный эффект кризисов в том, что они показывают не только проблему, но и архитектуру проекта:

• где не было контроля;
• где не учли зависимости;
• где план оказался слишком оптимистичным;
• где коммуникация не работала.

И в этом смысле кризис — это не только риск, но и диагностика системы.

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

Реестр рисков — документ, который появляется ещё до того, как проект начал жить. Он формируется не в середине проекта и не «по мере появления проблем», а создаётся сразу после того, как готово ТЗ и зафиксирован объём работ, но ещё до старта исполнения. Именно в этот момент проект впервые становится прозрачным.

Что это такое на практике

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

Обычно туда попадают вещи, которые в момент старта кажутся «не критичными», но в реальности почти всегда влияют на сроки и качество. Например:

• задержка материалов от клиента;
• неоднозначность требований;
• сложность интеграций;
• перегруз команды;
• зависимость задач друг от друга.

Как он формируется

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

• Где есть зависимости?
• Где есть неопределённость?
• Где есть внешние участники?
• Где возможны задержки?

И каждое такое место фиксируется как риск.

Как он выглядит (структура)

Чтобы реестр был не формальностью, а рабочим инструментом, он всегда содержит несколько обязательных элементов:

• описание риска (что может пойти не так);
• вероятность (низкая / средняя / высокая);
• влияние на проект (срок / бюджет / качество);
• триггер (по какому сигналу риск становится проблемой);
• план реакции (что делаем, если это случилось).

Шаблон реестра рисков.

Почему это критично

Реестр рисков делает одну важную вещь — он убирает иллюзию неожиданности. Потому что в хорошо управляемом проекте почти ничего не происходит внезапно. Всё уже было описано заранее — просто не наступило время активации.

Как он используется

Важно понимать: реестр рисков — это не документ для галочки. Он живой и используется на протяжении всего проекта. PM возвращается к нему:

• перед стартом каждого этапа;
• при изменении объёма работ;
• при задержках;
• при коммуникации с клиентом.

И самое главное — он позволяет не реагировать хаотично, а действовать по заранее продуманным сценариям.

Как это связано с кризисом

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

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

Опытный PM не тот, кто избегает кризисов, а тот, кто видит их раньше остальных и умеет вернуть проект в управляемое состояние, пока ещё есть пространство для действий.