12/10/2026
На длительном ИТ-проекте невозможно предусмотреть всё. Но многие проблемы можно заметить заранее и решить до того, как они повлияют на сроки, бюджет или качество продукта. Для этого рисками должен заниматься не только менеджер проекта: к обсуждению стоит подключать и команду, и заказчика.
В этом посте Елена Закатова, менеджер проектов Далее, делится главными советами о том, как управлять рисками спокойно и последовательно.
1. Обсуждайте риски еще до начала проекта
Стратегию работы с рисками лучше подготовить заранее: начать можно на этапе тендера или согласования работ. Команда и заказчик заранее оценят возможные последствия и договорятся, кто за что отвечает, если риск реализуется.
2. Сначала поговорите с командой и заказчиком отдельно
Не стоит сразу собирать всех на один созвон. В присутствии заказчика исполнители могут чувствовать давление и избегать открытого обсуждения всех возможных рисков.
Сначала обсудите возможные проблемы внутри команды, затем отдельно поговорите с клиентом. После этого можно встретиться всем вместе, сверить оценки и договориться о дальнейших действиях.
3. Обратитесь к профильным специалистам
Менеджер проекта не может самостоятельно и с одинаковой точностью оценить технические, юридические и финансовые риски. В обсуждении могут участвовать разработчики, технический директор, DevOps-инженеры, юристы и другие специалисты, чьи знания нужны на конкретном проекте.
4. Соберите риски в общем реестре
Реестр удобно вести в таблице, к которой есть доступ у команды и заказчика. Внесите в нее не только негативные, но и позитивные риски — на разных листах. Для каждого риска укажите:
• описание;
• вероятность;
• влияние на сроки, бюджет и качество;
• ответственного;
• план реагирования;
• текущий статус.
Начать можно с ситуаций, которые уже возникали на других проектах. Затем дополните реестр рисками, которые назвали участники текущего проекта.
5. Посчитайте возможные расходы
Расходы на риски лучше обсуждать открыто. Часть расходов на риски стоит сразу заложить в смету, например, увеличение трудозатрат на интеграции с внешними сервисами. Другую часть можно вынести на обсуждение с заказчиком — такие как увеличение серверных мощностей, апгрейд лицензий и так далее.
Для высоких рисков составьте отдельную смету. Она покажет команде возможные потери, а заказчику поможет заранее заложить нужную сумму в бюджет.
6. Подготовьте план реагирования
Укажите, на каком этапе может возникнуть риск, к каким последствиям он приведет, кто займется проблемой и сколько времени потребуется на её решение.
Разбирать каждый риск в плане реагирования необязательно. План нужен только для самых значимых рисков и тех, которые ведут за собой еще и другие угрозы для реализации проекта (связанные риски).
Важно: не всех рисков можно избежать. Для некоторых рисков максимум возможностей исполнителя — это минимизация последствий от их наступления.
7. Возвращайтесь к реестру по ходу проекта
На крупном проекте проверяйте реестр раз в неделю или в начале каждого спринта. Если произошёл инцидент, зафиксируйте, что случилось, как команда решила проблему, сколько времени и денег потребовалось и как ситуация повлияла на проект.
8. Обсуждайте
Выносите риски на ретро, но никогда не ругайте сотрудников. Это должна быть минутка рефлексии, где вы обсуждаете инциденты и реакцию на них, анализируете свою стратегию, обновляете реестр рисков и корректируете план реагирования.
Это касается и статусов с заказчиком: возвращайтесь к реестру рисков, обсуждайте инциденты, последствия и затраты на их устранение.
Совместная работа с рисками делает проект предсказуемее. Команда понимает, как действовать при проблемах, а заказчик заранее знает о возможных последствиях и расходах.
---------------------------------------------------------
Подробнее об инструментах с примерами из практики Лены смотрите в ее докладе на Городе ИТ https://vkvideo.ru/video-213987283_456239223?list=ln-bzvZpRRRw2CQysqUzI
