Идеальный час
Почему так
трудно планировать? Почему фактическое время, потраченное на задачи,
всегда выше запланированного? Даже когда мы доверяем оценки непосредственно
тем людям, которые должны выполнять задачу, они все равно ошибаются.
При этом они всегда находят тысячи оправданий превышению сроков
- "дернули" на другой проект, кто-то помешал, отвлекли в бухгалтерию
по поводу ИНН и так далее. Эта ситуация типична. В этой статье немного
о проблемах планирования и их источнике - "идеальном часе".
«Во множестве
компаний есть статистика об использовании рабочего времени. Но ни
в одной я не видел статистики по качеству этого времени.» Том де
Марко, Тим Листер.
Peopleware,
2nd
Edition.
Хочу нарисовать
гипотетическую ситуацию, которую, думаю, узнают многие менеджеры
разработчиков.
Итак, предположим,
что сегодня вечером было совещание по статусу на Вашем текущем проекте.
У Вас работает разработчик Федя. Федя – вполне способный программист
с солидным стажем. Вы ставите ему задачу Х. Выдав ему хорошо сформулированную
постановку задачи, Вы спрашиваете – Федя, сколько времени тебе надо,
чтобы закодировать задачу Х?
Федя немного думает
и говорит – четыре часа, максимум - шесть. Вы резюмируете – окей,
исходя из того, что завтра ты начнешь в 9 часов утра, в 6 вечера
мы уже включим твое творчество в завтрашний дневной билд? Федя отвечает
– Никаких проблем, все будет в лучшем виде.
Наступает завтра,
6 часов вечера. Федя не готов. Ему надо еще 2-3 часа. Почему не
готов, объяснить толком не может. Вопрос «чем ты занимался весь
день?!!» повергает его в ярость. Вы глубоко разочарованы в Феде.
Оказывается, он разгильдяй – а ведь выглядит вполне способным программистом...
Так трудно в наше время найти хорошие ресурсы...
Не грешите поспешными
суждениями. Вы лучше меня знаете, что у каждого следствия есть причина.
Давайте ее поищем. Понаблюдаем за Федей во время его работы, поищем
эту причину.
Итак, хроника
рабочего дня Феди.
v
Реализация
USECASE-01
Login (4
часа)
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.
Итак, коэффициент
есть. Теперь надо учесть при планировании. Самый простой способ
сделать это – перейти от коэффициента к множителю, т.е. получить
значение, на которое нужно умножить запланированную длительность
проекта. В нашем случае для этого подойдет следующая формула:

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