Портал TMGuru:

Оригинал статьи

В связи с выходом статьи «Идеальный час» поступила масса вопросов относительно того, как построен учет рабочего времени у нас в Компании. Больше всего коллег интересуют принципы учета, глубина его детализации и способы сбора информации. Не вижу препятствий к тому, чтобы поделиться хорошими практиками и дать ответы на эти важные вопросы.

Прежде чем перейти к этим важным темам, предлагаю спуститься еще на один уровень вниз и попытаться ответить на более фундаментальный вопрос — зачем мы это делаем? Ясное дело, что учет вызван какими-то объективными надобностями — иначе кто добровольно будет осложнять себе жизнь?

Собственно, объективных надобностей три:

• Требование Заказчика на предоставление детальной статистики. Практически неизбежно для проектов с почасовой оплатой, что естественно — так как Заказчик оплачивает ваше время, он хочет быть уверен в том, что вы работаете, а не курите бамбук.
• Сбор статистики для внутренних нужд. К каковым можно отнести: сбор исторической информации для оценок будущих проектов, определение эффективности исполнения проекта для исчисления бонуса, рассчет ключевых показателей (key performance indicators, KPI) проектной деятельности.
• Сбор статистики для исчисления заработной платы. Для нас очень актуально, так как почти вся наша разработка ведется контрактниками.

Разобравшись с тем, зачем мы собираем информацию, давайте определим особенности, присущие каждому назначению. Это позволит нам выработать методику учета, оптимально решающую поставленные задачи.

Случай первый — мы имеем требование Заказчика на предоставление детальной статистики. Здесь все просто. Требования к периодичности (день, неделя, месяц, этап) устанавливает Заказчик. Требования к детализации (четверть часа, час, день) устанавливает опять же Заказчик. Информация интересна в первую очередь Заказчику, а собирается сотрудниками Исполнителя. Соответственно, наибольших проблем можно ожидать в случае когда информация, собранная сотрудниками Исполнителя, Заказчику не нравится. Например, Заказчику кажется, что времени на определенную задачу потрачено больше, чем нужно. Соответственно, задача менеджера по сбору и обработке информации видится мне так:

a. Сделать информацию полной — чтобы Заказчик точно знал, сколько времени потрачено, и когда это время было потрачено.
b. Сделать информацию внятной — чтобы Заказчик мог понять, откуда взялись эти цифры, и как они были получены.
c. Сделать информацию наглядной — чтобы у Заказчика и мысли не возникло спорить.

Соответственно, что можно посоветовать дле решения этих задач? Программа-минимум для того, чтобы сделать информацию полной:

1. Выбирать осмысленные названия задач, поставленных исполнителям. Название должно быть достаточным для того, чтобы можно было понять, о чем идет речь, даже через месяц после того, как оно выполнено. Оптимально — каждая задача есть реализация конкретного требования или функционала, например «Сделать UC-01 Login» или «Сделать сервис wsPollTriggerStatus»
2. Собирать информацию ежедневно — в конце недели вместо мучительных раздумий о том, сколько времени было потрачено на какую задачу, исполнители обычно вписывают «на глазок» цифры, «похожие на правду». При ежедневном сборе и проверке обеспечивается необходимая очистка данных (я называю ее refinement, «дистилляция»).
3. Отображать информацию в сводной таблице — чтобы видеть картину по крайней мере с еженедельной детализацией.

Невнятность — один из самых частых дефектов информации об использовании времени. Чтобы информация была внятной, надо:

