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

И возникает закономерный вопрос — да что не так-то?

Годовое планирование

Прежде чем приступать к поиску ошибок в планировании, нужно сказать несколько слов о процессах в продуктовых командах в Альфа-Банке. 

Планирование состоит из нескольких этапов:

• на год;

• на квартал;

• на спринт.

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

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

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

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

• Если недооценить задачу, то команда не успеет ничего сделать.

• Если же ошибиться в большую сторону, то ресурсы будут простаивать и затраты на разработку окажутся завышены.

А теперь разберём, с какими трудностями сталкивается команда при оценке времени задач.

Ошибки при оценке трудозатрат

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

Вот наш Топ-3 ошибок, которые приводят к некорректной оценке:

• наслаивание задач друг на друга;

• потеря отпусков в команде;

• не учитывать особенности разработки фич.

Как можно избежать этих ошибок? 

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

• разработчики Java, iOS, Android;

• тестировщик;

• аналитик.

Как на квартальном планировании определить сроки для этой задачи? 

№1. Первый способ - определить созависимые процессы, спросить у всех участников оценку и слабые места в проекте. 

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

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

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

На конечную оценку могут влиять:

• возможность параллельной разработки;

• порядок интеграционного тестирования;

• зависимость внедрения в системах друг от друга;

• загруженность команды.

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

Тестирование и аналитику параллельно вести не получится, поэтому суммарно на эти этапы уйдет 3 дня. Итого получаем оценку в 4 рабочих дня.  

№2. Второй способ — берётся похожий выполненный проект за единицу измерения времени. И команда на основе своего опыта даёт оценку в новых единицах измерения. Конечно, этот способ основан на субъективных оценках участников и не учитывает изменения в процессах, но мы получаем достаточно хорошее приближение по будущим затратам сил разработки. 

Сделаем оценку проекта с баннером. Например, команда делала похожую задачу 3 месяца назад, тогда нужно было добавить баннер на другой экран. В то время проект занял ровно 1 спринт, с учетом задержек с тестированием и согласованием текста баннера, поэтому итоговая оценка - 14 дней. 

Что со всем этим делать?

После оценки одной задачи двумя методами команда получает разные результаты — 4 и 14 дней. Если результаты от методов разнятся (как в нашем примере), то это говорит о возможных трудностях при разработке и неучтенных проблемах. Нужно внимательно относиться к оценке времени.

Не думаю, что в задаче с баннером нужно закладывать максимальный срок разработки, так как низка вероятность повторения трудностей с тестированием и согласованием. Но и срок в 4 дня не учитывает рисков. На основе моего опыта, чаще всего закладывается 2-3 дня на возможные трудности. Итого получаем 6-7 дней, т.е чуть больше половины спринта.

Задержки на этапе согласований

Разработка проекта начинается задолго до самого программирования.

1. Сначала бизнес-заказчик генерирует идею нового функционала.

2. Задаче придается форма, считаются финансовые модели — стоит ли овчинка выделки? 

3. Когда бизнес требования сформированы, их верхнеуровнево оценивают, после чего начинается поиск ресурсов.

4. Проводят UX-исследование и получают необходимые согласования.

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

6. Составляется план разработки по спринтам.

7. Разработка.

8. Тестирование.

9. Повторные согласования.

10. Запуск.

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

Но самая фундаментальная ошибка — пропускать шаги или нарушать порядок, тогда сроки становятся непредсказуемыми. 

Например,  бизнес захотел увеличить продажи и подсчитал, что если показывать клиенту баннер, то ежемесячные продажи кредитных карт вырастут на 5%. Сразу сформировали задание - через месяц выпустить для клиентов доработку, проигнорировав 3 и 4 шаги. 

Началась работа:

• Команда взяла задачу в спринт и через 2 недели представила баннер на экране.

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

• Затем обнаружилось, что дизайн нового баннера не соответствует дизайн системе банка…

• Если сделать другой дизайн, то текст от маркетинга не помещается… Дата внедрения смещается на неопределенный срок. 

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

Самые непредсказуемые этапы связаны с согласованиями, так как мы не можем предсказать решения других людей. Если в проекте не согласованы юридические документы, не выполнены UX-исследования, не пройдена проверка отдела безопасности, то проект не выпускается без получения всех подтверждений. 

Иногда согласования занимают больше времени, чем сама разработка. И невозможно предсказать, что именно сегодня “палка выстрелит нам в ногу”. Из-за этой непредсказуемости затраты по времени на согласования закладываются в недостаточном объеме.

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

Как избежать?

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

Задержки на этапе аналитики

Следующий сложный этап для оценки – активная аналитика и составление списка задач для команды. 

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

Например, вернемся к проекту с баннером. Первичная оценка команды составляла 6-7 дней. На этапе активной аналитики оказалось, что внедрена новая система баннеров в мобильном приложении, всё управление ведется через новую админку. На консультациях с архитектором направления и тех.лидами нашлись новые подводные камни. И теперь команда оценивает разработку минимум в 3 недели и сроки сдвигаются. 

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

Не могу сказать, что другие этапы разработки легко оценивать, но в них нет большой степени неопределенности:

• Этап тестирования — можно точно оценить по количеству кейсов. 

• Сроки запуска предсказуемы, так как в Альфа-Банке шаг за шагом описаны процессы доставки нового функционала для клиента.

• Этап написания документации – по объёму изменений в сервисе аналитик может точно сказать сроки.  

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

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

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

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

Как избежать?

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

Задержки во время спринтов

Где чаще всего делаем ошибки в оценках спринта?

Хочется дать самый легкий ответ — на этапе разработки, неправильно распределяем задачи на спринты, но это не так. 

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

Новые таски сваливаются на команду как снег на голову, в любой момент. 

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

В идеальном скрам-мире такие задачи не берутся в спринт. Но мы живём в высококонкурентном мире бизнеса, и команда не может не взять срочные задачи. Можно сказать, что ничего страшного, пусть команда потратит 1-2 дня из спринта на срочную задачу, но из таких маленьких откусываний складываются смещения в датах разработки. Не нужно забывать, что мы все люди, и сложно переключаться между 3-4 параллельно идущими проектами.

Как избежать?

Никак.

Или нанять команду, которая будет заниматься внезапными тасками.

Оценка времени проекта — это искусство

Хочется верить, что есть какая-то идеальная методика, как не ошибаться и всегда делать проекты в срок, но серебрянной пули не существует. 

При оценке проекта, в первую очередь, нужно исходить из его сложности.

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

Для точной оценки нужно уменьшить неопределенность:

• спросить оценку длительности проекта у будущих участников;

• найти бутылочные горлышки в проекте — это может быть недостаток ресурсов, сложные согласования, отпуска и т.п.;

• организовать коммуникацию между командами;

• проверить, не нарушен ли порядок этапов разработки.

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

На этом всё. Если хотите что-то добавить или поделиться болью — пишите в комментариях, ваш опыт будет интересен.

Рекомендуем почитать [подборка от редактора]

• Арт-терапия и вялотекущая миграция с монолита

• У нас была стратегия и мы её придерживались: как подружить бизнес и DevRel, сохранив ментальное здоровье

• Как мы ведём требования к ПО: формализация

• Как мы ведём документацию рядом с кодом

• BPMN не в теории, а на практике

• Можно ли стать аналитиком, отучившись в онлайн-школе?

Также подписывайтесь на Телеграм-канал Alfa Digital — там мы постим новости, опросы, видео с митапов, краткие выжимки из статей, иногда шутим.