Очень часто при оценке проекта возникает ситуация, когда трудоемкость одних задач зависит от трудоемкости других. Например, трудоемкость управления проектом принимается равной 10% от трудоемкости разработки и внедрения. Логика проста: растет объем разработки - растет и нагрузка на управление. Было бы логичным, если бы система, используемая для оценки трудоемкости проекта, могла поддерживать такие зависимости.

В системе Project Calc такая возможность реализована. Она позволяет задать для задачи не конкретные значения трудоемкости, а два параметра:

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

Таким образом, если базовая задача имеет трудоемкость от 4 до 5 дней, а зависимая от нее задача - коэффициент 0.1, то система рассчитает ее трудоемкость как от 0.4 до 0.5 дней. Зависимости могут применяться не только к отдельным задачам, но и к целым веткам, и даже быть каскадными.

Например, нормативы, установленные в компании, определяют, что трудоемкость задач по тестированию составляет 20% от трудоемкости задач по разработке программного обеспечения, а управление проектом - 10% от разработки и 8% от тестирования.

Для реализации такого подхода в системе достаточно:

1. создать задачу "Тестирование" с базовой задачей Разработка и коэффициентом 0.2;
2. в ветке Управление проектом добавить задачу "Управление разработкой" (коэффициент 0.1);
3. в ветке Управление проектом добавить задачу "Управление тестированием" (коэффициент 0.08).

В результате итоговая трудоемкость управления проектом будет вычисляться автоматически через каскад зависимостей.

Все расчеты в системе происходят автоматически - запускать пересчет вручную не требуется.

Оценка трудоемкости и планирование - в чем различие?

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

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

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

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

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

Шаблоны для повторяющихся проектов

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

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

Это позволяет выстраивать довольно интересные модели для оценки проекта. Например, мы делаем оценку проекта для заказчика и ищем способы снизить стоимость. Одним из вариантов является уменьшение доли задача по управлению проектом с 10 до 8 процентов от трудоемкости разработки. В этом случае мы может сделать две ветки задач по управлению проектом- в одну включать задачи с коэффициентом 0.1, в другую- с коэффициентом 0.08. И за счет переключения внутри модификатора, который вешается на эти ветки можно будет увидеть, как меняется трудоемкость и стоимость проекта.

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

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

Модификаторы

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

Это позволяет выстраивать довольно интересные модели для оценки проекта. Например, мы делаем оценку проекта для заказчика и ищем способы снизить стоимость. Одним из вариантов является уменьшение доли задача по управлению проектом с 10 до 8 процентов от трудоемкости разработки. В этом случае мы может сделать две ветки задач по управлению проектом- в одну включать задачи с коэффициентом 0.1, в другую- с коэффициентом 0.08. И за счет переключения внутри модификатора, который вешается на эти ветки можно будет увидеть, как меняется трудоемкость и стоимость проекта.

Второй вариант- это когда какая-то задача может быть реализована либо своими силами, либо силами подрядчика. И нам нужно оценить оба варианта. При этом для управления проектом подрядчика нужен руководитель проекта более высокого уровня, чем для внутренних задач, но его участие ограничивается 5 процентами. Соответственно, в ветке Управление проектом можно сделать две задачи - одна для оценки внутренней реализации, вторая для подрядчика, повесить на них соответствующий модификатор. Тогда при оценке такого проекта будут приниматься во внимание все детали: свой проект будет вести более дешевый руководитель проектов, но большее время. А для внешней разработки потребуется опытный руководитель, но на меньшее время. Если еще учесть в этой оценке риски, то мы получим весьма прозрачную для принятия решения картину.

Выводы 

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

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