Как анализ распределения трудозатрат по видам работ на проекте может помочь в оценке бюджета нового проекта
Перед оценкой бюджета и сроков нового проекта необходимо задать один очень важный вопрос: «Выполнялись ли похожие проекты?». Если были похожие завершенные проекты, то значит база для оценки нового проекта есть. Но это не значит, что достаточно просто получить общие трудозатраты и срок выполнения завершенного проекта и перенести их в оценки для нового проекта. Необходимо провести ретроспективный анализ, проанализировать сработавшие риски, учесть различные наработки в старом проекте (архитектура, шаблоны документов, утилиты, скрипты и т.п.). «Похожесть» проектов в первую очередь опирается на «похожесть» архитектуры разрабатываемого продукта, «похожесть» команды, «похожесть» инфраструктуры разработки и «похожесть» кастомера. Смена того или иного компонента может по разному повлиять на сроки и бюджет. Но в любом случае — это хороший сценарий для менеджера проекта. База для оценки есть.
Предлагаю рассмотреть худшую ситуацию, когда новый проект не с чем сравнить, но при этом необходимо получить грубые оценки бюджета. На этапе инициации проекта вполне приемлемыми можно считать оценки с точностью от -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
Представим в виде графика
На Реализацию ПО в данном случае пришлась почти половина общих трудозатрат. С высокой долей вероятности можно утверждать, что в большинстве проектах компании, распределение работ будет похожим. Именно вид работы Реализации ПО является базовым в проектах по разработке ПО. Оценив эту работу, остальные приблизительно можно рассчитать из полученного соотношения. И тут никуда не деться, все равно менеджеру, архитектору и тимлиду необходимо сконцентрировать свой опыт и знания, чтобы приблизительно оценить объем работ по разработке. Далее, воспользовавшись соотношением из примера, можно предполагать, что Тестирование займет порядка 70% от Разработки, а, например, Управление требованиями — порядка 20-30%. Такой подход к оцениванию будет намного убедительнее чем «слепое» угадывание и необоснованные прогнозы.
В следующей статье предлагаю рассмотреть один из подходов к оцениванию сроков новых проектов на стадии инициации.