1. Заранее договориться о способе учета рабочего времени. То есть — как, кем и с какой периодичностью собирается, кому предоставляется, какова процедура утверждения заполненных табелей учета времени. Это спасет вас от трений, кто кому был что должен представить, а кто кому что должен был утвердить. Трения этого рода портят отношения с Заказчиками и проводят к срыву регулярной оплаты счетов — эксцессы такого рода очень злят начальство (поверьте, будучи начальством, знаю, о чем пишу).
2. Обязательно (ОБЯЗАТЕЛЬНО) договариваться, какие категории задач вносятся в табель, а какие нет. Это же касается работы конкретных исполнителей. Это спасет вас от трений о том, нужна ли была данная конкретная задача или данный конкретный человек. Трения этого рода гарантированно приводят к снижению объема оплаченного времени на проекте, что опять-таки отрицательно сказывается на проектной команде и отношениях с Заказчиком.
3. Установить способ учета рабочего времени. Для Заказчика наиболее оптимальным является способ учета рабочего времени «потрачено часов на каждую задачу в день». Собственно, у вас нет никаких оснований ему возражать.

Чтобы сделать информацию наглядной, надо:

Согласовать форму предоставления Заказчику информации — файл и печатный лист, на котором сразу видно, кто, что, когда, сколько и почему. О почему — ниже.

1. Требовать снабжать отчеты о потраченном времени комментариями. Во всяком случае, если по какой-то причине эти значения отличаются от тех, которые хочет увидеть клиент. Например, простой комментарий типа «пришлось не только обновить структуру базы, но и перелить в нее боевые данные, которые уже начал вносить клиент, хотя его просили этого не делать» экономит массу времени и нервов менеджеру проекта, которого Заказчик спрашивает «почему такая простая задача, как запустить скрипт обновления базы, заняла два часа?!!»
2. Сводить для каждой задачи комментарии в единый список — чтобы составлялся своего рода «тезисный план» о том, как работали по задаче. Это особенно актуально, если над задачей работало несколько человек. Например, задача «подготовка прототипов интерфейса». Работали над ней как минимум специалист по юзабилити, дизайнер и верстальщик. Задача одна, работу делали трое, каждый оставил комментарии — соответственно, все комментарии сводятся воедино.

Собственно, рекомендации нехитрые. Видимо, поэтому и работают.

Кстати, данный вариант сбора статистики работает и в третьем случае (сбор статистики для начисления зарплаты). Собственно, в данном случае Заказчиком выступаете вы сами — примерьте описанные выше рекомендации «на себя» и убедитесь, что они не лишены смысла.

Итак, нерассмотренным остается только второй случай:

Сбор статистики для внутренних нужд

Зачем собирается статистика для внутренних нужд? Целей как минимум три:

• Менеджер и Спонсор проекта хотят понимать состояние проекта. В первую очередь — не будет ли превышения бюджета и расписания? Эти характеристики легко высчитать на основании информации об использованном времени.
• Менеджер и Спонсор проекта должны иметь возможность точно предсказывать, сколько времени займет тот или иной проект. Для этого им необходима накопленная база статистической информации. Имея на руках эту информацию, они могут делать оценки будущих проектов методом прямой аналогии, коий из всех методов является наиболее надежным.
• Менеджер и Спонсор проекта хотят понимать финансовую эффективность команды и проекта.

Итак, мы определили три задачи, которые мы должны решать при учете рабочего времени, выполняемом для внутренних нужд. Следует отметить, что кроме установления порядка предоставления отчетности требуется решить еще ряд проблем, в том числе организационных — иначе задачи будут нерешаемы. Предлагаю исследовать механизмы выполнения задач и решения проблем более подробно.

Задача первая — определять, не будет ли превышения бюджета и расписания. Отправной точкой здесь является наличие бюджета и расписания. Они есть у любого проекта, независимо от типа: у типичной заказной разработки — контрактный бюджет и график проекта, у проекта с почасовой оплатой типа «доработка» — бюджет и график этапа\задачи, у проекта типа «поддержка» — объем предоплаченного Клиентом времени в контракте на поддержку. Соответственно, любой проект в системе управления проектами имеет два параметра — одобренный бюджет, у.е. ( approved budget ) и одобренная длительность, раб. дней ( approved duration ). Их устанавливает Спонсор проекта — руководитель организации, давший «добро» на начало этого проекта. Эту практику необходимо выработать и неукоснительно соблюдать.

