Автор статьи: Дмитрий Курдюмов
Участвовал в Аджайл-трансформациях в крупнейших компаниях в России (Альфа банк, МТС, Х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 SP (или XS).
Сравниваем другие задачи с ней и оцениваем их относительно друг друга.
Планируем спринт и смотрим, сколько SP команда реально завершает за итерацию.
Через 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 бессмысленно.
Анализируйте вариативность — насколько часто сроки отклонялись от запланированных, какие были причины.
Когда у вас есть такие данные, можно с высокой точностью прогнозировать, что реально успеет сделать команда в следующем спринте.
Почему статистические оценки лучше экспертных?
Они учитывают реальность, а не субъективные ощущения.
Позволяют учитывать неопределенности, связанные с согласованиями, задержками и исправлениями.
Снижают стресс в команде — разработчики не боятся ошибиться в оценках, так как прогноз строится на данных.
Улучшают предсказуемость — заказчики и руководство получают более точные сроки поставки.
Какие выгоды дает такой подход?
Прогнозируемость сроков вырастает до 90% — вы можете уверенно сказать заказчикам, когда будет готова та или иная задача.
Улучшается качество планирования — больше никаких внезапных переносов сроков.
Экономия времени на оценку — команда не тратит часы на бесполезные обсуждения, а использует уже накопленные данные.
Снижается напряженность в команде — разработчики работают в комфортном темпе, а менеджеры получают объективные данные.
Более точные ожидания со стороны бизнеса — заказчики понимают, когда получат готовый продукт.
Вывод
Абсолютные оценки задач в часах — это иллюзия контроля. Они не работают, потому что не учитывают неопределенности.
Если хотите более точно прогнозировать сроки:
Используйте статистику завершенных задач, а не экспертные оценки.
Оценивайте задачи в относительных единицах (Story Points, футболки).
Анализируйте скорость выполнения задач в прошлых спринтах.
Автоматизируйте сбор данных с помощью Aimger, чтобы получать объективные прогнозы.
Этот подход делает планирование точнее, а работу команды — более предсказуемой.
Приглашаю на менторство
Я помогаю менеджерам разного уровня, CTO, CPO лидам разработки и менеджерам проектов выстраивать эффективные процессы в командах, оптимизировать планирование и улучшать предсказуемость работы.
Больше полезных материалов по Agile, управлению командами и трансформации процессов — в моем Telegram-канале. Подписывайтесь! А также приходите на менторство.
Какие компетенции должны быть у современного продакта? Должен ли продакт выполнять функции проджекта, маркетолога и бухгалтера? Как разные компании трактуют роль продакт-менеджера? Обсудим это и многое другое на открытом уроке 6 февраля. Записаться
А также 24 февраля пройдет открытый урок, посвященный теме CJM — как она помогает строить отношения с клиентом. Поговорим об основных этапах касаний и о том, как улучшить пользовательский опыт. Подробнее
Комментарии (15)
Rhbnbr
30.01.2025 17:05Правильно ли я понимаю, что оценки каждой задачи дают все члены команды?
Что бы оценить сложность задачи, нужно как минимум ее хорошо понять. Это требует времени. Если в команде, например, 5 разработчиков, то изучение задач может сильно затянуться.
Еще вы говорите про сложность задач. Как раз время на выполнение задачи напрямую не связана с ее сложностью, если под сложностью понимать именно сложность. То есть задача может требовать нешаблонного решения, но если решение будет найдено, то реализация может быть быстрой.
Еще стоит разделять время, требуемое на реализацию задачи и время на ее тестирование, так как есть задачи, которые можно быстро сделать, но тестирование может потребовать много времени, а может быть и наоборот.
mst_72
30.01.2025 17:05абсолютные оценки в часах не работаю
Какое сильное утверждение.
А T-Shirt оценка работает?
То есть если новая команда (или новый человек в команде) скажет, что это L-задача - мы сразу получим точную оценку в отличие от того? если тот же человек скажет - примерно 5 дней?
В статье было про сбор статистики. И про то, что "zero-shot" не слишком достоверен. Потому оценку в часах-стори-поинтах-размерах надо корректировать при помощи статистики, собираемой на протяжении не нулевого времени. И, внезапно, при статистической корректировке "абсолютные оценки в часах" на удивление заработают.
Но это ж скучно? T-Shirt звучит круча часов? И явно ж открывает принципиально новую реальность и позволяет легче себя/методику продать... Ну а там кто проверять будет, что под капотом. Не правда ли?
pravosleva
30.01.2025 17:05Интересная точка зрения. Согласен почти со всем кроме некоторых моментов:
Абсолютные оценки в часах не работают
Но постойте, как же Принцип Доказательного Планирования от Joel Spolsky? Я думаю, оценивать в реальных часах конкретными людьми для последующего анализа - это нормально. Подробнее изложил здесь, если интересно - там есть идеи как вычислить, насколько обманет конкретный разраб, который сказал "Это на пару часов".
С этим тоже не могу согласиться:
если за последние три месяца 80% задач размера M выполнялись в течение 5–7 дней, то с высокой вероятностью новая задача аналогичного размера займет примерно столько же времени.
А если процессы совершенствуются с течением времени? Мой контраргумент коротко: разные люди работают с разной комфортной скоростью, в любой момент времени статистика конкретного исполнителя может удивить - люди развиваются и деградируют, и это надо иметь ввиду.
Согласен с тем, что необходимо вводить абстрактные критерии оценки сложности фичи (попугаи, пятибалльная система, футболки и т.д.) - зачастую сложность определяет комфортную скорость работы.
agileguru
30.01.2025 17:05Если совершенствуются, вы увидите с течением времени. Статистику нужно смотреть по месяцам, и как раз отслеживать тренд.
я наверное явно не указал в статье, но лично я всегда делаю фокус на метриках целиком на фичу, а не конкретном исполнителе. Потому что важно понимать возможности всей команды статистически а не отдельного участника.
pravosleva
30.01.2025 17:05Но любую фичу разные люди делают за разное время. И оценивают по разному - для кого-то фича простая, для другого - несколько сложнее. Команда также может менять состав с течением времени. Как быть с этими фактами? Общая статистика здесь не прокатит, кмк
JuryPol
30.01.2025 17:05Опять очередное откровение от «помогателя в налаживании процессов». И опять про «майки».
Когда на очередном промежуточном контроле заказчик или руководитель спросит про причины отставания на месяц, заметьте - на месяц, а не на пару трусов с вышитыми крестиком числами Фибоначчи, автор ему тоже начнет втирать про то, что думали обойтись тремя маленькими майками, а среди них затесалась одна большая и вот упс...? Нет, перейдет на такие сермяжные дни и недели.
Ни один из этих профессиональных суетологов не смог мне объяснить, почему после 3-5 спринтов оценка в майках становится удовлетворительно точной (ха-ха - в майках и точной), а оценка в днях - нет. И уж тем более не признался, что вся эта ерунда ему нужна только для того, чтобы несколько месяцев его не могли вышибить пинками на мороз по причине внезапно открывшейся непригодности к реальной работе.
Кстати, для 7 лет на этом «швейном» производстве у автора довольно длинный послужной список. Пришло что-то в голову, что пора перестать явление под названием «чес» относить исключительно к шоубизу.
agileguru
30.01.2025 17:05Ну тогда расскажите почему оценка в часах лучше?
для меня - не важно в чем вы оцениваете по большому счету, важно то что вы смотрите статистически и уже берете факты за основу, а не прогнозы пальцем в небо, тем самым обманывая своего заказчика и перенося сроки из раза в раз.
JuryPol
30.01.2025 17:05Да пожалуйста...
Живете в реальном мире? Время на ваших часах не в носках или колготках показывается? Вышестоящие руководители сроки выполнения работ не в пеленках или памперсах устанавливают? А прогноз о сроках сдачи проекта требуют в днях-месяцах, а не еще в какой-нибудь мануфактуре?
Вы же профи! Гуру! Так имейте смелость выдать всем участникам процесса вменяемые оценки в реальных единицах времени. И от исполнителей "налаживаемых процессов" требуйте того же. Вводите коррекцию с учетом статистики по данной команде, можете даже попускать пыль в глаза "фибоначчами" и "покером". Но - говорите о реальных сроках по каждому спринту, по каждой фиче, по каждой задаче. И отвечайте именно за эти сроки. Принимая покорно плюхи за возможное непопадание в прогноз.
Понимаю, это сложно. Работать - всегда сложно. И "помогать налаживать процессы" - тоже сложно. Но зато если сдюжите...
agileguru
30.01.2025 17:05Так те же оценки попугаев они все равно переводятся так или иначе в сроки. Мы лишь статистически знаем какой обьем работы команда выполняет за спринт. За 2 недели, и можем прогнозировать следующие периоды. Но не просто часы которые кто то потратил, а сколько целиком команда завершила фичей в спринт. Именно завершила, а не просто поработала работу.
Либо мы знаем что задачи категории S завершаются в 85% случаев до 5 дней например в таком составе команды.
JuryPol
30.01.2025 17:05Ну и зачем тогда совершенно лишняя промежуточная сущность, если все равно все переводится "так или иначе в сроки"? Наукообразие для придания хоть какого-то смысла своему занятию поднять на ровном месте? Чтобы на голубом глазу заявлять, что мы, мол, научились исключительно точно измерять сложность работ в АйТи в майках и носках?
Fullthoughtless
30.01.2025 17:05Вакуумная статья. В продукте мудрые продакты/овнеры покивают головами, и сначала спросят, когда будет готово, а потом когда начнет подгорать станут выжимать календарный план и подписанную кровью оценку.
В аутсорсе наверно в лучшем случае покрутят пальцем у виска, но скорее всего пройдут мимо, чтобы не связываться.
А так все красиво, по Agile. И задачи, конечно, от проекта к проекту одни и те же. В принципе можно еще посчитать среднее количество времени, требуемое на ctrl-c/ctrl-v переноса кода из файла в файл.
garr1nch4
30.01.2025 17:05С этими оценками задач в предметах одежды, сторипоинтах и тому подобному замечен еще такой момент: в итоге это все сводиться к часам, но при этом всем приходится делать лишние приседания с конвертацией в уме.
Банально даже тут в статье пример и ты волей-неволей будешь это конвертировать:
Задача A (1 SP) занимает 2 дня.
Задача B (3 SP) обычно занимает 5–6 дней.
Задача C (8 SP) может растянуться на 2–3 недели.
Кажется, что оценки в майках служат совсем другим целям
gun_dose
30.01.2025 17:05абсолютные оценки в часах не работают
А потом:
Задача A (1 SP) занимает 2 дня.
Это то же самое, что сказать "оценки в сантиметрах не работают, поэтому будем оценивать в дюймах".
Разработчик говорит: «Это на пару часов». Проходит день, потом два, и выясняется, что в процессе работы всплыли интеграционные проблемы, тестировщики нашли баги, а кто‑то еще ждет согласования. В итоге задача, которую оценили в несколько часов, затягивается на несколько дней или недель
Разработчик говорит: «Это на пару сторипоинтов». Проходит день, потом два, и выясняется, что в процессе работы всплыли интеграционные проблемы, тестировщики нашли баги, а кто‑то еще ждет согласования. В итоге задача, которую оценили в несколько сторипоинтов, затягивается на несколько спринтов
Вместо того, чтобы пытаться точно оценить время выполнения каждой задачи, собирайте реальные данные о том, сколько времени занимает выполнение похожих задач.
Что-что-что? Я вижу фразу "сколько времени занимает"? А почему это вдруг времени, а не ткани, хлопка, или из чего там сторипоинты шьют?
Вместо того, чтобы признаться самим себе, что учёт всегда ведётся только во времени, проджект-менеджеры по всему миру изобретают новые названия для всего, что было придумано до них сто лет назад.
Единственная здравая мысль в вашей статье - это то, что задачи нужно оценивать, опираясь на реальные сроки выполнения похожих задач в прошлом. Если задача в прошлый раз заняла 20 часов, то будет столько же и в этот раз. Аналогично и со сторипоинтами - было 10 СП в прошлый раз, будет столько же и в этот. Но если разработчик ошибся и назвал вместо 20 часов 4, то он точно так же ошибётся и со сторипоинтами, назвав один вместо трёх.
И ещё, не надо спекулировать на том, что якобы точное прогнозирование в часах невозможно. Если у вас один сторипоинт занимает два дня, вы точно так же можете прогнозировать сроки в часах с квантом в 16 часов и у вас всё будет сходиться так же, как на сторипоинтах.
Rhbnbr
30.01.2025 17:05Мы спорим в чем измерять время, в часах или попугаях, трусах, майках...,
Но у меня возникает вопрос: а вообще зачем оценивать время выполнения задачи? Ведь стоимость проекта мы так не определяем.
Конечно, если аврал, можно поднапрячься, иногда можно (и нужно) чуть расслабиться.
Занимаясь прогнозированием по каждой задаче, мы тратим время и силы команды на бесполезную активность. Почему нельзя просто спокойно работать? Если руководство считает что за те же деньги может найти других, которые будут работать быстрее, пусть ищет, это его право.
Mavenrad
Было заявлено три подхода, но по факту всё про один - относительная оценка задач с корректировкой соотношений через статистику. Который нужно собирать через сервис, который вы рекламируете, так?))