Автор статьи: Дмитрий Курдюмов

Участвовал в Аджайл-трансформациях в крупнейших компаниях в России (Альфа банк, МТС, Х5 retail group), с международным опытом в стартапе зарубежом

Меня зовут Курдюмов Дмитрий, я более 7 лет управляю ИТ‑командами и помогаю компаниям выстраивать эффективные процессы. Одной из самых частых проблем, с которыми сталкиваются команды, является неточность планирования сроков выполнения задач.

Разработчик говорит: «Это на пару часов». Проходит день, потом два, и выясняется, что в процессе работы всплыли интеграционные проблемы, тестировщики нашли баги, а кто‑то еще ждет согласования. В итоге задача, которую оценили в несколько часов, затягивается на несколько дней или недель.

Почему так происходит? Потому что абсолютные оценки в часах не работают. Они не учитывают неопределенности, возникающие в процессе работы:

  • Время на уточнение требований.

  • Ожидание обратной связи от аналитиков и заказчиков.

  • Время, потраченное на исправление неожиданных проблем.

  • Простои между передачами задач из одной команды в другую.

Как же тогда планировать и прогнозировать сроки выполнения задач?

Как прогнозировать сроки выполнения задач: три работающих подхода

1. Использовать статистику, а не экспертные оценки

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

Как это сделать:

  • Фиксируйте, когда задача была взята в работу и когда она реально была завершена (включая тестирование и релиз).

  • Отслеживайте не только время разработки, но и задержки, связанные с ожиданием ответов, согласованиями и релизами.

  • Разделите задачи по размеру (например, S, M, L, XL) и собирайте статистику по каждому типу.

Пример: если за последние три месяца 80% задач размера M выполнялись в течение 5–7 дней, то с высокой вероятностью новая задача аналогичного размера займет примерно столько же времени.

? Как автоматизировать сбор статистики?
Собирать такие данные вручную — долго и неэффективно. Поэтому я рекомендую использовать инструмент Aimger, который автоматически анализирует скорость выполнения задач, простои, задержки и формирует точные прогнозы на основе исторических данных. Aimger помогает командам и менеджерам получать объективные данные о времени выполнения задач, что делает планирование более точным.

2. Оценивать задачи не в часах, а в относительных единицах

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

  • Story Points (по ряду Фибоначчи: 1, 2, 3, 5, 8 и так далее).

  • Оценку в «футболках» (XS, S, M, L, XL).

Как это работает:

  1. Находим в бэклоге самую маленькую задачу, принимаем ее за 1 SP (или XS).

  2. Сравниваем другие задачи с ней и оцениваем их относительно друг друга.

  3. Планируем спринт и смотрим, сколько SP команда реально завершает за итерацию.

  4. Через 3–5 спринтов накапливается статистика, на которую можно опираться при планировании.

Таким образом, мы оцениваем не время, а сложность и объем задачи относительно других, что делает прогнозирование более точным.

Пример:

  • Задача A (1 SP) занимает 2 дня.

  • Задача B (3 SP) обычно занимает 5–6 дней.

  • Задача C (8 SP) может растянуться на 2–3 недели.

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

3. Использовать статистику выполнения прошлых спринтов

Если вы работаете по Scrum, можно анализировать, сколько Story Points команда выполняла в прошлых спринтах.

Как это сделать:

  • Фиксируйте скорость команды (Velocity) — среднее количество выполненных SP за спринт.

  • Учитывайте тенденции — если команда стабильно делает 30 SP за спринт, то планировать на следующий спринт 50 SP бессмысленно.

  • Анализируйте вариативность — насколько часто сроки отклонялись от запланированных, какие были причины.

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

Почему статистические оценки лучше экспертных?

  • Они учитывают реальность, а не субъективные ощущения.

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

  • Снижают стресс в команде — разработчики не боятся ошибиться в оценках, так как прогноз строится на данных.

  • Улучшают предсказуемость — заказчики и руководство получают более точные сроки поставки.

Какие выгоды дает такой подход?

  1. Прогнозируемость сроков вырастает до 90% — вы можете уверенно сказать заказчикам, когда будет готова та или иная задача.

  2. Улучшается качество планирования — больше никаких внезапных переносов сроков.

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

  4. Снижается напряженность в команде — разработчики работают в комфортном темпе, а менеджеры получают объективные данные.

  5. Более точные ожидания со стороны бизнеса — заказчики понимают, когда получат готовый продукт.

Вывод

Абсолютные оценки задач в часах — это иллюзия контроля. Они не работают, потому что не учитывают неопределенности.

Если хотите более точно прогнозировать сроки:

  • Используйте статистику завершенных задач, а не экспертные оценки.

  • Оценивайте задачи в относительных единицах (Story Points, футболки).

  • Анализируйте скорость выполнения задач в прошлых спринтах.

  • Автоматизируйте сбор данных с помощью Aimger, чтобы получать объективные прогнозы.