Далее все происходит предельно просто. Менеджер ставит задачи и определяет трудозатраты (work), которые могут потратить исполнители на выполнение этих задач. Исполнители отчитываются о выполнении задач, при необходимости запрашивая дополнительные трудозатраты. Менеджер с помощью метода под названием «анализ освоенного объема» ( earned value analysis , про него написано достаточно и нет нужды повторяться) рассчитывает два параметра — CPI и SPI ( Cost Performance Index и Schedule Performance Index ). Если они больше единицы — менеджер чуствует себя спокойно. Если они меньше единицы — он напрягается и рассчитывает еще один параметр — EAC ( Estimate at completion , оценка на завершение). Считает он ее для того, чтобы сравнить с одобренным бюджетом ( approved budget ). Если EAC > Approved budget — то пахнет жареным, это означает, что мы будем иметь превышение бюджета по завершению проекта. Что делать для исправления ситуации — вопрос не по теме данной статьи.

Конечно же, менеджер считает эту информацию не вручную. Для него это делает система управления проектами предприятия (Enterprise Project Management System, EPMS). Данные ему она представляет в виде простой и доходчивой информационной панели — см. рис. 1.

Рисунок 1. Информационная панель с информацией об исполнении бюджетов и графика.

В теории все выглядит все достаточно просто. На практике бывает существенно сложнее. Сложность №1.

«Исполнители отчитываются о выполнении задач». Отчитываться можно минимум тремя способами:

1. Процентов выполнено (0-100%). Подразумевается, что если задача на 8 часов, и выполнение 100%, то потрачено 8 часов. В общем случае верно, но не учитывает возможность того, что для достижения 100% готовности могло понадобится 10 часов. Соответственно, если трудозатраты проекта выросли на пару часов, а график сбился на полдня, то никто этого как бы не заметит. Кроме того, есть чисто субъективные сложности исчисления процентов — что для одного 75%, то для другого — 10%. Ввиду этих недостатков крайне не рекомендую использовать этот метод.
2. Трудозатрат потрачено — трудозатрат осталось (часов). Мой любимый метод. Подразумевается, что если задача на 8 часов, и ты ее выполнил — ты указываешь, что потраченное время 8 часов. Система сама считает, что процент выполнения равен 100%. Прелесть в том, что если в конце дня ты понял, что осталось еще на 2 часа работы, то указываешь в отчете «потрачено» 8 часов, «осталось» еще 2 часа — и система рассчитывает соответствующий процент выполнения, включая твои 2 часа в общий план и при необходимости сдвигая график проекта. У метода есть один большой недостаток — что делать, если человек на самом деле сделал задачу за 6 часов? Во многих компаниях это станет неразрешимой проблемой — раз человек отдан на проект на весь день, он должен отчитаться 8 часами, и не важно, сколько он там потратил на самом деле! Такие подходы существенно снижают ценность собираемой статистики, так как она не отражает реального состояния дел (см. ниже).
3. Потрачено на задачу, часов в день — суть метода объяснена в названии. Наверное, самый распространенный способ учета рабочего времени. Имеет только одно неудобство — собирать данные нужно каждый день, иначе в конце недели менеджер получает от десятка членов команды табели рабочего времени, заполненные по принципу «ну-я-не-сильно-помню-но-вроде-того». Табели нужно внимательно читать и при необходимости возвращать для корректировки. Для 10 человек процесс довольно муторный: 10 человек * 5 дней * пару задач в день = таблица из 100 строк. Кто будет вдумчиво в них вчитываться?

Итого — для того, чтобы исполнители осмысленно отчитывались о выполнении задач и на этих данных можно было использовать метод освоенного объема, требуется использовать 2-ой или 3-ий метод сбора отчетности. Первый, используемый почти во всех системах управление проектами предприятия по умолчанию, совершенно не годится.

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

