​​Как и зачем декомпозировать User Story — 21 шаблон

Давайте представим, что мы делаем некий MVP. На дискавери потрачено 3 месяца. Скоуп определен, дизайны отрисованы и требования подробно описаны. На разработку заложено еще 3 месяца. Катить на пользователей что-то меньшее, чем этот скоуп — бессмысленно. Например, зачем видеть список товаров, если корзины нет и оплатить невозможно.

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

…

Следующий кадр: прошло 3 месяца, продакт смотрит, что получилось.

А получилось, что параллельно делали всё, закопались и ни один сценарий целиком не успели.
Команда говорит, что показать промежуточный результат не могут и нужен еще 1 месяц.
А через месяц нужен еще 1 месяц.
В итоге через 5 месяцев сдают проект. И вроде бы всё по тз, но «не то».

«Программисты виноваты!» — скажете вы.
«Какое тз, такой и результат!» — ответят программисты.

Всем плохо: программисты без премии, продакт с кривым MVP, которое уже никому не нужно.

Можно ли было помочь и команде и продакту? — Да!

Очень часто в продуктовой разработке мы изобретаем водопадные процессы.
Долго и тщательно дискаверим, по мере уточнения требований предполагаемый срок деливери увеличивается.
В итоге пилим проект, размером в квартал/полугодие/год.
А чем дольше горизонт планирования, тем больше вероятность не попасть в оценки.

Поэтому есть простое решение, как лучше попадать в сроки и делать «то», благодаря более частой обратной связи:
Вместо долгого дискавери, мелко декомпозировать и начинать деливери.
А параллельно доделывать дискавери по другим частям.

Вот как мог бы выглядеть процесс разработки нашего MVP по спринтам:

0️⃣ — Для старта проекта нам нужно хоть какое-то описание первой функции. Быстренько дискаверим, как должен выглядеть список товаров. Пока пофиг на фильтры и поиск. И пофиг что будет не идеально. Посмотрим вживую, потом поправим.

1️⃣ спринт — разработаем список товаров без поиска и фильтрации. Параллельно будем дискаверить фильтры и поиск.
К концу спринта смотрим, как выглядит вживую список товаров. Даем команде обратную связь, чтобы учесть правки в следующем спринте, либо отложить их на конец.

2️⃣ спринт — приделаем фильтры и поиск. А дискавери работает на следующий спринт: как должна выглядеть корзина.

3️⃣ спринт — сделаем корзину и возможность добавлять туда товары. Параллельно дискаверим оплату.

4️⃣ спринт — сделаем процесс оплаты на моках, и только успешный сценарий, без корнер-кейсов, неудачной оплаты и возвратов.

…

И так далее — до момента, когда уже можно релизить.

Да, нет смысла катить на пользователя экран со списком товаров без возможности поиска.
Но есть смысл декомпозировать MVP на мелкие User Story не больше 2 недель в разработке. И одной из таких User Story может быть «видеть список всех товаров».

Так мы решаем сразу обе проблемы:

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

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

Я призываю продактов помогать командам декомпозировать User Story на более мелкие, даже если катить на пользователя еще рано.
Почитать больше можно в статье Кента Макдональда.