Как декомпозировать фичи

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

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

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

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

Во всех источниках используется разная терминология, здесь и далее под словом «фича» (от англ. feature) мы будем понимать полноценный блок функциональных возможностей системы, который в полной мере закрывает конкретную потребность клиента, а реализация предполагает определённый набор доработок (scope) и может быть ограничена во времени (time bounded).

Зачастую решить проблему пользователя мы можем только большой и сложной фичёй. У кого-то “большой” фича будет начиная от недели работы, у кого-то — от месяца или квартала.

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

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

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

В этой статье разберём декомпозицию фичей как базовый элемент MVP-first подхода в современном мире. С фокусом на высокую гибкость, скорость поставки ценности и упрощение работы команды.

🤔 Зачем мы декомпозируем?

Всё начинается с проблемы клиента. Именно её мы и хотим решить.

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

Это создаёт большое поле неопределённости, что порождает ряд сложностей:

• 🦄 Мы хотим проверить, сработает ли наша идея или нет, прежде чем инвестировать в неё — тот самый MVP-first подход
• 🧗‍♀️ Чем объёмнее и продолжительнее фича, тем сложнее контролировать и прогнозировать выполнение работы командой
• 🪁 Довольно витиеватая координация членов одной или нескольких команд, кто участвует в работе над фичёй
• и т.п.

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

Декомпозиция позволяет разложить фичу на более маленькие составные элементы, тем самым мы:

• 🧘 Снижаем когнитивную нагрузку на всех участников рабочего процесса
• 🤝 Договариваемся между всеми участниками о том, что и кто будет делать (здесь больше про роли, нежели про конкретных людей)
• 🛤️ Упрощаем планирование и контроль работы
• 😎 Облегчаем формирование оценок и попадание в сроки

📊 Популярные способы декомпозиции

В своей практике я встречал много подходов к декомпозиции задач: User Stories, Job Stories, Use Case Slices, одинаковые по размеру задачи, технические задачи (вида добавить API метод, создать таблицу в БД и пр.) и др.

Каждый из них имеет свою пользу и ценность, но концептуально можно выделить 2 вида:

• 🏗️ Горизонтальная декомпозиция от процесса исполнения
• ❤️‍🔥 Вертикальная декомпозиция от потребности пользователя

Разберём подробнее оба вида 👇

🏗️ 1. Декомпозиция от процесса исполнения (горизонтальная)

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

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

Дальнейшей декомпозиции не ведётся, т.к. распараллеливание на уровне платформ уже произошло.

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

❤️‍🔥 2. Декомпозиция от потребности пользователя (вертикальная)

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

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

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

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

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

🎖️ Что лучше: вертикальная или горизонтальная декомпозиция?

Вернёмся к сути бизнеса, про которую говорили выше:

Компания создаёт продукт, которым пользуются клиенты для решения своих проблем. За что клиенты платят деньги компании.

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

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

Что, в свою очередь, даёт команде ряд важных аспектов:

• 🧙 Позволяет команде лучше разобраться в продукте, который она создаёт и развивает
• 💚 Повышает ownership за продукт у каждого члена команды (степень восприятия продукта, как собственного), что повышает их вовлечённость в работу
• 🚌 Снижает Bus Factor в команде благодаря органическому процессу распределения знаний во время работы
• 🥏 Даёт возможность в любой момент работы над фичёй сделать что-то иначе, но всё равно достигнуть целей
• 🧑‍✈️ Потенциал делегировать лидирование кусочков достаточно опытным инженерам внутри команды, высвобождая время руководителя
• 👥 Не оставляет возможности не общаться друг с другом, тем самым ускоряя принятие решений и повышая их качество

При этом внутри каждый кусочек довольно удобно делить горизонтально — на небольшие подзадачи. Например, под конкретную функцию в команде (бэкенд, фронтенд или др.), разные шаги (создать таблицу в БД, реализовать API endpoint или др.) и т.п.

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

Как обычно, после того как мы декомпозировали фичу, её необходимо оценить и спланировать работы по ней 👇

🔢 Оценки и планирование работы

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

Команде всегда нужно грамотно выбирать, что делать в первую очередь и как получить результат быстрее. Чем лучше мы это сделаем, тем большее конкурентное преимущество обеспечим компании.

Для приоритизации работы исходя из потребностей клиентов нам, так или иначе, нужно:

