Накопленный опыт взаимодействия с командами и смежными руководителями проектов все больше отражает печальную картину, что многие специалисты не понимают различие между рабочими, календарными и человеко-днями (часами). Попробую разобрать действительно простые понятия, в качестве достоверного источника для определений буду ссылаться на PMBoK.
Определения
Работа (Activity) – составная часть проекта, выполняемая в ходе его реализации. Каждая работа обычно характеризуется ожидаемыми длительностью, затратами на ее выполнение и потребностями в ресурсах. Работа может быть разбита на отдельные задачи.
Затраты на выполнение работы/задачи = Трудозатраты (Effort) – затраты, необходимые для выполнения работы или иного элемента проекта. Обычно выражается в человеко-часах, человеко-днях или человеко-неделях. Не следует путать трудоемкость работы с ее длительностью.
Длительность (Duration) – число календарных единиц, требующихся для завершения работы или иного элемента проекта без учета выходных и других нерабочих дней. Обычно выражается в рабочих днях или неделях. Иногда ошибочно приравнивается к затратам времени (трудозатратам).
Календарные сроки – сроки, устанавливаемые указанием на какой-либо период времени либо календарную дату. Необходимо четко разделять, что календарная неделя и трудозатраты человеко-неделя – разные понятия, их нельзя использовать как одинаковые временные рамки. Определение календарных сроков приведено из правового поля, PMBoK не дает определения календарным срокам и разнице между рабочими и календарными днями.
Просто о сложном на примере
Допустим, разработчику Васе необходимо написать приложение научного калькулятора для мобильного устройства (не будем вдаваться в подробности ОС, моделей и языков программирования). Помимо обычных функций сложения, умножения нужны еще функции степеней, извлечение корней и т.д. По оценке Васи ему необходимо 16 человеко-часов на написание такой функциональности.
Почему для оценки используется понятие человеко-часа? Человеко-час — единица учёта отработанного (или планируемого) времени, соответствует одному часу работы одного человека. К слову, обычно один человеко-день – это 8 человеко-часов, значит оценка Васи – 2 человеко-дня.
Количество ресурсов | Трудозатраты | Длительность |
1 | 16 человеко-часов | 2 дня |
Вася понимает, что многие функции калькулятора не связаны между собой и их можно делать параллельно, если позвать кого-то на помощь, например, с такой же продуктивностью. Если мы разделим всю работу Васи поровну между ним и его помощником, то по длительности они смогут написать калькулятор за 1 рабочий день, а по трудозатратам потратят все те же 2 человеко-дня (16 человеко-часов).
Количество ресурсов | Трудозатраты | Длительность |
2 | 16 человеко-часов | 1 день |
Такой подход в PMBoK и других классических методологиях называется быстрым проходом (Fast Tracking) или распараллеливанием – для сокращения сроков работ / проекта можно на одни и те же трудозатраты привлекать дополнительное количество ресурсов. Трудозатраты остаются без изменений, длительность сокращается. В обратную сторону при сокращении количества доступных ресурсов, но том же объеме работ трудозатраты остаются неизменными, длительность вырастает.
Если вдруг у помощника возникнет другая срочная задача, и он сможет уделять только 50% своего времени на написание калькулятора, а перераспределять объем работ Вася и его помощник не захотят, то длительность работ снова станет 2 дня, трудозатраты останутся без изменений. Вася сделает свои 8 человеко-часов за 1 рабочий день, а помощник – свои 8 человеко-часов за 2 рабочих дня. Аналогично будет и при снижении доступной загрузки Васи до 50%, трудозатраты не изменятся, длительность будет 2 рабочих дня.
Количество ресурсов | Трудозатраты | Длительность |
1 с загрузкой 100%, | 16 человеко-часов | 2 дня |
2 с загрузкой 50% | 16 человеко-часов | 2 дня |
2 с загрузкой 25% | 16 человеко-часов | 4 дня |
Быстрый проход является одним из основных методов сжатия длительности работ проекта. Сжатие (Crashing) – проведение мероприятий, направленных на сокращение общей длительности проекта на основе анализа нескольких альтернатив и выбора той из них, которая дает максимально возможное сжатие длительности проекта при заданной его стоимости.
При использовании инструментов снижения длительности работ никогда нельзя забывать о наличии зависимостей между работами и ключевыми вехами. Существуют задачи, которые невозможно выполнить до завершения предыдущих или наступления определенных событий. Зависимость работ (в PMBoK логическая зависимость) – взаимосвязь между двумя или несколькими работами в составе проекта или между работой и вехой. Существует 4 типа логических зависимостей:
финиш-старт – начало последующей работы зависит от завершения предшествующей;
финиш-финиш – завершение последующей работы зависит от завершения предшествующей;
старт-старт – начало последующей работ зависит от начала предшествующей;
старт-финиш – завершение последующей работы зависит от начала предшествующей.
Зачем все это знать
Отвечая на вопрос заинтересованных людей, зачем при оценках работ разделять трудозатраты и длительность, когда достаточно сказать «это можно сделать за 15 дней», напомню, что помимо команд, которые делают продукт, есть еще сидящие рядом менеджеры, которым нужно считать деньги, называть сроки и рисовать презентации с графиками (и это тоже полезная работа).
В настоящее время есть большая вариативность инструментов оценки будущей функциональности и много способов «сообщить» результат такой оценки. И даже если ваша команда сделает какую-то классную фичу всего за 15 дней, из такой оценки даже самому крутому и продвинутому менеджеру далеко не всегда будет понятно сколько денег и сроков нужно нарисовать на графике. Для единого понимания и прозрачного выстроенного процесса важно всегда синхронизироваться в понятиях, используемых при оценке. На мой взгляд, придумывать велосипед и изобретать свои системы счисления не стоит, да и вообще нет ничего лучше, чем использование классического и подтвержденного мировым опытом подхода по разделению трудозатрат, длительности и сроков на раздельные составляющие.
В противном случае при использовании способов оценки «наша команда сделает за 15 дней» всплывает известная задача про землекопов. Чтобы не сотрясать воздух, привожу «живой» пример от менеджера команды из недавних переписок:
Проблемы этого письма:
Менеджер команды путает календарные и человеко-месяцы, для справки: в одном квартале действительно 3 месяца, но в среднем это 63 рабочих дня, а никак не 90.
90 человеко-дней – это уже 4,2 человеко-месяца, которые можно уместить в один квартал, если несколько ресурсов будут работать параллельно.
Полная неразбериха в трудозатратах и длительности и нулевая информативность оценки: сколько ресурсов и их процентная доступность, сложно рассчитывать бюджет.
И «на десерт» был план такой оценки:
Проблемы плана:
План не привязан к календарю (невозможно понять сроки старта и окончания работ, не учтены возможные сдвиги из-за календарных праздников и внезапных нерабочих дней).
Отсутствует разбиение блоков работ на атомарные работы для осуществления возможного сжатия проекта по длительности.
Отсутствуют зависимости между задачами и вехами работ также для осуществления возможного сжатия проекта по длительности.
Отсутствует информация о количестве ресурсов и их доступности.
И самое главное – длительность честно указана в человеко-днях (wtf !?).
В таком исполнении оценки и последующего плана оценка команды имеет нулевую ценность и информативность, невозможно корректно рассчитать бюджет проекта, его календарные сроки и ограничения, так как разные 90 дней по-разному влияют на бюджет и сроки. И это не занудство менеджера, которому больше нечем заняться, а грамотное проектное управления и планирование работ.
Модные понятия
Ни в коем случае не хочу накидывать на вентилятор в сторону Agile-команд, я их люблю и работаю с ними, но все-таки упомяну новомодное понятие, с которым приходится сталкиваться – командо-дни.
Если вдаваться в подробности происхождения, то это выдуманное понятие, аналогичное человеко-дням, только вместо человека целая команда. Вместе с этим вам несколько «НО»:
PMBoK, PRINCE2 и прочие взрослые методологии не вводят таких понятий, хотя давно уже дружат с Agile. Не потому, что методологии отсталые (ни в коем случае!), а потому что командо-дни – не унифицированная единица измерения.
Великий Google ничего не выдает толкового по запросам «командо-дни проекта», «командо-дни agile» и так далее. А Google знает все, ну или почти все.
Такая абстрактная единица подходит только для сугубо внутреннего использования команд или для оценок команд универсалов, где все делают всё и взаимозаменяемые. Как только у вас происходит функциональное разделение команды по ролям, а если еще присутствует разделение финансовых ставок по ролям, то командо-дни – это очень сложно конвертируемое оценочное измерение.
Вместо заключения
Качество поставляемых продуктов и услуг всегда зависит от базового фундамента и выстроенных процессов, которые способны обеспечить должный уровень удовлетворения конечного потребителя или пользователя. Уровень качества оценки отображает уровень зрелости процессов управления и планирования разрабатываемых продуктов, и этот уровень невозможно создать без понимания и применения базовых понятий.
Надеюсь, если ваши оценки длительности раньше были в человеко-днях, после прочтения вы сможете делать их корректнее и радовать своих менеджеров и спонсоров проекта.