Этот подход делает планирование точнее, а работу команды — более предсказуемой.

Приглашаю на менторство

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

Больше полезных материалов по Agile, управлению командами и трансформации процессов — в моем Telegram-канале. Подписывайтесь! А также приходите на менторство.


Какие компетенции должны быть у современного продакта? Должен ли продакт выполнять функции проджекта, маркетолога и бухгалтера? Как разные компании трактуют роль продакт-менеджера? Обсудим это и многое другое на открытом уроке 6 февраля. Записаться

А также 24 февраля пройдет открытый урок, посвященный теме CJM — как она помогает строить отношения с клиентом. Поговорим об основных этапах касаний и о том, как улучшить пользовательский опыт. Подробнее

Комментарии (5)


  1. Mavenrad
    30.01.2025 17:05

    Было заявлено три подхода, но по факту всё про один - относительная оценка задач с корректировкой соотношений через статистику. Который нужно собирать через сервис, который вы рекламируете, так?))


  1. Rhbnbr
    30.01.2025 17:05

    Правильно ли я понимаю, что оценки каждой задачи дают все члены команды?
    Что бы оценить сложность задачи, нужно как минимум ее хорошо понять. Это требует времени. Если в команде, например, 5 разработчиков, то изучение задач может сильно затянуться.
    Еще вы говорите про сложность задач. Как раз время на выполнение задачи напрямую не связана с ее сложностью, если под сложностью понимать именно сложность. То есть задача может требовать нешаблонного решения, но если решение будет найдено, то реализация может быть быстрой.
    Еще стоит разделять время, требуемое на реализацию задачи и время на ее тестирование, так как есть задачи, которые можно быстро сделать, но тестирование может потребовать много времени, а может быть и наоборот.


  1. mst_72
    30.01.2025 17:05

    абсолютные оценки в часах не работаю

    Какое сильное утверждение.
    А T-Shirt оценка работает?
    То есть если новая команда (или новый человек в команде) скажет, что это L-задача - мы сразу получим точную оценку в отличие от того? если тот же человек скажет - примерно 5 дней?
    В статье было про сбор статистики. И про то, что "zero-shot" не слишком достоверен. Потому оценку в часах-стори-поинтах-размерах надо корректировать при помощи статистики, собираемой на протяжении не нулевого времени. И, внезапно, при статистической корректировке "абсолютные оценки в часах" на удивление заработают.
    Но это ж скучно? T-Shirt звучит круча часов? И явно ж открывает принципиально новую реальность и позволяет легче себя/методику продать... Ну а там кто проверять будет, что под капотом. Не правда ли?



  1. pravosleva
    30.01.2025 17:05

    Интересная точка зрения. Согласен почти со всем кроме некоторых моментов:

    Абсолютные оценки в часах не работают

    Но постойте, как же Принцип Доказательного Планирования от Joel Spolsky? Я думаю, оценивать в реальных часах конкретными людьми для последующего анализа - это нормально. Подробнее изложил здесь, если интересно - там есть идеи как вычислить, насколько обманет конкретный разраб, который сказал "Это на пару часов".

    С этим тоже не могу согласиться:

    если за последние три месяца 80% задач размера M выполнялись в течение 5–7 дней, то с высокой вероятностью новая задача аналогичного размера займет примерно столько же времени.

    А если процессы совершенствуются с течением времени? Мой контраргумент коротко: разные люди работают с разной комфортной скоростью, в любой момент времени статистика конкретного исполнителя может удивить - люди развиваются и деградируют, и это надо иметь ввиду.

    Согласен с тем, что необходимо вводить абстрактные критерии оценки сложности фичи (попугаи, пятибалльная система, футболки и т.д.) - зачастую сложность определяет комфортную скорость работы.


  1. JuryPol
    30.01.2025 17:05

    Опять очередное откровение от «помогателя в налаживании процессов». И опять про «майки».

    Когда на очередном промежуточном контроле заказчик или руководитель спросит про причины отставания на месяц, заметьте - на месяц, а не на пару трусов с вышитыми крестиком числами Фибоначчи, автор ему тоже начнет втирать про то, что думали обойтись тремя маленькими майками, а среди них затесалась одна большая и вот упс...? Нет, перейдет на такие сермяжные дни и недели.

    Ни один из этих профессиональных суетологов не смог мне объяснить, почему после 3-5 спринтов оценка в майках становится удовлетворительно точной (ха-ха - в майках и точной), а оценка в днях - нет. И уж тем более не признался, что вся эта ерунда ему нужна только для того, чтобы несколько месяцев его не могли вышибить пинками на мороз по причине внезапно открывшейся непригодности к реальной работе. 

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