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

Меня зовут Гелий Шаров, и я работаю тим-лидом в Orion Innovation. Проработав 24 года в IT-компании на разных должностях, включая менеджерские, я понял, что существует путаница в понятии человеко-час и в том, как им можно манипулировать в IT-проектах. Эта статья поможет развеять мифы и подскажет как правильно планировать работы в проектах. От правильной оценки проекта зависит очень многое. И то, согласится ли с ней ваш клиент и даст ли проекту старт. И то, насколько сложно вам будет делать коррекцию этой оценки в процессе, что неизбежно, и сможете ли вы эту коррекцию обосновать, и то, как вы будете выстраивать бизнес-процессы в управлении проектом. Поэтому в оценке IT-проекта задействована масса факторов, шкал и расчетов. Тем не менее, основная масса клиентов ориентируется на очень понятную и четкую единицу измерения – человеко-час.

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

Человеко-час — это единица измерения, которой пользуются в проектах для двух разных целей:

  1. Оценки объёма/сложности разработки программного продукта/компонента – то есть оценки необходимых усилий на его создание и тестирование.

  2. Подсчёта стоимости работ по проекту.

Например, если пять человек выполняют работу в течение рабочей недели, то это составляет 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-проектов. А что говорит Ваш опыт? – жду Ваших комментариев к этой статье.

В заключение я бы хотел процитировать слова Фредерика Брукса:

Программные проекты чаще проваливаются из-за нехватки календарного времени, чем по всем остальным причинам вместе взятым.

Комментарии (13)


  1. academic777
    29.08.2021 22:26

    Если говорить про it, то несмотря на все человеко-часы, все равно при согласовании стоимости у обоих сторон уже есть в голове какое-то видение стоимости. А норомо или человеко-часы просто помогают придать некоторую видимость ее обоснованности.


    1. GeliySharov Автор
      30.08.2021 10:50

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


    1. aimfirst
      01.09.2021 09:46

      Как правило, в кошельке заказчика ограниченный бюджет, а в голове - желание решить все проблемы за эти деньги. Однако, IMHO, если исполнитель покажет заказчику, что его желания могут быть реализованы путем выполнения определенного перечня работ, каждая из которых оценивается в нормо-часах специалиста, у заказчика появляется возможность выбора - какие работы он может выполнить за свои деньги, а какие оставить на потом. Это основание для начала нормального диалога.
      Когда Вы приходите к автомобильному дилеру с желанием отремонтировать свой автомобиль и он формирует перечень работ, общую цену и планируемые сроки, если у Вас не хватает денег или времени, Вы же не оспариваете стоимость отдельных работ - вы выбираете из списка наиболее приоритетные или уходите в другой сервис.
      Другое дело, если исполнитель любыми путями хочет получить контракт. Это распространенная ситуация - когда контракты заключают одни, а отвечают за их реализацию другие. Вот тогда мы сталкиваемся с ситуацией "впихнуть невпихуемое". И именно тогда нормо-часы превращаются в профанацию.
      Конечно, ключевой момент здесь в корректности оценки отдельных работ. Для снижения неопределенности при оценке трудоемкости я стараюсь конечную стоимость согласовывать с заказчиком после формирования проектных решений (подробно описал как их формируют на моих проектах здесь) и при создании WBS, по необходимости, использую калькуляторы оценки трудоемкости задач, которые в свою очередь являются площадкой для диалога между РП/аналитиком планирующим задачи и непосредственным исполнителем.


      1. academic777
        01.09.2021 10:09

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

        В рамках темы статьи я просто хотел сказать что все эти расчеты не более как способ чем-то обосновать стоимость работы. Хотя по факту все услуговые цены - договорные из разряда «согласен» - «не согласен».

        Просто психологически труднее расставаться с деньгами без какого то формального подтверждения обоснованности стоимости. Вот и все.


  1. LuchS-lynx
    30.08.2021 00:17
    +2

    Мой опыт строителя говорит что это все от Лукавого =)

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

    Еще трудоемкость учитывают при расчете ФОТ и зарплаты, но в контексте табеля, с натягиванием на него налогов и, в некоторых случаях, сделки.

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


    1. sshikov
      30.08.2021 10:41

      >Мой опыт строителя говорит что это все от Лукавого =)
      Мой тоже. И в целом статья ничего путного не содержит. Обычные банальности, причем не новые. Можно подумать, кто кто-то из использующих человеко-день в работе не знает, что неделя или месяц не получается из дня путем простого умножения на константу? Это смешно. Что месяцы в году разные по числу рабочих дней — знает любой, кто брал отпуск.


    1. GeliySharov Автор
      30.08.2021 10:51

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


  1. Gunslinger38
    30.08.2021 10:52

    Что это и зачем оно здесь? Абсолютное отсутствие полезной информации.
    Лучше прочитать оригинал, на который ссылается автор.


    1. GeliySharov Автор
      30.08.2021 10:54

      Да, рекомендую прочитать Фредерик Брукса «Мифический человеко-месяц» начинающим менеджерам проектов. Будет очень полезно. Эта статья лишь делает краткий обзор по проблеме человеко-часа.


  1. melvladimir
    30.08.2021 11:43
    +1

    Один из критериев оценки мной "качества" ИТ компании - это сколько человека часов у разработчика в сутках. Часто видел 8, как и время рабочего дня, что в корне не верно и для меня сигнал, что в компании не понимают базы и не любят точность. Я всегда считал для своей команды 6ч/день и 30 - неделя. Ёмкость спринта - кол-во человек * 2 недели минус отпуск (если есть). Ну и далее насыпайте в спринт задач примерно 2/3 ключевых и 1/3 мелких. И будет всем счастье)


    1. GeliySharov Автор
      30.08.2021 11:51

      В Agile/Scrum проектах правильнее использовать для оценок не человеко-час, а Story Points


      1. melvladimir
        30.08.2021 11:57

        Многие так и используют, но SP так или иначе коррелируют с часами. Так зачем измерять что-то ещё чем-то?


  1. dimti
    03.09.2021 15:01

    Меня на фрилансе всегда просят оценить в часах. Каждый час - плюс минус косарь для заказчика. 37 часов - соответственно 37 косарей.

    Никогда не оперировали такими терминами как человеко-месяц и прочее.

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

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

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