1. Определить бюджет и длительность — сделать это правильно в начале проекта и корректировать оценки при изменения предмета и границ проекта.
2. Ставить задачи — оптимально каждая задача должны быть продолжительностью в день и поставлена в соответствии с критерием SMART — Specific, Measurable, Achievable, Realistic, Time-related.
3. Контролировать использование бюджета — ежедневно или в крайнем случае еженедельно, собирая отчетность об исполнении задач.
4. Контроливать исполнение бюджета — рассчитывая EAC и сравнивая его с одобренным бюджетом.

На этом сложности не заканчиваются. Сложность №2.

Знаете, зачем от вас требуют указывать каждый день 8 часов отработанного времени (даже если вы его не отработали)? Потому что оно должно быть отнесено на какой-то конкретный финансовый центр (cost center) — проект, отдел, заказ и т.д. Для каждого финансового центра в итоге считаются две вещи — затраты (cost) и прибыль (profit). После чего делается вывод о прибыльности или убыточности данного проекта, отдела, заказа и т.д. При этом возникает одна любопытная особенность.

Предположим, вас назначили на проект на один день на задачу с бюджетом трудозатрат 8 часов. Вы быстренько (за 4 часа) порвали задачу на британский флаг и тихо сидите и смотрите кино. При этом компания, что характерно, начисляет вам за это время зарплату. Поэтому при фактических трудозатратах в 4 часа на проект будет начислено 8 часов — думаю, вам теперь понятно, почему. Проблема в другом — эта вынужденная и экономически совершенно оправданная мера лишает статистику всякого смысла, так как на статистике в таком случае нельзя основывать оценки методом аналогии — получим погрешность в два раза (8 \ 4 = 2).

Что делать в такой ситуации? Программа-минимум — завести еще одно поле, назвав его real hours , hrs (реальные часы) и писать в него имеющие место быть значения, в том время как в поле work писать требуемые 8 часов. Подход неидеальный ввиду решения задачи «в лоб», но по этой же причине очень прост. В результате можно иметь статистику, подобную указанной на картинке, приведенной ниже, и делать осмысленные оценки длительности и стоимости будущих проектов. Другой способ — разнести ресурсное планирование и сбор отчетности в репозитарий проектной информации. При кажущейся излишней сложности метод в конечном итоге дает лучшие результаты.

Собственно, теперь осталось только рассказать о связи проектных метрик и бонусов. Но ввиду болезненности данной темы и существенного объема мыслей по поводу решил написать об этом отдельную статью, которая выйдет в ближайшее время.

В таком случае остается только резюмировать:

1. Нет идеального метода сбора отчетности. Метод надо соотносить с задачами, которые вы собираетесь решать с помощью накопленной статистики.
2. Статистика ради статистики бессмысленна. Конечно, интересно смотреть, на какие проекты уходит больше всего ресурсов. Но лучше использовать статистику для ответов на вопросы — как минимум вы можете использовать ее для того, чтобы делать осмысленные оценки будущих проектов. Но лучше всего использовать ее для измерения финансовой эффективности.
3. Накополение данных в репозитарии статистики опирается на метод сбора отчетности. При этом какой бы метод вы не избрали, потребуется его признание на организационном уровне, за исключением тех случаев, когда вы собираете данные «для себя» — например, для оценки будущих проектов конкретной команды. Но если не всех меряют одной линейкой, то полученные вами данные не могут служить показателем, скажем, вашей финансовой эффективности по сравнению с другими проектами.
4. В основе измерения финансовой эффективности — понятие «одобренный бюджет». Следовательно, пока такой термин не появится в официальном словаре организации вместе с процедурой его утверждения, методы измерения есть не более чем фикция.

Из этого следует, что организация учета рабочего времени — это не просто установка соответствующей программы с требованием предоставлять отчетность каждую неделю. Это — решение целого набора вопросов, в том числе организационных. И первый вопрос, с которого рекомендуется начать — «зачем мы это делаем?»