Что измеряется в человеко часах
Какие бывают дни: трудозатраты, длительность, сроки
Накопленный опыт взаимодействия с командами и смежными руководителями проектов все больше отражает печальную картину, что многие специалисты не понимают различие между рабочими, календарными и человеко-днями (часами). Попробую разобрать действительно простые понятия, в качестве достоверного источника для определений буду ссылаться на PMBoK.
Определения
Работа (Activity) – составная часть проекта, выполняемая в ходе его реализации. Каждая работа обычно характеризуется ожидаемыми длительностью, затратами на ее выполнение и потребностями в ресурсах. Работа может быть разбита на отдельные задачи.
Затраты на выполнение работы/задачи = Трудозатраты (Effort) – затраты, необходимые для выполнения работы или иного элемента проекта. Обычно выражается в человеко-часах, человеко-днях или человеко-неделях. Не следует путать трудоемкость работы с ее длительностью.
Длительность (Duration) – число календарных единиц, требующихся для завершения работы или иного элемента проекта без учета выходных и других нерабочих дней. Обычно выражается в рабочих днях или неделях. Иногда ошибочно приравнивается к затратам времени (трудозатратам).
Календарные сроки – сроки, устанавливаемые указанием на какой-либо период времени либо календарную дату. Необходимо четко разделять, что календарная неделя и трудозатраты человеко-неделя – разные понятия, их нельзя использовать как одинаковые временные рамки. Определение календарных сроков приведено из правового поля, PMBoK не дает определения календарным срокам и разнице между рабочими и календарными днями.
Просто о сложном на примере
Допустим, разработчику Васе необходимо написать приложение научного калькулятора для мобильного устройства (не будем вдаваться в подробности ОС, моделей и языков программирования). Помимо обычных функций сложения, умножения нужны еще функции степеней, извлечение корней и т.д. По оценке Васи ему необходимо 16 человеко-часов на написание такой функциональности.
Почему для оценки используется понятие человеко-часа? Человеко-час — единица учёта отработанного (или планируемого) времени, соответствует одному часу работы одного человека. К слову, обычно один человеко-день – это 8 человеко-часов, значит оценка Васи – 2 человеко-дня.
Вася понимает, что многие функции калькулятора не связаны между собой и их можно делать параллельно, если позвать кого-то на помощь, например, с такой же продуктивностью. Если мы разделим всю работу Васи поровну между ним и его помощником, то по длительности они смогут написать калькулятор за 1 рабочий день, а по трудозатратам потратят все те же 2 человеко-дня (16 человеко-часов).
Такой подход в PMBoK и других классических методологиях называется быстрым проходом (Fast Tracking) или распараллеливанием – для сокращения сроков работ / проекта можно на одни и те же трудозатраты привлекать дополнительное количество ресурсов. Трудозатраты остаются без изменений, длительность сокращается. В обратную сторону при сокращении количества доступных ресурсов, но том же объеме работ трудозатраты остаются неизменными, длительность вырастает.
Если вдруг у помощника возникнет другая срочная задача, и он сможет уделять только 50% своего времени на написание калькулятора, а перераспределять объем работ Вася и его помощник не захотят, то длительность работ снова станет 2 дня, трудозатраты останутся без изменений. Вася сделает свои 8 человеко-часов за 1 рабочий день, а помощник – свои 8 человеко-часов за 2 рабочих дня. Аналогично будет и при снижении доступной загрузки Васи до 50%, трудозатраты не изменятся, длительность будет 2 рабочих дня.
1 с загрузкой 100%,
1 с загрузкой 50%
Быстрый проход является одним из основных методов сжатия длительности работ проекта. Сжатие (Crashing) – проведение мероприятий, направленных на сокращение общей длительности проекта на основе анализа нескольких альтернатив и выбора той из них, которая дает максимально возможное сжатие длительности проекта при заданной его стоимости.
При использовании инструментов снижения длительности работ никогда нельзя забывать о наличии зависимостей между работами и ключевыми вехами. Существуют задачи, которые невозможно выполнить до завершения предыдущих или наступления определенных событий. Зависимость работ (в PMBoK логическая зависимость) – взаимосвязь между двумя или несколькими работами в составе проекта или между работой и вехой. Существует 4 типа логических зависимостей:
финиш-старт – начало последующей работы зависит от завершения предшествующей;
финиш-финиш – завершение последующей работы зависит от завершения предшествующей;
старт-старт – начало последующей работ зависит от начала предшествующей;
старт-финиш – завершение последующей работы зависит от начала предшествующей.
Зачем все это знать
Отвечая на вопрос заинтересованных людей, зачем при оценках работ разделять трудозатраты и длительность, когда достаточно сказать «это можно сделать за 15 дней», напомню, что помимо команд, которые делают продукт, есть еще сидящие рядом менеджеры, которым нужно считать деньги, называть сроки и рисовать презентации с графиками (и это тоже полезная работа).
В настоящее время есть большая вариативность инструментов оценки будущей функциональности и много способов «сообщить» результат такой оценки. И даже если ваша команда сделает какую-то классную фичу всего за 15 дней, из такой оценки даже самому крутому и продвинутому менеджеру далеко не всегда будет понятно сколько денег и сроков нужно нарисовать на графике. Для единого понимания и прозрачного выстроенного процесса важно всегда синхронизироваться в понятиях, используемых при оценке. На мой взгляд, придумывать велосипед и изобретать свои системы счисления не стоит, да и вообще нет ничего лучше, чем использование классического и подтвержденного мировым опытом подхода по разделению трудозатрат, длительности и сроков на раздельные составляющие.
В противном случае при использовании способов оценки «наша команда сделает за 15 дней» всплывает известная задача про землекопов. Чтобы не сотрясать воздух, привожу «живой» пример от менеджера команды из недавних переписок:
Проблемы этого письма:
Менеджер команды путает календарные и человеко-месяцы, для справки: в одном квартале действительно 3 месяца, но в среднем это 63 рабочих дня, а никак не 90.
90 человеко-дней – это уже 4,2 человеко-месяца, которые можно уместить в один квартал, если несколько ресурсов будут работать параллельно.
Полная неразбериха в трудозатратах и длительности и нулевая информативность оценки: сколько ресурсов и их процентная доступность, сложно рассчитывать бюджет.
И «на десерт» был план такой оценки:
План не привязан к календарю (невозможно понять сроки старта и окончания работ, не учтены возможные сдвиги из-за календарных праздников и внезапных нерабочих дней).
Отсутствует разбиение блоков работ на атомарные работы для осуществления возможного сжатия проекта по длительности.
Отсутствуют зависимости между задачами и вехами работ также для осуществления возможного сжатия проекта по длительности.
Отсутствует информация о количестве ресурсов и их доступности.
В таком исполнении оценки и последующего плана оценка команды имеет нулевую ценность и информативность, невозможно корректно рассчитать бюджет проекта, его календарные сроки и ограничения, так как разные 90 дней по-разному влияют на бюджет и сроки. И это не занудство менеджера, которому больше нечем заняться, а грамотное проектное управления и планирование работ.
Модные понятия
Ни в коем случае не хочу накидывать на вентилятор в сторону Agile-команд, я их люблю и работаю с ними, но все-таки упомяну новомодное понятие, с которым приходится сталкиваться – командо-дни.
Если вдаваться в подробности происхождения, то это выдуманное понятие, аналогичное человеко-дням, только вместо человека целая команда. Вместе с этим вам несколько «НО»:
PMBoK, PRINCE2 и прочие взрослые методологии не вводят таких понятий, хотя давно уже дружат с Agile. Не потому, что методологии отсталые (ни в коем случае!), а потому что командо-дни – не унифицированная единица измерения.
Великий Google ничего не выдает толкового по запросам «командо-дни проекта», «командо-дни agile» и так далее. А Google знает все, ну или почти все.
Такая абстрактная единица подходит только для сугубо внутреннего использования команд или для оценок команд универсалов, где все делают всё и взаимозаменяемые. Как только у вас происходит функциональное разделение команды по ролям, а если еще присутствует разделение финансовых ставок по ролям, то командо-дни – это очень сложно конвертируемое оценочное измерение.
Вместо заключения
Качество поставляемых продуктов и услуг всегда зависит от базового фундамента и выстроенных процессов, которые способны обеспечить должный уровень удовлетворения конечного потребителя или пользователя. Уровень качества оценки отображает уровень зрелости процессов управления и планирования разрабатываемых продуктов, и этот уровень невозможно создать без понимания и применения базовых понятий.
Надеюсь, если ваши оценки длительности раньше были в человеко-днях, после прочтения вы сможете делать их корректнее и радовать своих менеджеров и спонсоров проекта.
Как правильно рассчитать человеко-часы, расчет
Трудозатраты — один из важнейших технико-экономических показателей на предприятии. Без знания человеко-часов расчет его становится невозможным. Ч4. ст91 ТК обязывает предприятия вести учет времени. На практике применяются табели рабочего времени, где учитывается график работы каждого сотрудника, а также время, фактически отработанное за каждый день. В статье рассмотрим экономическую составляющую данного критерия оценки работы и методологию расчета.
Что это и для чего применяется
Человеко-час — единица оценки времени, необходимого для выполнения определенной работы. В абсолютном значении — это время пребывания сотрудника на рабочем месте. С его помощь можно:
Фотография рабочего дня
Зная время пребывания сотрудника на работе и составив фотографию его рабочего дня, руководитель может объективно оценить эффективность трудового времени работника в разрезе «человеко-часы» — процент выполнения задачи за день. Выявив потери времени в течение дня, можно выстроить план мероприятий по оптимизации рабочего процесса, конечным результатом которых является повышение производительности отдельного рабочего и предприятия в целом.
Штат сотрудников
Зная время, необходимое для выполнения конкретной работы, и получив данные по человеко-часам, руководитель определяет потребность в трудовых ресурсах, что является ключевым параметром для формирования фонда оплаты труда.
Сроки выполнения целей
Определив нормы времени для выполнения конкретной работы, человеко-часы помогают установить сроки их выполнения. Это, с одной стороны, делает процесс планирования на предприятии более прозрачным, с другой стороны — стимулирует на результат отдельного работника.
Исходные данные
Прежде чем ответить на вопрос, как рассчитать человеко-часы, необходимо исключить время:
Формулы расчета
№ 1. Ч = СС * Т, где:
СС — среднесписочная численность (на предприятии с небольшим количеством работников, это количество работников на определенную дату);
Т — время на работе за исключением времени отсутствия (см.выше).
Пример 1. Штат сотрудников на месяц 5 человек, им применим 8-часовой рабочий день, в месяц 22 рабочих дня, т. е. за месяц каждый отрабатывает 176 часов, соответственно: Ч (день)=5*8=40 часов Ч (месяц)=5*176=880 часов.
Формула применима, если работники пребывали одинаковое время, если же есть несколько работников с одинаковым графиком работы, то применима формула № 2.
№ 2.Ч=СС1*Т1+СС2*Т2+…ССn*Тn
Пример 2: В организации 5 человек с 8 часовым рабочим днем, 3 на сокращенном графике по 4 часа в день, итого: Ч (день)=5*8+3*4=52 часа Ч (месяц)=5*176+3*88=1144 часа.
Простейшие формулы применимы для внутренних целей самих руководителей. Однако эти данные необходимы для органов статистки (не распространяется на индивидуальных предпринимателей). С этой целью формируется отчет «П-4» («Сведения о численности и заработной плате работников» по форме согласно приказу Росстата от 02.08.2016 № 379). Периодичность зависит от численности работников:
В данном случае применима формула № 3.
№ 3.Ч=Ч1+Ч2+…+Чn, где:
Чn — время пребывания на работе n-го сотрудника.
Важно помнить, чтобы корректно рассчитать человеко-часы, необходимо включить сверхурочные работы, выходы в выходные и праздничные дни.
Пример 3. Как посчитать человеко-часы за сентябрь (21 рабочий день) для организации со штатом в 16 человек, из которых 5 отработали весь месяц по 8 часов, 2 помимо прочего вышли в один выходной, 3 отработав целый месяц полный рабочий день, имеют сверхурочку, согласно табелю, 3 дня по 2 часа, 6 человек отработали 21 день на сокращенном графике в 4 часа. Получаем следующие расчеты: Ч (сентябрь)=Ч1 (1*8*21)+Ч2 (1*8*21)+Ч3 (1*8*21)+Ч4 (1*8*21)+Ч5 (1*8*21)+Ч6 (1*8*21+8)+Ч7 (1*8*21+8)+ +Ч8 (1*8*21+3*2)+Ч9 (1*8*21+3*2)+Ч10 (1*8*21+3*2)+Ч11 (1*4*21)+Ч12 (1*4*21)+Ч13 (1*4*21)+Ч14 (1*4*21)+ +Ч15 (1*4*21)+Ч16 (1*4*21) = 2212 часов.
Для расчета применимы все три формулы. При условии полной выработки 40-часовой рабочей недели без сверхурочек и выходов в праздничные и выходные дни сотрудник должен отработать 1973 часа.
Мифический человеко-час
Что такое человеко-час, человеко-месяц и человеко-год? Как правильно ими пользоваться при планировании и выполнении программных проектов? Какие типичные ошибки допускают проектные менеджеры и руководители групп программистов?
Меня зовут Гелий Шаров, и я работаю тим-лидом в 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-проектов. А что говорит Ваш опыт? – жду Ваших комментариев к этой статье.
В заключение я бы хотел процитировать слова Фредерика Брукса:
Программные проекты чаще проваливаются из-за нехватки календарного времени, чем по всем остальным причинам вместе взятым.