Привет, Хабр! Меня зовут Денис Улизко, я CPO AoS (CRM для B2B в МТС). За время работы с цифровыми продуктами в России и за рубежом я заметил одну типовую для энтерпрайза проблему — слишком длинный цикл поставки фич. В среднем релиз занимает 4–6 спринтов. Попробуешь ужаться до двух — получаешь перегрузку ролей, возвраты и техдолг. Но решение есть. В этом материале расскажу, как переход на трехспринтовую модель позволил нам сократить Story Lead Time с 21,5 до 9,6 дней.

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

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

Фича за 2 спринта: Discovery + Delivery

Двухспринтовый подход мы опробовали на первой версии мобильной продажи в AoS. Нужно было вывести ее на прод как можно скорее, и этот вариант нам показался самым оптимальным. Цикл мы разделили на Discovery и Delivery. 

В первом спринте — Discovery — параллельно включались все ключевые роли:

• на первой неделе бизнес-аналитик собирал требования у стейкхолдеров, а архитектор проверял их на соответствие целевой архитектуре;

• на второй неделе системный аналитик превращал все это в спецификации, а дизайнер вместе с продактом тестировали мокапы на пользователях и вносили правки.

Во втором спринте шел этап Delivery. Сначала неделя на разработку — реализацию по БФТ, спецификациям и комментариям архитектора. Затем неделя на тестирование, где QA проверяли функциональность, искали баги и вместе с разработчиками их исправляли.

На бумаге схема выглядела идеально: всего два спринта от идеи до релиза. Но в реальности все оказалось куда сложнее.

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

Мы поняли, что за первую неделю собрать и согласовать БФТ почти нереально. В итоге при двухспринтовом подходе примерно треть задач срывалась из-за того, что перегруженные стейкхолдеры не успевали согласовать требования.

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

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

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

Фича за 3 спринта: Discovery + Discovery + Delivery

Трехспринтовый подход мы впервые применили, когда делали функциональность добавления представителей — она критически важна, потому что расширяет возможности маркировки и управления «представителем клиента». Для этого Discovery был разделен на два последовательных спринта, а Delivery остался под разработку и тесты.

В первом спринте Discovery работали бизнес-аналитик и архитектор. На первой неделе аналитик собирал требования у стейкхолдеров, а архитектор проверял их на соответствие целевой архитектуре и давал комментарии. 

На второй неделе требования возвращались к стейкхолдерам, правки согласовывались через встроенный инструмент Confluence и снова проходили проверку у архитектора. На выходе получалось согласованное и «провалидированное» БФТ.

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

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

Так нагрузка распределилась равномерно. Системный аналитик и дизайнер получили на вход более проработанное БФТ и архитектуру, поэтому переделок стало меньше. Бизнес-аналитику стало хватать времени на то, чтобы собрать и согласовать требования со стейкхолдерами. Артефакты на выходе стали качественнее. 

Для баланса нагрузки мы использовали дашборды из Confluence, показывающие нагрузку в SP на каждого сотрудника разных ролей на спринт. Это позволило управлять нагрузкой не только на команду, но и на роль.

Команды отметили, что работа стала прозрачнее. Объем задач не уменьшился, но снизился уровень стресса — стало понятнее, как движется Discovery и каковы шансы уложиться с Delivery в срок. 

Коммуникацию внутри мы выстраивали через встречи Pulse, которые проходили раз в спринт. На них обсуждали важные изменения в продукте и в процессе, а на Daily meeting уже выравнивались по новому формату работы. Со стейкхолдерами также проводили регулярные сессии, где рассказывали не только о прогрессе по задачам, но и об изменениях в процессах.

Также благодаря трехспринтовому подходу появилась возможность вести несколько историй параллельно: пока одна ждет согласований, над другой можно продолжать работу. Планирование стало предсказуемее, а риск техдолга заметно снизился.

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

Что на практике?

На практике получился парадокс. Два спринта дают быстрый старт, но на финише все буксует из-за возвратов. Три спринта выглядят длиннее, зато ценность до пользователя «доезжает» быстрее — исправлять почти ничего не нужно.

Мы замерили эффект: Story Lead Time сократился с ~21,5 до ~9,6 дней, то есть на 55%. Для команды это означает меньше хаоса и перегрузок, для бизнеса — заметно более предсказуемые релизы.

По нашему опыту, лучше сразу переходить на трехспринтовую модель. Чтобы у вас это получилось эффективнее, советую действовать так: 

• определить стори на третий спринт;

• нарезать задачи для BA + Arch на первый спринт;

• оценить на PBR задачи BA + Arch;

• нарезать задачи для SA + DSGN на второй спринт.

Тогда процесс выстраивается проще. В первом спринте команда делает BA и Arch, а также параллельно оценивает на PBR задачи для SA и DSGN. Во втором спринте выполняются SA и DSGN и проводится оценка стори для Dev и QA. В третьем спринте в работу берется сама стори, которую реализуют Dev и QA. 

А как у вас устроено планирование Discovery и Delivery? Удается втиснуть фичи в два спринта или тоже пришли к тому, что три надежнее?