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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

Хотите узнать, каких результатов можно достичь с помощью Agile в вашем проекте или компании?
Напишите нам
                                                      

Еще публикации по Agile в Agile, Scrum, Kanban–метод

Публикация
Agile, Scrum, Kanban–метод
Зачем улучшать процессы компании?
Зачем оптимизировать процессы? Существует правило: качество продукта или сервиса, который мы оказываем клиенту, всегда НЕ выше качества внутренних процессов компании.
Публикация
Agile, Scrum, Kanban–метод
Материалы для самостоятельного изучения Agile
Мы собрали для вас список самых важных книг на тему Agile и всего того, что пригодится на нелегком пути трансформации. Они могут вам самостоятельно изучить подход, а также закрепить и расширить полученные на тренингах знания.
Публикация
Agile, Scrum, Kanban–метод
Product owner и скрам-мастер: почему важно разделять эти роли
При внедрении Scrum появляются две новые роли: владелец продукта и скрам-мастер. И часто бывает, что на них решают назначить одного человека — обычно это менеджер проекта или тимлид. Но это не лучшее решение.
Публикация
Agile, Scrum, Kanban–метод
Подготовка корпоративной культуры к Agile (видео)
Основные причины, мешающие традиционным компаниям вставать на путь гибкости и уверенно по нему идти.

С 2004 года мы помогаем адаптировать к изменениям культуру и процессы компании

Связаться с нами

Дмитрий Лобасев

Managing Partner

+7 495 221 87 39

dmitry@onagile.ru

Наш Telegram канал об Agile и гибких организациях, присоединяйтесь!