• 💍 Понимание ценности — какую пользу конкретный кусочек принесёт клиенту
• 💰 Стоимости реализации — оценка от команды, сколько времени и денег уйдёт на все работы по этому кусочку

Отношение ценности к стоимости формирует коэффициент ROI (Return of Investmets). Чем выше ROI, тем более выгодным для нас будет кусочек и тем раньше его следует взять в работу.

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

Но в любом случае нам надо стремиться поставлять максимум ценности за минимально возможное время. О чём и поговорим далее 👇

🐢 Как получить результат быстрее?

В проектном управлении есть «Железный треугольник». Согласно ему, в любом проекте есть три ключевых элемента:

• 📆 Сроки (time)
• 💰 Ресурсы (budget)
• 🧺 Содержание (scope)

Они тесно связаны между собой. Если изменить один элемент, то придётся менять и два других, чтобы треугольник “сошёлся”. При этом внутри треугольника — качество, которое напрямую зависит от исполнения ограничений по каждому из этих трёх элементов.

Одно из следствий треугольника:

Вернёмся к результату работы команды.

Результат, в текущем контексте, — это новое ценностное предложение в нашем продукте, которое мы сделали доступным клиентам и теперь можем зарабатывать больше.

Имея множество независимых кусочков в рамках одной фичи, мы можем очень ловко и просто управлять скоупом по каждой из наших фичей:

• 🚀 Пуская вперёд самые ценные их части
• 🚯 Деприоритизируя или даже выкидывая всё остальное

Это позволяет получить максимальный результат быстрее, просто фокусируясь на том, что действительно важно. Например, исходя из ROI каждой части фичи.

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

Срезая или откладывая целые кусочки, мы высвобождаем значительный объём ресурсов и фокуса команды— тем самым получаем макрооптимизацию.

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

🔪 Как понять, что надо декомпозировать ещё сильнее?

Допустим, один элемент фичи получился слишком больши́м по итогу оценки.

Да, “слишком большой” — это довольно субъективная оценка, тесно связанная с контекстом команды. Но, так или иначе, это маркер, что потенциально что-то не так.

Хороший вопрос для проверки себя:

Мы точно готовы инвестировать, например, 1 мес. работы команды в этот элемент не имея полной уверенности, что он действительно решит проблему пользователей и принесёт нам прибыль?

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

Второй вопрос:

Мы можем сделать меньше, но сохранить при этом ценностное предложение для наших клиентов?

(другими словами: сделать меньше, но решить проблему клиентов)

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

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

Рассмотрим небольшой пример, как всё это может выглядеть на практике 👇

🧑‍🔬 Пример вертикальной декомпозиции

Допустим, мы делаем приложение, и нам нужно создать такую фичу (источник):

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

Результат опишем через критерии приёмки, чтобы сделать ситуацию более понятной:

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

Эта фича не очень большая, но команда не могла реализовать её за 1 спринт, т.к. у них были и другие фичи, над которыми они хотели поработать.

Команда решила посмотреть, сможет ли она поставить ценность клиенту, сделав только часть фичи.

Что развилось в такие мысли:

• Существующая ссылка в профиле ведёт непосредственно к загрузке обновления, и пользователи привыкли к этому поведению.
• Баннер на главной даст пользователям быстрее узнать про выход нового обновления и сразу обновиться. А это именно то, что нам нужно.
• Экран с примечаниями к обновлению несёт отдельную, независимую ценность для клиента и может быть сделан полностью обособленно.

Поэтому команда разделила эту фичу на несколько самостоятельных кусочков:

1️⃣ Добавить баннер о новом обновлении на главную, который ведёт себя так же, как и текущая ссылка в профиле

2️⃣ Создать раздел с примечаниями к обновлению и открывать его с баннера на главной и по ссылке из профиля

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

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

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

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

🏆 Популярные форматы описания задач

Наиболее частые форматы для описания задач при декомпозиции от потребности, которые я встречал:

1. User Story в каноничном виде
2. Job Story как элементы работы в формате Jobs to be Done

Рассмотрим кратко каждый из них.

1. User Story

User Story — это неформальное описание одной или нескольких функций программной системы. Истории записываются с точки зрения конечного пользователя системы (как внешнего, так и внутреннего).

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

Для формирования Истории необходимо понимать:

• 👨‍🎤 Кто будет нашим пользователем
• 🏰 Что он хочет получить
• 🪢 Какие есть для этого предусловия

