20.05.2010
»Во множестве компаний есть статистика об использовании рабочего времени. Но ни в одной я не видел статистики о качестве этого времени»
Том де Марко, Тим Листер, Peopleware
Хочу нарисовать гипотетическую ситуацию, которую, думаю, узнают многие менеджеры разработчиков.
Итак, предположим, что сегодня вечером было совещание по статусу на вашем текущем проекте. У вас работает разработчик Федя. Федя – вполне способный программист с солидным стажем. Вы ставите перед ним задачу Х. Выдав ему хорошо сформулированную постановку задачи, спрашиваете: Федя, сколько времени тебе надо, чтобы закодировать задачу Х?
Федя немного думает и говорит: четыре часа, максимум — шесть. Вы резюмируете: окей, исходя из того, что завтра ты начнешь в 9 часов утра, в 6 вечера мы уже включим твое творчество в завтрашний дневной билд? Федя отвечает: Никаких проблем, все будет в лучшем виде.
Наступает завтра, 6 часов вечера. Федя не готов. Ему надо еще 2–3 часа. Почему не готов, объяснить толком не может. Вопрос »чем ты занимался весь день?!!» повергает его в ярость. Вы глубоко разочарованы в Феде. Оказывается, он разгильдяй – а ведь выглядит вполне способным программистом… Так трудно в наше время найти хорошие ресурсы…
Не грешите поспешными суждениями. Вы лучше меня знаете, что у каждого следствия есть причина. Давайте ее поищем. Понаблюдаем за Федей во время его работы, поищем эту причину.
Итак, хроника рабочего дня Феди.
1. 10:00. Пришел на работу. Был уведен на совещание по соседскому проекту в качестве консультанта.
2. 11:00. Выпил кофе. Встретил Ивана, вышли покурить.
3. 11:15. Сел писать UC-01.
4. 12:30. Пришли чинить кондиционер. Согнали с места, пью кофе, сходил покурил.
5. 13:00. Позвали в бухгалтерию. Долго распрашивали о каких-то бумажках со сложными аббревиатурами.
6. 13:30. Ушел обедать.
7. 14:30. Пришел с обеда, начал работать. Дописал почти все, осталась самая малость.
8. 16:00. Снова совещание. Сижу, рисую в блокноте. Деваться некуда – меня сюда загнал заместитель директора.
9. 17:00. Через час выпуск дневного билда, а у меня еще ничего не готово!
10. 18:15. Получил от DTL нагоняй: »Задача на полдня, а ты весь день с ней провозился, да еще и опоздал!»
Итак, причина прорисовывается, верно? Сколько времени Федя потратил на непосредственно написание кода? 15 минут + 1 час 30 минут + 1 час 15 минут. Итого – 3 часа! На осуществление его прямых обязанностей в вашем проекте у него было всего три часа вместо четырех, которые были ему нужны! И он справился гораздо раньше – он потратил меньше чем четыре часа! Его хвалить надо было, а не ругать! Надеюсь, теперь Вы понимаете, почему его взбесил вопрос »чем ты занимался весь день?»
Он занимался работой. Просто КПД его деятельности был вынужденно низким. Не потому, что плох Федя. А потому, что продуктивность любого разработчика влияет на то, что я называю »коэффициентом мусорного времени». Грубо говоря – это соотношение непроизводительных часов к производительным. В случае Феди – 5:3, что означает что для выполнения 4-часовой задачи ему был необходим весь день и еще немного следующего. Если посмотреть на его результат, то мы увидим, что это вполне справедливо – Федя лихорадочно заканчивал дописывать свой код после того, как рабочий день кончился.
Сразу хочется предостеречь тех, кто считает, что в их организации »мусорного времени» нет. »Мусорное время» есть всегда. У одних его больше, у других меньше. Пронаблюдав порядка двух десятков компаний, я вывел следующие значения »коэффициента мусорного времени»:
Лучшие компании (две из 19)
- 1\7
- 1\6,5
Средние значения
- 2\6
- 3\5
Худшая
- 4\4
Итак, лучше вам, как менеджеру, сразу избавиться от иллюзии того, что »мусорное время» на ваш проект не влияет.
Метки: