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

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

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

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

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

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

Например, работы по отдельной задаче команда оценивает так: аналитику нужно 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-команды переходят на гибкие методы оценки в сторипоинтах.

Как правильно использовать story points для оценки задач в Скраме?

Story points (сторипоинты) в Scrum используются для относительной оценки сложности задач. Команда выбирает эталонную задачу и присваивает ей определенное количество points, затем оценивает остальные задачи относительно эталона. Это помогает точнее планировать спринты и прогнозировать сроки разработки, основываясь на реальной производительности команды (velocity).

Какие методы оценки задач используются в современной IT-разработке?

В современной IT-разработке используется несколько основных методов оценки задач: сторипоинты в Scrum, идеальные часы с учетом фокус-фактора, покер планирования для командной оценки, T-shirt sizing для быстрой приблизительной оценки. Выбор метода зависит от используемого фреймворка (Scrum, Kanban) и специфики проекта.

Как правильно планировать спринт, чтобы не срывать сроки?

Для эффективного планирования спринта в Scrum важно: использовать исторические данные о velocity команды, учитывать capacity (доступность) участников, правильно оценивать задачи в story points, оставлять буфер на непредвиденные работы. Команды, использующие такой подход, значительно реже срывают дедлайны.

Как фокус-фактор помогает в оценке задач?

Фокус-фактор в Agile показывает, какую часть рабочего времени команда реально тратит на разработку. Например, при факторе 0.6 из 8 часов рабочего дня эффективными являются около 5 часов. Это помогает точнее планировать спринты и оценивать время разработки новых фич. Однако современные команды чаще используют velocity и story points для оценки.

Почему даже подробные требования не гарантируют точную оценку сроков?

При разработке IT-продуктов даже детальные требования не могут предусмотреть все нюансы. В отличие от классического проектного управления, Agile-разработка происходит в условиях постоянных изменений. Команда регулярно сталкивается с техническими сложностями, изменением требований и другими факторами, которые влияют на сроки разработки.

Хотите системно изучить гибкие методологии?

Cертифицированный Скрам-мастер и Agile-coach

27 - 29 августа 2025
Узнать больше

Профессиональный сертификационный тренинг по Agile и Scrum

24 - 26 сентября 2025
Узнать больше

Сертифицированный Владелец продукта в Agile

01 - 03 октября 2025
Узнать больше

Полный календарь тренингов

Перейти к расписанию

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

Выбор пилотной команды для внедрения Agile
Публикация Agile, Scrum, Kanban–метод

Выбор пилотной команды для внедрения Agile

С какой команды лучше начать пилотное внедрение Agile? Давайте подумаем, какая команда была бы идеальной для эксперимента внедрения Agile.

Что такое Agile на самом деле? Разбираем на конкретных примерах
Публикация Agile, Scrum, Kanban–метод

Что такое Agile на самом деле? Разбираем на конкретных примерах

В этой статье мы погрузимся в мир Agile и рассмотрим его ключевые принципы, используя живые примеры и истории из реальной жизни. Согласно Agile Manifesto, в Agile "люди и взаимодействие важнее процессов и инструментов, работающий продукт важнее совершенной документации, сотрудничество с заказчиком важнее согласования условий контракта, а готовность к изменениям важнее следования плану". Но что это значит на практике? Давайте разберемся вместе.

Манифест Тестирования в Agile среде. В чем отличия от классического подхода к QA?
Публикация Agile, Scrum, Kanban–метод

Манифест Тестирования в Agile среде. В чем отличия от классического подхода к QA?

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

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

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

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

Managing Partner

+7 495 221 87 39

dmitry@onagile.ru

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