Мифический человеко-час
Что такое человеко-час, человеко-месяц и человеко-год? Как правильно ими пользоваться при планировании и выполнении программных проектов? Какие типичные ошибки допускают проектные менеджеры и руководители групп программистов?
Меня зовут Гелий Шаров, и я работаю тим-лидом в Orion Innovation. Проработав 24 года в IT-компании на разных должностях, включая менеджерские, я понял, что существует путаница в понятии человеко-час и в том, как им можно манипулировать в IT-проектах. Эта статья поможет развеять мифы и подскажет как правильно планировать работы в проектах. От правильной оценки проекта зависит очень многое. И то, согласится ли с ней ваш клиент и даст ли проекту старт. И то, насколько сложно вам будет делать коррекцию этой оценки в процессе, что неизбежно, и сможете ли вы эту коррекцию обосновать, и то, как вы будете выстраивать бизнес-процессы в управлении проектом. Поэтому в оценке IT-проекта задействована масса факторов, шкал и расчетов. Тем не менее, основная масса клиентов ориентируется на очень понятную и четкую единицу измерения — человеко-час.
И разумеется, это палка о двух концах. С одной стороны — это предельна простая базовая единица. С другой стороны, нередко задача по адекватной оценке сложного проекта в столь простых единицах похожа на попытку измерить расстояния в нелинейной системе в попугаях.
Человеко-час — это единица измерения, которой пользуются в проектах для двух разных целей:
Оценки объёма/сложности разработки программного продукта/компонента — то есть оценки необходимых усилий на его создание и тестирование.
Подсчёта стоимости работ по проекту.
Например, если пять человек выполняют работу в течение рабочей недели, то это составляет 5×40 = 200 человеко-часов. Человеко-часы — это удобный инструмент, который широко используется в аутсорсинговых организациях по разработке ПО.
Если сравнить человеко-месяц и человеко-час, то в разных проектах ситуация может отличаться. Чаще всего человеко-месяц это 20 рабочих дней * 8 часов = 160 человеко-часов, но в некоторых проектах может быть 21 рабочий день. Если работы по проекту начались 1 февраля и закончились в конце месяца, то это не то же самое, что с 1 марта до конца марта, так как количество рабочих дней разное. Поэтому термин человеко-месяц нужно употреблять аккуратно при оценке и планировании работ, лучше использовать человеко-часы. Более того в разных странах отличается длительность рабочей недели. Например, во Франции она составляет 35 часов, то есть во Франции термин человеко-месяц может содержать меньшее количество человеко-часов, чем в России.
Ещё больше сложностей в определении термина человеко-год. Для подсчёта суммарного количества человеко-часов в одном человеко-годе необходимо взять количество календарных дней — 365 для невисокосного года и 366 для високосного, вычесть из него количество выходных дней в этом году и количество праздничных нерабочих дней. Также стоит вычесть длительность отпуска, что составляет в России 28 календарных дней или 20 рабочих.
Очевидно, что в разные календарные года объём человеко-года будет разный. Это зависит от страны, в которой выполняются работы по проекту, от количества выходных дней, попавших в календарный год и других условий.
Дополнительным преимуществом человеко-часа перед человеко-месяцем и человеко-годом является его точность. Так если программист работает параллельно в двух проектах, его отработанные часы легко поделить между проектами пропорционально отработанному времени.
Планирование и учёт человеко-часов
Теперь давайте рассмотрим человеко-час как инструмент оценки объёма работ по будущему проекту. В первую очередь работы разбиваются до уровня задач, каждую из которых может выполнить один инженер в ограниченное количество времени. Выполнение этих задач оценивается в человеко-часах, они суммируются, добавляются административные задачи, оцениваются риски и усилия по их минимизации, после чего всё суммируется для оценки будущей стоимости всего проекта. Также составляется календарный график работ по проекту, в котором наибольшее внимание следует уделить задачам на критическом пути.
Но оценки объёма работ могут оказаться неточными и Вам могут потребоваться дополнительные усилия для завершения задач по проекту. Предположим, до финальной отсылки кода осталось два месяца. У Вас в проекте работают два инженера, а оставшаяся работа оценена в 14 человеко-месяцев. Тогда напрашивается решение о добавлении в проект ещё пяти инженеров на два месяца, чтобы успеть в срок. Сработает ли такое решение на практике? Да или нет — это зависит от многих условий. Во-первых, оставшиеся в проекте задачи должны быть разбиваемыми на подзадачи, чтобы их можно было выполнять параллельно. Во-вторых, новые инженеры должны иметь достаточно времени, чтобы вникнуть в проект и свои задачи. В-третьих, необходимо заложить время на коммуникации между семью инженерами, а также на интеграцию их кода в единый продукт. Если хотя бы одно из этих условий не выполнено, то проект не будет завершён в срок. Добавление же ещё большего числа инженеров может даже привести к увеличению сроков, а не к уменьшению.
Фредерик Брукс в своей книге «Мифический человеко-месяц» писал:
Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше. Это развенчивает миф о человеко-месяце. Продолжительность осуществления проекта зависит от ограничений, накладываемых последовательностью работ. Максимальное количество разработчиков зависит от числа независимых подзадач. Эти две величины позволяют получить график работ, в котором будет меньше занятых разработчиков и больше месяцев.
Производительность программистов
Термин человеко-час удобен для планирования работ, но важно понимать, что разные инженеры работают с разной производительностью.
В одном из исследований Сакман (Sackman), Эриксон (Erikson) и Грант (Grant) измеряли производительность труда в группе опытных программистов. Внутри одной лишь этой группы соотношение между лучшими и худшими результатами составило примерно 10:1. Это означает, что какие-то задачи в проекте будут выполнены быстрее чем ранее сделанные оценки по объёму работ, а другие наоборот будут задержаны. Поэтому самых опытных программистов нужно планировать на выполнение задач на критическом пути проекта, от выполнения которого зависят сроки отсылки кода и продукта заказчику. Самый ценный ресурс в любом проекте — это календарное время. Если оно упущено, обратно его уже не вернуть, в то время как другие ресурсы проекта восполнимы в течение жизненного цикла проекта.
Тестирование продукта
Для разработки конечного программного продукта требуется оценить и запланировать человеко-часы на тестирование, что является одной из важнейших задач в практически любом проекте. В каждой компании по разработке ПО желательно иметь независимую команду инженеров по тестированию, которая верифицирует выполнение всех проектных требований в программном продукте. Планирование тестов должно учитывать возможные дефекты в продукте, которые необходимо устранить в коде продукта и перевыполнить соответствующие тесты — на что начинающие менеджеры иногда забывают запланировать соответствующие человеко-часы. Существует такой подход к тестированию, когда объём часов на эти задачи выделяется как некий фиксированный процент от объёма часов на разработку продукта. Такой подход излишне упрощает проблему планирования, ведь разные программные продукты отличаются по сложности выполнения функциональных и регрессионных тестов.
К счастью, процесс тестирования в IT проектах довольно стандартизирован и подсчитать трудозатраты QA немного проще. Обычно при таких расчётах учитываются требования заказчика к видам тестирования, которые довольно несложно собрать уже перед началом проекта. Есть мнение, что в среднем трудозатраты в человеко-часах на тестирование в среднем составляют 0.7 от трудозатрат на разработку. Можно сказать, что если расчеты очень сильно отклоняются от этого показателя, то это как минимум повод провести их еще раз.
Выполнение крупных проектов
Существует мнение что объём потраченных человеко-часов в ИТ-проектах линейно зависит от объёма написанного кода. График ниже демонстрирует результаты, полученные в исследовании, проведенном Нанусом (Nanus) и Фарром (Farr) в System Development Corporation. В нем выявляется зависимость с показателем степени 1,5. На графике по горизонтали указан объём написанного кода, по вертикали — объём потраченных человеко-месяцев, в виде жирных точек приведена статистика из реальных проектов. Пунктиром изображена линейная зависимость. Сплошной кривой изображена степенная зависимость.
Объем работы = (константа) × (количество команд)1,5
То есть в проектах по разработке сложных объёмных продуктов средняя производительность инженеров в машинных командах в единицу времени ниже, чем в небольших проектах, что необходимо учитывать при планировании таких проектов.
Fixed cost vs T&M
Планирование работ в человеко-часах зависит от используемой бизнес-модели. Существуют две основные бизнес-модели оплаты услуг аутсорсинговых организаций Fixed Cost и Time&Material. Давайте их рассмотрим поподробнее:
В модели Fixed Cost оценивается стоимость всех работ по проекту, которую указывают в контракте вместе со списком основных требований к программному продукту. Заказчик оплачивает работу после получения предварительных версий продукта и финальной версии. В случае изменений требований к продукту пересматривается контракт для согласования новой стоимости. В этой модели для заказчика не важно, сколько инженеров и на какой срок привлечено в реализацию проекта. Для компании-исполнителя важно построить такую команду, чтобы выполнить обязательства в полном объёме и не превысить планируемые расходы на проект. В этом случае от грамотного расчёта исполнителя будет зависеть то, реализует ли он проект в срок и заранее рассчитанным количеством человек, или, если расчет окажется неверным, будет ли работать себе в убыток, превысив бюджет и/или выйдя за дедлайн.
В модели Time&Material также оценивается объём работ по проекту в человеко-часах, но в контракте указывается стоимость одного человеко-часа и базовые принципы по их планированию, отчётности и оплате. После привлечения сотрудников в проект в конце каждого месяца отсылается отчёт по проделанной работе и затраченным человеко-часам. Оплата происходит ежемесячно при условии, что исполнитель не превышает заранее установленных планов и критериев по суммарным человеко-часам. В этой модели заказчик видит часы каждого сотрудника, вовлечённого в проект. В случае изменения проектных требований они оцениваются и бюджет может быть увеличен для вовлечения дополнительных сотрудников.
В проектах, где есть устойчивые требования к разрабатываемому программному продукту, модель Fixed Cost обладает преимуществами как для заказчика, так и для исполнителя. В других проектах, включая Agile, T&M модель более предпочтительна так как эта модель не требует пересматривать контракт при изменении требований.
Заключение
Инструмент планирования «человеко-час» удобен для сложения, деления, переноса и других математических операций, в то время как в реальных проектах перепланирование работ требует более глубокого анализа планируемых работ по проекту и учёта многих факторов. Я имел опыт работы с проектами размером более 30000 человеко-часов и могу сказать, что собственный опыт является ключевым фактором в правильном планировании и выполнении IT-проектов. А что говорит Ваш опыт? — жду Ваших комментариев к этой статье.
В заключение я бы хотел процитировать слова Фредерика Брукса:
Программные проекты чаще проваливаются из-за нехватки календарного времени, чем по всем остальным причинам вместе взятым.