Есть разные подходы для формулирования историй. В своём опыте я чаще всего встречал подход от Connextra:

• As a “role” I can “capability”, so that “receive benefit”
• Как “роль” я хочу/могу “возможность”, чтобы “выгода”

И чуть реже такие форматы:

• In order to “receive benefit” as a “role”, I can “goal/desire” (Cris Matts)
• As “who” “when” “where”, I “want” because “why” (метод “5W”)

Пример вертикальной декомпозиции, который мы разбирали выше, имел в основе именно User Story:

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

Подробнее про User Story можно прочитать в блоге у Алексея Арефьева.

2. Job Story

Job Story — один из артефактов подхода Jobs To Be Done (JTBD), который содержит описание потребности человека. В основе подхода JTBD лежит идея, что мы не покупаем продукты (товары, услуги), а нанимаем их для выполнения определённой работы.

Структура Job Story формируется следующим образом:

• When “situation”, I want “action/change”, so I can “outcome”
• Когда “ситуация”, я хочу “изменение”, чтобы “результат”

На примере кейса с обновлением, который разбирали выше, Job Story могла бы выглядеть так:

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

Прочитать подробнее про Job Story можно у Rocketyze.

🧠 Итоговая система

Итак, немного подрезюмируем всю систему.

В основе успеха компании лежит ценностное предложение продукта (или нескольких) для своих клиентов. Развитие этого продукта — основной драйвер роста.

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

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

При выработке решения для проблемы клиента попробуем максимально нарезать вертикально наши идеи на полностью независимые кусочки. Всё вместе с командой.

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

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

🪆 One more thing…

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

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

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

Это снижает когнитивную нагрузку при коммуникации, тем самым упрощая рабочий процесс.

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

🏄‍♂️ С чего начать

Посмотрите на бэклог своей команды и задайте себе 1 простой вопрос:

Каждый элемент бэклога несёт ценность для пользователей независимо от других?

Если вы не можете однозначно сказать «Да», то:

1. 🦖 Возьмите одну из последних фичей/проектов вашей команды. Главное, чтобы вы их уже завершили.
2. 🍰 Попробуйте перенарезать эту фичу по-новому с использованием вводных из данной статьи. Например, на каноничные User Story.
3. 👨‍👩‍👦 Привлеките к этому своего продакта и команду — расскажите им идею и предложите попробовать вместе.
4. 😉 Помните, что фича решает проблему клиента. «Создать таблицу в БД» — это не фича.

Если вы уже активно практикуете вертикальную декомпозицию от потребности, то:

1. 🦖 Возьмите несколько элементов бэклога вашей команды, которые команда поставила за последние 4 недели. В идеале не меньше 6–7 и разного размера, для большего разнообразия.
2. 🤔 Ретроспективно посмотрите на них и подумайте, насколько удачно их нарезали. В этом отлично подходят два вопроса:
   1. Если между элементами от одной фичи были зависимости, то можно ли было декомпозировать вертикально так, чтобы этих зависимостей не было?
   2. Точно ли всё, что вы сделали в рамках каждой фичи, было нужно для решения проблемы ваших пользователей? Может, можно было сделать меньше?
3. 👨‍👩‍👦 Не забудьте подключить вашего продакта и команду поучаствовать в этом обсуждении.
4. 🧑‍🎓 Учтите полученный опыт и дальше почивайте на лаврах более эффективно вертикальной декомпозиции.
5. 📆 Время от времени возвращайтесь к этой рефлексии. Мир активно меняется, нужно поспевать.

Тебя заинтересовали идеи из статьи и ты хочешь попробовать их в своей работе?

Я с радостью помогу применить всё в работе. Бесплатно. Просто напиши мне 👇

Хочу консультацию!

💎 Послесловие

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

То, о чём мы не знаем, обязательно станет для нас сюрпризом и окажет значимое влияние. Лишь вопрос времени, когда это произойдёт.

Осознавая это, мы можем минимизировать влияние на нас, за счёт вложений в то, чтобы делать дела и идти вперёд, но небольшими и достаточно безопасными шагами.

“Делать больше” не всегда означает “делать больше”.

Наоборот, чтобы действительно делать больше надо делать самое важное ровно в том объёме, который объективно необходим. И так в каждый момент времени.

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

Удачи 💫