Руководитель проекта должен заранее прикинуть возможные срывы по ходу работы и держать под рукой план действий на каждый такой случай — нейросеть собирает черновой реестр рисков по плану и техническому заданию проекта за 20–30 минут вместо пары часов мозгового штурма командой.

Что делает модель

TL;DR

По прайсам сервисов на сентябрь 2026, нейросеть собирает черновой реестр из 10–15 рисков проекта с оценкой вероятности, влияния и мерой реагирования за 20–30 минут вместо двух часов мозгового штурма командой на стартовой встрече.

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

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

На практике внедрений типовой прогон по среднему проекту — сайт с интеграцией, внутренний сервис или запуск бота — даёт 12–18 рисков, из которых половина повторяется от проекта к проекту (задержка подрядчика, изменение требований, болезнь ключевого специалиста), а вторая половина специфична именно для этого технического задания.

Подбор модели

ChatGPT и Claude предлагают более разнообразный набор рисков за счёт широкого охвата типовых сценариев из разных отраслей — полезно для нетиповых проектов, где легко упустить редкий, но серьёзный по влиянию риск. GigaChat и YandexGPT быстрее собирают стандартный набор рисков для типового проекта, знакомого модели по частым запросам.

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

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

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

Шаблон промпта

  1. Загрузить план проекта с этапами и задачами, а также исходное техническое задание.
  2. Попросить модель предложить 10–15 рисков с привязкой к конкретному этапу плана.
  3. Задать оценку вероятности и влияния по простой шкале — низкая, средняя, высокая — для каждого риска.
  4. Отдельным запросом получить конкретную меру реагирования на каждый риск с высоким влиянием.
● Discovery · 1 час · бесплатно

Какой риск чаще всего срывает сроки на ваших проектах?

Прийти на Discovery →

Меры реагирования стоит запрашивать отдельным шагом после самого списка рисков — если попросить всё сразу одним запросом, модель часто даёт общие формулировки вроде «внимательно следить за ситуацией» вместо конкретного действия с датой и ответственным.

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

Где нужен человек

Показательный случай из практики: модель оценила риск «недоступность стороннего API для интеграции» как средний по вероятности — такая оценка типична для большинства проектов с внешней зависимостью. Руководитель проекта поднял эту строку до высокой вероятности, потому что знал деталь, недоступную модели: техподдержка именно этого сервиса уже дважды в этом квартале срывала оговорённые сроки ответа на инциденты у других клиентов компании, и об этом рассказал знакомый из другой команды.

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

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

Частые ошибки

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

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

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

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

Частые вопросы

Сколько рисков обычно включают в реестр среднего проекта?
По нашему опыту внедрений, рабочий реестр держит 10–15 рисков — меньше упускает значимые сценарии, а заметно больше усложняет реестр до состояния, когда команда перестаёт им реально пользоваться.
Можно ли показывать заказчику реестр рисков от нейросети без правок?
Стоит сначала дополнить его специфичными для конкретного проекта рисками и убрать общие формулировки реагирования — заказчик доверяет реестру больше, когда видит конкретные меры вместо универсальных фраз.
Чем реестр рисков проекта отличается от проверки правовых рисков сделки?
Проверка правовых рисков ищет проблемы в тексте договора — штрафные условия, ответственность сторон, спорные формулировки. Реестр рисков проекта смотрит на организационные и технические сценарии срыва сроков и бюджета уже в ходе самой работы.
Как часто стоит обновлять реестр рисков по ходу проекта?
Разумный ритм — сверка реестра на каждой контрольной точке проекта, обычно раз в две-четыре недели: часть рисков к этому моменту снимается, а новые появляются по мере продвижения работы.
Какая модель лучше находит редкие, нетиповые риски проекта?
ChatGPT и Claude обычно предлагают более широкий и разнообразный набор сценариев — полезно именно для нетиповых проектов, где легко упустить редкий, но серьёзный по влиянию риск.