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

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

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

• Требование Заказчика на предоставление детальной статистики. Практически неизбежно для проектов с почасовой оплатой, что естественно — так как Заказчик оплачивает ваше время, он хочет быть уверен в том, что вы работаете, а не курите бамбук.
• Сбор статистики для внутренних нужд. К каковым можно отнести: сбор исторической информации для оценок будущих проектов, определение эффективности исполнения проекта для исчисления бонуса, рассчет ключевых показателей (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. В основе измерения финансовой эффективности — понятие «одобренный бюджет». Следовательно, пока такой термин не появится в официальном словаре организации вместе с процедурой его утверждения, методы измерения есть не более чем фикция.

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

Запись Учет рабочего времени — почему, зачем и как впервые появилась Портал TMGuru.

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

«Во множестве компаний есть статистика об использовании рабочего времени. Но ни в одной я не видел статистики о качестве этого времени…» Том де Марко, Тим Листер. Peopleware, 2-nd Edition.

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

Итак, предположим, что сегодня вечером было совещание по статусу на Вашем текущем проекте. У Вас работает разработчик Федя. Федя — вполне способный программист с солидным стажем. Вы ставите ему задачу Х. Выдав ему хорошо сформулированную постановку задачи, Вы спрашиваете — Федя, сколько времени тебе надо, чтобы закодировать задачу Х?

Федя немного думает и говорит — четыре часа, максимум — шесть. Вы резюмируете — окей, исходя из того, что завтра ты начнешь в 9 часов утра, в 6 вечера мы уже включим твое творчество в завтрашний дневной билд? Федя отвечает — Никаких проблем, все будет в лучшем виде.

Наступает завтра, 6 часов вечера. Федя не готов. Ему надо еще 2-3 часа. Почему не готов, объяснить толком не может. Вопрос «чем ты занимался весь день?!!» повергает его в ярость. Вы глубоко разочарованы в Феде. Оказывается, он разгильдяй — а ведь выглядит вполне способным программистом… Так трудно в наше время найти хорошие ресурсы…

Не грешите поспешными суждениями. Вы лучше меня знаете, что у каждого следствия есть причина. Давайте ее поищем. Понаблюдаем за Федей во время его работы, поищем эту причину.

Итак, хроника рабочего дня Феди.

• Реализация USE CASE-01 Login (4 часа)
  • 10:00. Пришел на работу. Был уведен на совещание по соседскому проекту в качестве консультанта.
  • 11:00. Выпил кофе. Встретил Ивана, вышли покурить.
  • 11:15. Сел писать UC-01.
  • 12:30. Пришли чинить кондиционер. Согнали с места, пью кофе, сходил покурил.
  • 13:00. Позвали в бухгалтерию. Долго распрашивали о каких-то бумажках со сложными аббревиатурами.
  • 13:30. Ушел обедать.
  • 14:30. Пришел с обеда, начал работать. Дописал почти все, осталась самая малость.
  • 16:00. Снова совещание. Сижу рисую в блокноте. Деваться некуда – меня сюда загнал заместитель директора.
  • 17:00. Через час выпуск дневного билда, а у меня еще ничего не готово!
  • 18:15. Получил от DTL нагоняй: «задача на полдня, а ты весь день с ней провозился, да еще и опоздал!»

Итак, причина прорисовывается, верно?

Сколько времени Федя потратил на непосредственно на написание кода? 15 минут + 1 час 30 минут + 1 час 15 минут. Итого — 3 часа! На осуществление его прямых обязанностей в Вашем проекте у него было всего три часа вместо четырех, которые были ему нужны! И он справился гораздо раньше — он потратил меньше чем четыре часа! Его хвалить надо было, а не ругать! Надеюсь, теперь Вы понимаете, почему его взбесил вопрос «чем ты занимался весь день?»

Он занимался работой. Просто КПД его деятельности был вынужденно низким. Не потому, что плох Федя. А потому, что продуктивность любого разработчика влияет то, что я называю «коэффициентом мусорного времени». Грубо говоря — это соотношение непроизводительных часов к производительным. В случае Феди — 5:3, что означает что для выполнения 4х часовой задачи ему был необходим весь день и еще немного следующего. Если посмотреть на его результат, то мы увидим, что это вполне справедливо — Федя лихорадочно заканчивал дописывать свой код после того, как рабочий день кончился.

Сразу хочется предостеречь тех, кто считает, что в их организации «мусорного времени» нет. «Мусорное время» есть всегда. У одних его больше, у других меньше. Пронаблюдав порядка двух десятков компаний, я вывел следующие значения «коэффициента мусорного времени»:

• Лучшие компании (две из 19)
  • 1\7
  • 1\6,5
• Средние значения
  • 2\6
  • 3\5
• Худшая
  • 4\4

Итак, лучше Вам, как менеджеру, сразу избавиться от иллюзии того, что «мусорное время» на Ваш проект не влияет. А теперь самое интересное — как учесть влияние «мусорного времени» на Ваш проект?

Действовать в данном случае стоит в двух направлениях:

1. учитывать «коэффициент мусорного времени» при планировании (обязательно)
2. снижать «коэффициент мусорного времени» путем устранения источников мусора (тема, заслуживающая отдельной статьи)

Давайте по порядку. Прежде всего — как учитывать коэффициент при планировании. Прежде чем учитывать, его надо определить. Определяется он элементарно просто — назначаете своим разработчикам несколько коротких и безрисковых, но осмысленных задач (при длинных или рискованных задачах начинают действовать факторы громоздкости или рисков, что нежелательно для «чистоты эксперимента»). Лучше всего на роль таких задач подходят типовые задачи по имплементации стандартных функций (отображение данных, создание элементов и т.д.) При этом просите их сформулировать оценки в «идеальных часах» (сколько надо времени, если сесть и писать задачу от начала и до конца, и никто при этом не будет мешать, без включения просадки, и если не надо будет есть, курить и т.д.) После этого нажмите кнопку секундомера и пусть все начинают. Сравните полученные фактические значения продолжительности с продолжительностью в идеальных часах. Поздравляем, вы получили «коэффициент мусорного времени». Идеально это будет что-то вроде 1:7 .

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

Давайте рассмотрим действие формулы на примере. Предположим, у Вас есть проект, чистая продолжительность которого (без учета влияния «мусорного времени») равна 10 дням. При этом в рабочем дне 8 часов. «Коэффициент мусорного времени» равен 1:7, то есть один час в день «мусорный».

Уверен, что практика покажет, что эта оценка была правильной. Важно другое — без учета этого фактора Вы каждые 10 дней «теряете» один день. А если проект был длиной полгода, то по милости «коэффициента мусорного времени» Вы потеряете 12 дней — отстанете более чем на две недели… Знакомо, не правда ли?

Этот метод вполне точен и годится для оценок. Еще более точным методом может стать использование статистического моделирования — например, с помощью инструмента Riskology, разработанного Томом де Марко и Тимом Листером для моделирования влияния рисков на проекты. Получить его можно по адресу SystemsGuild.Com, и там же находится инструкция по применению. Согласно этой инструкции надо задать параметры проекта, внести новый риск непрерывного типа «Влияние мусорного времени», и задать коэффициент его влияния согласно инструкции.

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

Что можно порекомендовать для борьбы с издержками? Мусорное время можно искать в четырех возможных областях рабочей деятельности:

1. Административная деятельность поддерживающих служб компании. Однажды с ужасом наблюдал, как строгая тетенька в очках несколько раз заставляла Ведущего разработчика проекта переделывать авансовый отчет, в то время как в переговорной томились представители заказчика. Стоит ли говорить, что такая ситуация недопустима. Не стоит забывать, что задачи Административно-хозяйственной службы — обеспечивать производственную деятельность, а не мешать ей. В своей компании, например, я установил такой порядок — бухгалтер готовит для сотрудника весь набор документов, и ему остается лишь поставить свою подпись.
2. Бюрократическая деятельность, связанная с проектным делопроизводством. Другая бездонная пропасть, поедающая время. Зачем заполнять журнал учета рабочего времени с пятнадцатиминутной детализацией, если заказчик этого не требует? Зачем снабжать документ из одной страницы тремя страницами шапок, обязательных к заполнению? Примеров такого бездарного использования рабочего времени можно привести много. Мой совет — обходитесь минимумом бумаги, и даже при этом автоматизируйте эту область деятельности по максимуму.
3. Рабочая обстановка самого офиса. Если люди начинают приходить на работу к восьми часам или уходить в час ночи — это верный признак того, что в офисе лучше всего работается когда никого нет. При этом может мешать множество факторов — скученность, телефонные разговоры, громкие обсуждения, духота.
4. Личные интересы сотрудников. Возможно, я кого-то удивлю, но достаточно много людей рассматривает работу как способ заниматься любыми делами за чужой счет. Чаты, форумы, поиск фильмов и музыки, онлайновые знакомства — вот далеко не полный перечень развлечений в рабочее время. Конечно, не надо путать теплое с мягким — форумы могут способствовать профессиональному росту, коммуникаторы можно использовать для общения с коллегами из других городов — но во всем хороша мера.

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

1. Разрешите своим разработчикам отвечать на все письма, не связанные напрямую с рабочей деятельностью, в конце рабочего дня. Данная рекомендация особенно актуальна для больших компаний. Каждый день сотрудники получают как минимум два-три письма типа «сообщите», «проголосуйте», «представьте данные». Все это мешает сосредоточиться и отнимает время, при этом не является критичным. В конце концов, если я проголосую по поводу качества обедов три часа спустя — неужели небо упадет в Дунай?
2. Требуйте использовать голосовую почту на рабочих и персональных рабочих телефонах. Во-первых, это существенно сократит уровень шума в комнате, а во-вторых, позволит людям сохранять концентрацию, так как они не будут отвлекаться на звонки. Голосовую почту можно проверять на перекурах или кофе-брейках, убивая двух зайцев.
3. Сядьте так, чтобы видеть мониторы членов Вашей рабочей группы. После этого удивительным образом возрастет количество времени, которое люди уделяют работе и соответственно снизится время, уделяемое auto.ru. Обычно лучше всего расставить рабочие столы по периметру комнаты вплотную к стенам — это, во-первых, обеспечит достаточное количество рабочего пространства, во-вторых обеспечит свободу передвижения что важного для парного программирования, например, и в-третьих поможет Вам занять стратегический наблюдательный пункт, с которого все видно. Тем не менее, лучше объявить, что все хобби в интернете остаются на вечер — в конце концов, должна же быть у людей личная жизнь?
4. Станьте брандмауэрами перед Вашими людьми. Защищайте их от бюрократов, попыток вовлечь их в бесконечные совещания, начать менять им мебель в середине рабочего дня — одним словом, от любых действий, которые могут помешать им работать.

Вот, вкратце, и все. Надеюсь, эти несложные рекомендации помогут читателям бороться с коварством «мусорного времени». Как всегда, если у кого-то есть аналогичный опыт, свои инструменты или наработки, которыми он хочет поделиться, или мнение, которым он хочет обменяться — жду его по адресу dp@dpconsulting.ru.

Запись Идеальный час впервые появилась Портал TMGuru.