Как оценивать сроки завершения работы

Оценка задач в человеко-часах и ее альтернативы

Сначала об одной из частых ошибок — оценке задач в человеко-часах.

Удивительно, что многие команды в разработке ПО продолжают использовать оценку задач на основе человеко-часов и даже человеко-дней.

Например, работы по отдельной задаче команда оценивает так: аналитику нужно 2 дня, разработчику 6 дней, тестировщику 3 дня. Получаем общую сумму в 11 дней, кладем на календарь, получаем дату окончания работ = день начала + 11 дней.

И примерно в 100% случаев результат по задаче выдается позже озвученной даты и наши заказчики начинают становиться недовольными.

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

Есть два способа улучшить точность оценки, не сделав ее процесс сложнее.

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

То есть процесс оценки в часах обычно выглядит так: «если тебя никто не будет отвлекать, ты сядешь и целиком погрузишься в задачу — сколько часов тебе потребуется, чтобы ее сделать?»

Теперь остается умножить полученную оценку на некий коэффициент, отражающий соотношение идеального времени к реальному в вашей команде, например, на 1,4.

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

2. Самая точная и при этом быстрая оценка задач (вернее сказать, пользовательских историй) — в сторипоинтах.

Это относительные размеры историй друг к другу, без привязки к часам, работам определенной роли (анализ, разработка, тестирование) и вообще календарю.

Например, задача по выпуску виртуальной карты может иметь оценку в 13 поинтов, а задача по отображению ее реквизитов — оценку в 3 поинта.

Что это для нас значит?

Что реквизиты примерно в 4 раза проще выпуска карты и очевидно более определенные с точки зрения требований, зависимостей и возможных рисков.

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

В чем вообще проблема с оценками? 

Почему в общем случае крайне сложно дать точную оценку? (Говоря об оценке работ так называемого умственного труда, knowledge work.)

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

2.  Требования, которые у нас есть на старте - не описывают будущий продукт на 100%, какими бы объемными и детальными они ни были. В отличие от, например, изготовления детали по чертежу или строительство дома по готовой проектной документации. 

3.  И самое главное — проблема в ДНК процесса оценки.

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

Мы говорим (применяя любую методику оценки), например, через 20 дней, или к 17 ноября. И это тот оценочный срок, который нас попросили назвать.

Но в ту же секунду, те кто нас спрашивает о сроках (заказчики), воспринимают его как дедлайн, под который мы только что сами подписались. Отсюда и возникают недоверие и напряженность в отношениях между заказчиками и командой. И, конечно, сорванные сроки.

Поэтому нужно искать кардинально иные способы прогнозирования сроков поставки результата.

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