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

Если проект небольшой, полученная оценка может быть просмотрена глазами на предмет ошибок, недочетов и опечаток. А что делать, если оценка проекта большая, собиралась от нескольких команд (например, включая подрядчика) и правки в нее вносились бесконечное количество раз? 

Очевидно, что нужны соответствующие инструменты.

 В системе Project Calc есть два инструмента, которые решают эту проблему: отчет “Аномалии в оценке проекта” и “Анализ оценки проекта с помощью искусственного интеллекта”. 

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

Аномалии в оценке проекта 

Отчет “Аномалии в оценке проекта” состоит из двух отчетов.  

1. Слишком большое отклонение “от” и “до”. 

 Отчет ищет задачи, у которых: 

• указаны обе трудоемкости: трудоемкость от и трудоемкость до;
• разница между “от” и “до” в процентах больше, чем трудоемкость “от”;
• трудоемкость “от” больше заданной;
• задач не является родительской;
• задача не является зависимой.

Отчет не принимает во внимание текущую конфигурацию проекта, установленную с помощью модификаторов. Иными словами отчет анализирует все задачи, даже те, которые находятся в ветках, отключенных с помощью модификаторов.

Для чего нужен такой отчет?

Допустим, некая задача была оценена в трудоемкость от 1 до 2 дней. Что можно сказать про такую задачу? Это, скорее всего, несложная работа связанная, например, с разработкой простой формы. Так как задача небольшая, требования на нее логичные, вопросов к ней не возникает.  

Интересное наблюдение, что если другая задача оценивается в трудоемкость от 5 до 10 дней, возникает вопрос, а почему трудоемкость может вдруг увеличивается в два раза? Ответы на этот вопрос могут быть различными, но как правило, это означает, что оценщик не очень хорошо понимает специфику, т.е. у него есть обоснованные сомнения, что задача может “выйти боком” и занять гораздо больше времени. Например, оценщик видит, что спецификации недостаточно хорошо прописаны, у задачи есть сторонние зависимости, речь идет о внешней интеграции и так далее. И видя такие риски, человек, выполняющий оценку, здраво рассуждает, что надо перестраховаться в виде дополнительной трудоемкости. До этого момента все идет неплохо только если он вынесет и оформит свои сомнения в виде оценки и описания риска, которые он должен прикрепить к этой задаче.

Таким образом, правило хорошей оценки в упрощенной форме будет звучать так: “если у задачи слишком большое расхождение в оценке трудоемкости, задача должна содержать причину в виде оценки риска”. 

Давайте посмотрим, как это работает на практике.  

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

Далее мы просим систему показать нам задачи, у которых отклонение между “от” и “до” больше, чем 40% от оценки “от”. Так как поднят чекбокс “не показывать задачи с рисками”, в отчет не попадут задачи без выявленного риска. 

В результаты попало несколько задач, остановимся для примера на задаче “Закупка”, очевидно, что разброс по трудоемкости для такой задачи может быть связан с целым рядом проблем, например, логистикой, оплатой, изменением цены и т.п. Однако, до тех пор, пока эти проблемы не отражены в рисках, такая оценка задачи не может считаться качественной. Такая задача должна быть доработана с учетом рисков и проект, таким образом, получит не только уточненную оценку, но и явную зависимость от условий или событий, которые придется принимать во внимание при управлении проектом. 

2. Слишком маленькие и слишком большие задачи

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

• смысл задачи понятен и очевиден;
• трудоемкость задачи колеблется от 1-го до 2-х дней;
• у задачи один исполнитель.

Почему именно такая трудоемкость? Дело в том, если при оценке трудоемкость падает ниже 1-го дня, скорее всего, суммарная трудоемкость таких задач будет завышена. И наоборот, если трудоемкость выше 2-х человеко-дней, скорее всего, суммарная трудоемкость будет занижена. 

