Как анализ распределения трудозатрат по видам работ на проекте может помочь в оценке бюджета нового проекта

Перед оценкой бюджета и сроков нового проекта необходимо задать один очень важный вопрос: «Выполнялись ли похожие проекты?». Если были похожие завершенные проекты, то значит база для оценки нового проекта есть. Но это не значит, что достаточно просто получить общие трудозатраты и срок выполнения завершенного проекта и перенести их в оценки для нового проекта. Необходимо провести ретроспективный анализ, проанализировать сработавшие риски, учесть различные наработки в старом проекте (архитектура, шаблоны документов, утилиты, скрипты и т.п.).  «Похожесть» проектов в первую очередь опирается на «похожесть» архитектуры разрабатываемого продукта, «похожесть» команды, «похожесть» инфраструктуры разработки и «похожесть» кастомера. Смена того или иного компонента может по разному повлиять на сроки и бюджет. Но в любом случае — это хороший сценарий для менеджера проекта. База для оценки есть.

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

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

При использовании системы Jira или любого другого корпоративного task\bug трекера получение фактических трудозатрат легко закрывается практикой регулярного фиксирования сотрудниками своих ворклогов в привязке к выполняемой задаче. Фиксация ворклогов должна выполняться в конце рабочего дня или не позже чем с «сегодня на вчера». Ворклоги, которые отмечаются сотрудником в конце рабочей недели или того хуже в конце итерации или месяца, теряют свою объективность. В конце недели не так-то просто вспомнить, сколько часов было затрачено на определенную задачу и в какой день.

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

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

Распределение трудозатрат по основным процессам разработки ПО можно получить двумя способами:

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

Остановимся более детальнее на втором способе. Чтобы получить распределение трудозатрат на проекте опираясь на данные из Jira, можно воспользоваться SQL-запросом.

select wlt.pname, 
       sum(wl.timeworked/3600) timeworked
from   worklog wl,
       jiraissue ji,
       project p,
       jiraworklog jwl,
       worklogtype wlt
where  p.pkey = 'DEMO'
       and ji.PROJECT = p.ID
       and wl.issueid = ji.ID
       and jwl.ID = wl.ID
       and jwl.WORKLOGTYPE =wlt.ID

Пример написан для проекта DEMO.

На одном из проектов результат получился следующим:

Вид работы                 Трудозатраты (чел-час)

Документирование           5009.716539

Консультации и саппорт     2502.133240

Проектирование ПС          2622.716637

Управление требованиями    8506.266546

Реализация ПС              55456.399201

Тестирование               38058.948062

Техническая ревизия        286.066663

Управление конфигурацией   338.999998

Управление проектом        3634.299979

Устранение дефектов        6475.566401

Представим в виде графика

art7_stat

На Реализацию ПО в данном случае пришлась почти половина общих трудозатрат. С высокой долей вероятности можно утверждать, что в большинстве проектах компании, распределение работ будет похожим. Именно вид работы Реализации ПО является базовым в проектах по разработке ПО. Оценив эту работу, остальные приблизительно можно рассчитать из полученного соотношения. И тут никуда не деться, все равно менеджеру, архитектору и тимлиду необходимо сконцентрировать свой опыт и знания, чтобы приблизительно оценить объем работ по разработке. Далее, воспользовавшись соотношением из примера, можно предполагать, что Тестирование займет порядка 70% от Разработки, а, например, Управление требованиями — порядка 20-30%. Такой подход к оцениванию будет намного убедительнее чем «слепое» угадывание и необоснованные прогнозы.

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