Корректная оценка проекта – одно из ключевых условий его успешной реализации. Она определяет бюджет, сроки, состав команды и, по сути, формирует среду для всех участников процесса. Однако в практике ИТ-проектов ошибки в оценке встречаются постоянно. Причины могут быть разными – от неполноты требований до неправильной декомпозиции работ или игнорирования рисков.
Когда оценка проекта оформлена как связанный набор требований, задач, исполнителей и рисков, она превращается в структурированный объект, над которым можно выполнять новые и полезные операции. С ней уже удобно сопоставлять требования, проверять логику разбиения и искать скрытые риски. А передав такую структуру генеративному искусственному интеллекту, можно получить независимый экспертный взгляд еще до этапа защиты оценки.
Давайте разберемся, насколько такой подход может нам помочь получить более точную оценку проекта. Для этого обратимся к основных причинам ошибок и посмотрим, как подход, реализованный в системе Project Calc, позволяет выявить и нивелировать многие из них.
Ошибки в оценке могут возникать из-за множества обстоятельств, объединим их в пять групп.
5 причин, по которым оценка проекта оказывается неверной
1. Неполнота требований, их изменения в ходе проекта
Это наиболее распространенная причина расхождения между оценкой и фактическими затратами. Проблемы возникают, когда:
-
требования сформулированы поверхностно;
-
не выявлены важные, существенные состояния системы;
-
аналитики и оценщики по-разному трактуют функциональность;
-
игнорируются нефункциональные требования.
Изменения требований почти всегда являются следствием этой же проблемы – неполноты и неоднозначности начального описания.
2. Ошибки при декомпозиции задач
Вторая ключевая группа ошибок – неправильное разбиение проекта на задачи. А именно:
-
слишком крупные или слишком мелкие задачи;
-
абстрактные формулировки задачи (“проверка”, “сделать отчет”);
-
несоответствие между требованиями и задачами;
-
копипейст-ошибки;
-
пропуск вспомогательных и обязательных работ: тестирования, документация, развертывание, управление проектом.
3. Переоценка компетенций команды и технологических возможностей
Переоценка это ожидание, что команда сделает больше и быстрее, чем позволяет реальный опыт и производительность. Это происходит, когда:
-
отсутствует системный учет предыдущих проектов;
-
проектная команда впервые работает с технологией;
-
у заказчика сформированы завышенные ожидания;
-
сознательное занижение трудоемкости проекта.
В результате срок и стоимость выглядят прагматично, но не имеют под собой реальной базы.
4. Игнорирование рисков и неопределенности
По сути, неполнота требований, слабая декомпозиция и переоценка это тоже риски. Однако существует отдельный пласт рисков, которые традиционно недооцениваются:
-
интеграционные и миграционные риски;
-
регуляторные ограничения;
-
риски внешних зависимостей;
-
риски инфраструктуры и производительности;
-
организационные риски.
Именно игнорирование подобных факторов приводит к каскадному росту сроков в ходе реализации проекта.
5. Плохое управление проектом
Даже правильно составленная оценка может оказаться неадекватной из-за ошибок в управлении:
-
отсутствие контроля изменений;
-
некачественное управление ресурсами;
-
слабое планирование и отсутствие прозрачности.
На этапе оценки это невозможно исправить, но можно заранее дать рекомендации, которые повысят шансы на успешную реализацию.
Почему важен анализ оценки проекта
Оценка – это модель проекта, в которой легко спрятать ошибки: неполные требования, неточная декомпозиция, неверные допущения о технологии, игнорированные риски или управленческие перекосы. Анализ позволяет выявить эти слабые места до старта работ.
Если оценка представлена как структурированная система, ее можно проверить так же, как спецификацию: убедиться в полноте, логике и согласованности. А загрузив такую структуру в ИИ, можно получить независимую экспертизу и увидеть проблемы, которые обычно проявляются только в ходе проекта.
Как анализ оценки реализован в Project Calc
Необходимо отметить, что требования к проекту в системе Project Calc должны быть загружены в систему – только после этого возможен анализ оценки проекта. Те. анализ происходит за счет того, что по сути сопоставляются требования и оценка, выполненная на основе этих требований.
Система Project Calc передает в ИИ документы проекта, дерево задач, дерево исполнителей, риски, дополнительные сведения и с помощью промптов заставляет ИИ выполнить роль независимого эксперта. Искусственный интеллект выполняет анализ оценки проекта по следующим восьми ключевым разделам:
-
Полнота охвата требований;
-
Качество исходных документов;
-
Детализация оценки;
-
Согласованность документов;
-
Адекватность трудоемкости, сроков, стоимости;
-
Анализ рисков;
-
Типовые слабые места в оценках;
-
Выводы и рекомендации.
Результат анализа – это отчет, который подсвечивает зоны (предположительно проблемные), на которые требуется обратить внимание. Напимер, при проверке согласованности терминологии система может выдавать следующее заключение:
4.2 Совпадение терминологии ТЗ и оценки
Терминология в ТЗ и дереве задач в целом совпадает: используются одни и те же понятия для модулей, ролей, процессов. Встречаются незначительные расхождения в формулировках (например, “бабушки” vs “пациенты учреждения”), но они не влияют на понимание структуры проекта. В целом, согласованность терминологии высокая.
Пример: как работает система
Чтобы получить отчет, необходимо заполнить пошаговую форму с уточняющими вопросами.