Это эмпирическое правило, и применять его нужно аккуратно.. Например, очень часто, спецификации не позволяют нам дойти до нужной глубины оценки в 1-2 дня и приходится оперировать очень общими задачами. С другой стороны, некоторые задачи требуют детальной декомпозиции- просто чтобы понять точный состав работ (каждая из которых может вносить один или два часа в общую трудоемкость).  

Так как оценку задач в системе Project Calc могут выполнять разные подразделения (например, юристы), филиалы и даже сторонние компании, обучить их такому правилу представляется довольно сложной задачей, однако можно выявить их не качественные оценки с помощью такого отчета.

В любом случае отчет позволяет перевести вопросы “Почему у нас существуют настолько мелкое дробление по задачам” и “Почему не выполнена декомпозиция целого ряда больших задач” в практическую плоскость- т.е. в список задач, формируемых данными отчетами.

Анализ оценки проекта с помощью искусственного интеллекта

Давайте для начала посмотрим, где располагается система Project Calc в жизненном цикле по разработке программного обеспечения. 

Жизненный цикл, согласно этой диаграмме, состоит из 4-х этапов. Этап A это формулирование проекта, т.е. подготовка документов, описывающих проект (спецификации, требования и т.п). Эти документы поступают на этап B, где в системе Project Calc происходит оценка проекта. Оценка проекта должна пройти защиту на этапе C (это, может быть например, подписание договора или защита бюджета в зависимости от типа компании). И после этого начинается этап D по реализации проекта.  

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

Такой механизм в системе Project Calc есть и он называется “Анализ оценки проекта с помощью искусственного интеллекта”. Этот отчет, который формируется на базе спецификаций и других требований с одной стороны и оценки проекты с другой. Отчет состоят из 8 разделов, каждый из который выполняет специфический анализ оценки проекта, они перечислены ниже.

1. Полнота охвата требований.

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

2. Детализация оценки.

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

3. Согласованность документов.

Выполняет проверку терминологии и структуры между ТЗ и оценкой. Если названия модулей или подходы различаются, это может привести к путанице и ошибкам на этапе реализации. Проверяется, чтобы не было "лишних" задач и чтобы структура оценки повторяла архитектуру проекта.

4. Риски и неопределенности.

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

5. Трудоемкость, сроки, стоимость.

Проверяет математику оценки. Все ли числа сходятся? Реалистичны ли сроки под указанные ресурсы? Одинаково ли применены ставки? Достаточно ли времени на тестирование и внедрение? Этот блок отвечает за «экономику проекта». 

6. Анализ рисков.

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

7. Типовые слабые зоны.

Анализ нацелен на области, которые часто упускаются в оценках. Это DevOps и CI/CD, управление проектом (PM), приемочные тесты, поддержка после запуска, а также скрытые допущения (например, готовая инфраструктура). 

8. Выводы и рекомендации.

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

Задача каждого такого блока - подсветить слабые места в нашей оценке. Блоков довольно много, поэтому рассмотрим подробнее первый из них - “Полнота охвата требований” и разберемся, как он работает.

Полнота охвата требований 

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

Задачи без соответствия в спецификации

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

Учет нефункциональных требований

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

Абстрактные задачи в дереве 

Отчет также ищет задачи, название которых не поясняет сути выполняемых работ. Формулировки вроде “задача 1” или “отчет” не несут полезной информации и должны быть уточнены. Хорошее название должно содержать глагол и конкретное описание, например: “Разработка отчета о прибылях и убытках, КНД 0710002”.

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

Заключение

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

Инструменты Project Calc позволяют вывести процесс оценки на новый уровень зрелости. Отчет по аномалиям помогает быстро выявлять очевидные недочеты и расхождения, которые сложно заметить вручную. А анализ оценки с помощью искусственного интеллекта дает возможность увидеть структуру проекта так, как ее видит команда экспертов: с учетом требований, полноты декомпозиции, непротиворечивости документов, рисков и типичных зон недооценки.

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

Проще говоря, качественная оценка - это уже половина успешного проекта. Project Calc позволяет сделать эту половину максимально надежной.