Оценка задач в человеко-часах и ее альтернативы
Сначала об одной из частых ошибок — оценке задач в человеко-часах.
Удивительно, что многие команды в разработке ПО продолжают использовать оценку задач на основе человеко-часов и даже человеко-дней.
Например, работы по отдельной задаче команда оценивает так: аналитику нужно 2 дня, разработчику 6 дней, тестировщику 3 дня. Получаем общую сумму в 11 дней, кладем на календарь, получаем дату окончания работ = день начала + 11 дней.
И примерно в 100% случаев результат по задаче выдается позже озвученной даты и наши заказчики начинают становиться недовольными.
В чем причина? Как минимум, при такой оценке не учитываются временные затраты на встречи, ожидание, помощь коллегам и даже фикс ошибок, найденных тестировщиком. Все эти активности занимают достаточно большое количество времени и общий срок по задаче улетает за 11 дней.
Есть два способа улучшить точность оценки, не сделав ее процесс сложнее.
1. Использовать понятие «идеальный час» — это час рабочего времени, когда мы в субботу сидим одни в комнате, все прочие дела сделаны, в наушниках играет любимая музыка и мы максимально погружены в решение задачи без единого отвлекающего фактора.
То есть процесс оценки в часах обычно выглядит так: «если тебя никто не будет отвлекать, ты сядешь и целиком погрузишься в задачу — сколько часов тебе потребуется, чтобы ее сделать?»
Теперь остается умножить полученную оценку на некий коэффициент, отражающий соотношение идеального времени к реальному в вашей команде, например, на 1,4.
Раньше такой коэффициент называли фокус-фактор, но поскольку в целом оценка в часах признана мировым сообществом слишком неточной, от нее так или иначе уходят на следующий способ.
2. Самая точная и при этом быстрая оценка задач (вернее сказать, пользовательских историй) — в сторипоинтах.
Это относительные размеры историй друг к другу, без привязки к часам, работам определенной роли (анализ, разработка, тестирование) и вообще календарю.
Например, задача по выпуску виртуальной карты может иметь оценку в 13 поинтов, а задача по отображению ее реквизитов — оценку в 3 поинта.
Что это для нас значит?
Что реквизиты примерно в 4 раза проще выпуска карты и очевидно более определенные с точки зрения требований, зависимостей и возможных рисков.
Предположим команда в двухнедельный спринт делает историй в среднем на 20 поинтов. Исходя из этого можно научиться достаточно точно планировать как объем спринта, так и сроки по набору историй из бэклога, и, конечно, выполнять обязательства.
В чем вообще проблема с оценками?
Почему в общем случае крайне сложно дать точную оценку? (Говоря об оценке работ так называемого умственного труда, knowledge work.)
1. В вариативной среде, которой свойственная большая неопределенность (например, создание нового продукта), при этом работая командой в несколько человек, физически невозможно заранее предугадать все факторы, которые возникнут в процессе работы и повлияют на ее длительность.
2. Требования, которые у нас есть на старте - не описывают будущий продукт на 100%, какими бы объемными и детальными они ни были. В отличие от, например, изготовления детали по чертежу или строительство дома по готовой проектной документации.
3. И самое главное — проблема в ДНК процесса оценки.
Когда нас просят что-то оценить, нам говорят буквально следующее «На основе информации, которая есть у вас сейчас и вашего опыта, когда, как вам кажется, вы могли бы это сделать?».
Мы говорим (применяя любую методику оценки), например, через 20 дней, или к 17 ноября. И это тот оценочный срок, который нас попросили назвать.
Но в ту же секунду, те кто нас спрашивает о сроках (заказчики), воспринимают его как дедлайн, под который мы только что сами подписались. Отсюда и возникают недоверие и напряженность в отношениях между заказчиками и командой. И, конечно, сорванные сроки.
Поэтому нужно искать кардинально иные способы прогнозирования сроков поставки результата.
В следующем посте я расскажу про еще два способа, как можно договариваться с заказчиками, не прибегая к привычной экспертной оценке.