В результате мы получаем интерактивный отчет, который состоит из восьми разделов. В качестве примера рассмотрим раздел “Полнота охвата требований”. Этот раздел отвечает за соответствие задач требованиям проекта. Он состоит из следующих блоков.
1. Покрытие требований задачами
На крупных проектах до 20% требований пропускаются или игнорируются. Исследования показывают, что разработчики склонны не замечать непонятные или неоднозначные требования (эффект “избирательной слепоты”).
ИИ находит такие пробелы и указывает, какие требования не нашли отражения в оценке.
Пример
1.3 Требования, не покрытые задачами в дереве
В спецификации присутствуют требования, которые не нашли отражения в дереве задач:
– Безопасное хранение персональных данных и соответствие законодательству РФ (ФЗ-152) – нет отдельной задачи на аудит или внедрение мер безопасности.
– Система разграничения прав доступа – нет отдельной задачи на проектирование и реализацию ролевой модели.
– Адаптивный дизайн публичной части – задачи по фронтенду не выделяют адаптивность как отдельную работу.
2. Задачи без требований
Обратная ситуация, когда в оценке есть задачи, но неясно, к каким требованиям они относятся. Причины:
-
многократные корректировки оценки;
-
за основу взяли старую версию оценки или чужую оценку;
-
“позолота”, избыточный функционал, украшательство.
Такие задачи при защите проекта очень сильно снижают доверие к оценке, порождают критику и могут использоваться для дискредитации оценки и занижения трудоемкости проекта.
Пример
1.4 Задачи без соответствия в спецификациях
В дереве задач встречаются задачи, которые не имеют явного отражения в спецификации:
– Документооборот в модуле координаторов – в ТЗ не описан отдельный документооборот для координаторов, возможно, это копипейст или устаревшая задача.
– Документооборот в модуле волонтеров – аналогично, в ТЗ нет отдельного документооборота для волонтеров.
3. Абстрактные задачи
ИИ находит задачи со непонятными, ничего не значащими названиями, такими как “Анализ” или “Сделать отчет”. Обычно это признаки:
-
низкой вовлеченности исполнителей;
-
большого количества исправлений;
-
спешки;
-
отсутствия четкого понимания требований.
Пример
1.5 Абстрактные или неконкретные задачи в дереве задач
В дереве задач встречаются задачи с абстрактными или неконкретными названиями, например:
– Общая задача по интеграции – не раскрывает, с какими системами и по каким сценариям будет интеграция.
– Общая функциональность в кабинете координатора и волонтера – неясно, какие именно функции включены.
А что насчет ошибок самого ИИ?
Любая LLM может ошибаться и “галлюцинировать”. Это касается и анализа оценки. Однако в Project Calc это не слишком критично по трем причинам:
-
цель ИИ состоит в подсветке потенциальных проблемы, конечное решение принимает человек.
-
ошибки легко проверить, так как отчет содержит ссылки на конкретные задачи.
-
серьезные ошибки возникают редко, так как проверка основана на структурированных данных оценки.
Интересный парадокс – ИИ указывает на “проблему” в оценке. Руководитель проекта проверяет ее и понимает, что настоящей проблемы нет, просто формулировка была неточной или контекст недостаточно ясен. Но в итоге оценка все равно становится лучше: либо за счет более глубокого понимания, либо благодаря тому, что формулировки были уточнены.
Обратно к пяти причинам
Давайте вернемся к пяти ключевым причинам, из-за которых оценка проекта может получиться недостаточно точной, и посмотрим, какие из них помогает закрыть система Project Calc.
1. Неполнота требований, их изменения в ходе проекта
Project Calc позволяет уменьшить неопределенность на этом этапе за счет:
-
оценки качества исходных документов, включая полноту и структурированность требований;
-
выявления проблемных зон, где требования сформулированы расплывчато, противоречиво или неполно;
-
фиксации рисков, связанных с возможным появлением новых требований. Система подсвечивает участки, где сценарии явно не закрыты.
2. Ошибки при декомпозиции задач
ИИ анализирует структуру оценки и указывает на случаи:
-
слишком мелких или слишком крупных задач, нарушающих баланс декомпозиции;
-
абстрактных или неконкретных формулировок, требующих уточнения;
-
копирования задач, которые могут быть ошибочными или нерелевантными;
-
неявных работ, которые отсутствуют в спецификации, но обычно присутствуют в реальных проектах (тестирование, документация, управление проектом, развертывание и т.п.).
3. Переоценка компетенций команды и технологических возможностей
Project Calc анализирует:
-
пропорциональность распределения работ между задачами, что пом��гает обнаружить нереалистичные ожидания;
-
характеристики команды проекта, подсказывая, соответствует ли заявленная оценка реальным возможностям исполнителей;
-
требования и задачи, для которых недостаточно квалификации заявленной команды проекта.
4. Игнорирование рисков и неопределенности
Система выполняет расширенный анализ рисков, включая:
-
оценку полноты списка рисков, сформированных в ходе оценки;
-
рекомендации по уточнению неясных рисков;
-
выявление полностью неучтенных рисков, которые обычно встречаются в аналогичных проектах;
-
поиск случаев переоценки рисков, когда влияние или вероятность указаны неоправданно высокими.
5. Плохое управление проектом
Система Project Calc не управляет проектом напрямую. Однако благодаря тому, что в системе выполняется декомпозиция задач, выявляются риски и производится оценка трудоемкости, все это сказывается на управлении проекта. Прежде всего за счет того, что проект получает адекватное пространство для реализации планов как с точки зрения ресурсов, так и сроков. Это снижает вероятность управленческих ошибок и улучшает качество планирования.
Пример
Ниже можно скачать отчет, который построила система, используя в качестве исходных данных:
-
функциональную спецификацию;
-
описание архитектуры проекта;
-
оценку проекта, подготовленную в системе .
К сожалению, нам не разрешили привести в статье в качестве иллюстрации спецификации, но мы можем показать итоговый отчет. Он достаточно информативен сам по себе, и на его основе можно понять качество и глубину анализа оценки.
Модель, версия: ChatGPT, gpt-4.1.
Отчет можно скачать здесь.
Выводы
Анализ оценки проекта – это важнейший этап подготовки к защите бюджета или заключению контракта. Он позволяет заранее обнаружить несоответствия, слабые места и риски, которые могли бы привести к перерасходу бюджета, срыву сроков и потере доверия.
Использование ИИ так, как это реализовано в Project Calc, позволяет:
-
автоматизировать экспертную подготовку оценки проекта;
-
повысить качество оценки;
-
увидеть проблемы заблаговременно;
-
уменьшить неопределенность;
-
улучшить качество принятия решений.
ИИ не заменяет опыт, ИИ не заменяет людей, но он в состоянии сделать работу руководителя проекта гораздо более эффективной. Например, справляться с задачами по анализу оценки гораздо быстрее и не упускать из вида громадное количество деталей. И чем больше и сложнее проект, чем больше команд в нем принимает участие, тем важнее и полезнее становится такая помощь.
—
Напомню, лендинг здесь projectcalc.ru, система здесь app.projectcalc.ru. Для работы в системе предусмотрена простая регистрация, денег за работу в системе не просим, но есть ограничения, например, на число проектов или размер загружаемых документов. ИИ функции по запросу.
Вопросы, мысли и пожелания можно сюда info@projectcalc.ru.
Автор: WFF


