Как оценивать сроки задач не «навскидку», а точно: инструмент и практики от Kaiten
Статья о том, как перестать ставить сроки на глаз и перейти к грамотному планированию, когда команда не выгорает, а проект завершают вовремя. Разбираемся, почему сорванные сроки — это обычно не вина разработчиков, а ошибочное планирование ресурсов и дедлайнов.
Почему сроки срывают: когнитивные искажения и системные ошибки
Ситуация: тимлид спрогнозировал, что команда выпустит обновление приложения через 3 месяца. Все хорошо — продуктовый маркетолог анализирует рынок, продакт-менеджер разрабатывает дополнения продукта, разработчики программируют. И все вовлечены, все выполняют свою работу на максимум и не саботируют задачи.
Но вот приходит время релиз и… обновление не выходит — оно появится у пользователей только через 2 месяца после оговоренной даты, инвесторы негодуют, команда остается без премии.
Почему так? Тимлид ошибся в постановке конкретных сроков. И даже усердная работа команды не спасла релиз — обновления вышли позже на 2 месяца.
Что приводит к некорректной постановке сроков:
- Излишне оптимистичные прогнозы, optimism bias. Важно смотреть на реальные данные и верить им, а не своим оптимистичным ожиданиям и историям успеха. Да, Стив Джобс заставлял свою команду укладываться в рекордные сроки, но не каждый из нас Стив Джобс, и не каждый готов сталкиваться с диким выгоранием команды.
- Неравномерное распределение нагрузки. Это «эффект студента», когда команда откладывает самые сложные задачи на «потом». Подобное приводит к прокрастинации и затягиванию сроков. Ответственность руководителя — грамотно распределить нагрузку между этапами и сотрудниками на этапе формирования бэклога.
- Последствия прошлых проектов/спринтов. Если команда завершила проект с переработками, то стоит снизить темп на первых этапах разработки нового продукта, заложив время на «разгон».
- Технический долг с прошлого проекта. «Отработка» техдолга будет занимать ежедневное время команды. Важно заложить это в срок нового проекта, работа над которым будет вестись параллельно с закрытием долгов.
- Некорректное буферное время. Важно заложить около 10-20% буферного времени, которое команда может использовать в непредвиденных обстоятельствах. При этом делать запас времени не должен быть больше 20%, иначе команда начнет снижать ритм работы.
- Снижение сроков под давлением стейкхолдеров. Несмотря на власть инвесторов и ЛПР, тимлид должен доносить до стейкхолдеров реальные сроки, а не те дедлайны, которые видятся руководству.
Как удовлетворить ожидания всех сторон — от разработчиков до стейкхолдеров, читайте в статье по ссылке.
Главная причина переоценки сроков и ресурсов — это, как правило, человеческий фактор, который устраняется, если руководитель опирается на реальные данные, а не свое мнение и настрой, при оценке сроков.
Одна проблема на всех: почему все отделы рискуют сорвать сроки?
Разные отделы занимаются разными задачами. Маркетинг выпускает PR-статьи, разработчики — обновления для приложения, HR-отдел подбирает кандидатов, а юристы следят за правовой «чистотой» компании. Но есть кое-что общее между этими командами — некорректная постановка сроков одинаково губительна для проектов во всех отделах.
В маркетинге сроки могут растягиваться из-за зависимости от внешних факторов. Например, редактор запланировали выпустить статью в СМИ в понедельник, но эксперт утвердил ее только в среду.
Разработчики имеют большое количество «unknown unknowns» — заранее неизвестные факторы, которые могут возникать в процессе разработки.
Например, команда девелоперов может развернуть новое решение на облачном сервисе, но не учесть лимиты на одновременное подключение баз данных. Это приведет к падению сервера и остановит разработку на неопределенное количество времени.
Сроки в рекрутинге могут срываться из-за болезни или неожиданных отпусков кандидатов или тимлидов, которые должны присутствовать на некоторых этапах отбора.
Несмотря на разноплановые проблемы департаментов, команды могут использовать проверенные практики и гибкие инструменты, которые существуют на рынке и подходят для всех типов команд.
Обзор проверенных подходов, как прогнозировать сроки
Разберем несколько проверенных способов оценить сроки проекта.
Важно: лучше использовать сразу несколько методов планирования, чтобы сочетать интуитивные и статистические способы, а также учитывать человеческие и аналитические данные.
Planning Poker. Популярный среди Agile-команд метод оценки задач. Как он устроен:
1. При покерном планировании несколько экспертов команды собираются в одном помещении.
2. Ведущий раздает им по набору карт, каждая из которых обозначает количество часов для выполнения задачи.
3. Каждый участник выдвигает карту с тем значением, которое по его мнению соответствует необходимому времени на задачу.
4. Владельцы минимального и максимального значения объясняют свои оценки.
5. По итогу обсуждения команда приходит к единой оценке.
⭢ Еще больше про покерное планирование можно прочитать в статье Kaiten и Product Lab.
Delphi-метод. «Дедушка» распространенного сегодня покерного планирования. Но в отличие от Planning Poker, Delphi-метод — анонимное голосование за сроки при оценке сложности задачи с последующим обсуждением и усреднением значений.
PERT (Program Evaluation and Review Technique). Это принципиально другой способ оценки сроков. Вместо угадывания времени он опирается на изучение трех возможных сценариев:
- Оптимистичный (О) — минимальное возможное время при идеальных условиях работы над проектом.
- Пессимистичный (Р) — максимальное время, которое включает всевозможные задержки.
- Наиболее реалистичный (М) сценарий при обычных условиях работы.
Время (Т), которое закладывает в итоге команда на работу, вычисляется по формуле:
Story points, или размеры футболок. Story points — это метод командной оценки сложности задачи. С помощью него команда оценивает объем усилий, которые предположительно может потребовать выполнение проекта или задачи.
В некоторых проектах эквивалентом объема служат размеры футболок, чтобы все участники оценки имели общее представление о единицах измерения сложности.
Подобное «футболочное» обсуждение может проводиться как офлайн, так и онлайн. В Kaiten есть поле «Размер »в каждой карточке задач для оценки сложности предстоящей задачи. Как это выглядит:
Также в Kaiten можно установить WIP-лимиты не только на количество задач в работе, но и на их размер:
Это помогает эффективно распределить нагрузку на каждого сотрудника и избежать ситуации, когда один разработчик выполняет 5 задачи размера L, а другой 6 — размером XS.
Historical data. Метод, который требует анализа прошлых завершенных проектов/спринтов команды. На основе сбора статистики руководитель оценивает сроки грядущих проектов. Разберем подробнее на примере разработки:
- Тимлид смотрит фактические сроки выполнения задач в прошлых проектах. Найти их можно в таск-менеджерах, таблицах и других системах планирования.
- Помимо времени он учитывает: story points, число багов и их исправлений, доработок, блокировки задач из-за внешних обстоятельств.
- Оценивает скорость работы команды с помощью графика Velocity или подсчета story points за определенный период.
- Выявляет типовые риски, которые повторяются из раза в раз, и закладывает время на них.
Например, прошлые 5 спринтов команда в среднем выполняла объем задач в 70 story points. Размер следующего проекта разработчики оценили в 100 story points. Значит, тимлид закладывает на 30% времени больше на следующий спринт. Также он добавляет еще 5%, чтобы учесть возможные риски задержек.
Или после выпуска обновления команде приходится исправлять около 20% функций, что занимает 5-7 дней. Тогда при планировании сроков руководитель может добавить 6 дней на доработку релиза.
Как современные инструменты превращают примерные оценки сроков в точный прогноз
Сегодня тимлиду уже не обязательно бегать по кабинетам между разработчиками и спрашивать, во сколько поинтов они оценили бы задачу, сколько у них уходит времени на исправление бага, какие риски они наблюдают в процессе работы.
Команда может оценивать сроки и объем задач внутри систем планирования и таск-менеджеров. Рассмотрим на примере Kaiten, как это можно делать удобно и быстро.
Визуализация. Kaiten — это система управления проектами, где команда может визуализировать все процессы работы. Это помогает руководителю одним взглядом оценить, какой объем задач сейчас у команды в работе, на каком этапе каждое поручение.
Выше мы уже рассказали, как команда может оценить размер задачи на этапе бэклога. Также сотрудники могут использовать систему рейтинга и оценки с помощью звезд, а не только размера. Все данные отобразятся на фасаде карточки, чтобы тимлид быстро оценил мнение команды о грядущем проекте.
Настраиваемые доски. Система Kaiten — гибкий таск-менеджер для управления проектами в разных сферах. Kaiten одинаково удобно используют маркетологи, разработчики, рекрутеры, производители, строительные компании и другие сферы бизнеса.
Все кейсы, как компании используют Kaiten для прозрачного отображения процессов, прогнозирования сроков и аналитики работы команды, вы можете прочитать в разделе «Кейсы».
Блокировки. В Kaiten сотрудник может заблокировать карточку с задачей, если ее выполнение остановилось по внешней причине. Например, маркетолог не может выпустить материал без согласования эксперта или ответственный исполнитель ушел на больничный.
Или карточка может быть заблокирована, если предыдущая необходимая задача не выполнена.
В конце отчетного периода руководитель может увидеть число блокировок, их время и причины в автоматическом отчете Kaiten.
Автоматическая аналитика работы команды. В Kaiten есть десятки отчетов, которые система собирает автоматически. Рассмотрим некоторых из них, которые могут быть полезны при оценке сроков проекта.
→ Velocity. Необходимый отчет для scrum-команд. Показывает, какой объем задач команда может выполнить за спринт, что помогает прогнозировать последующие периоды работы.
→ Cycle Time. График отражает время, которое находилась карточка на определенном этапе.
→ Контрольный график. Показывает, сколько задач были выполнены после срока, и оценить причины их задержки.
Диаграмма Ганта. Kaiten автоматически просматривает диаграмму Ганта при подключении модуля «ГАНТ и ресурсное планирование». В бесплатной версии системы есть ее упрощенный аналог — таймлайн.
В планировании сроков диаграмма Ганта помогает распределять время между каждой задачи. При этом если сотрудник меняет даты в диаграмме Ганта, они автоматически меняются в соответствующих карточках. И наоборот — изменения сроков в карточках отражаются на диаграмме.
Kaiten сам отметит просроченные задачи и визуализирует ответственных исполнителей. Руководитель может добавить вехи проектов и связи между задачами.
Резюме: 3 ключевых фактора постановки корректных сроков
Точная оценка сроков проекта состоит из 3 ключевых компонентов:
- Сбор данных о работе команды и совместное прогнозирование. Чтобы корректно оценить сроки грядущего проекта, важно обратить к опыту и мнению команд, которая будет воплощать этот проект.
- Правильная методика оценки. Для корректного прогнозирования сроков лучше использовать несколько методов. Например, сочетать интуитивное покерное планирование с аналитикой исторических данных за прошлые спринты.
- Современные инструменты. Времена ручного сбора информации прошли. Сейчас на российском рынке множество инструментов планирования, которые помогут руководителю и команде визуализировать процессы работы и проанализировать завершенные задачи для точного прогноза выполнения будущих поручений.
Сочетание этих элементов превращают интуитивную оценку сроков в корректный прогноз и снижают риски выхода за сроки и бюджета проекта.