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

Как мы в WEEEK перепрошили приоритизацию и вернули здравый смысл в продуктовую разработку.

В один момент наш бэклог стал похож на бардак: фичи спорили с багами, баги спорили с хотелками клиентов, а команда спорила друг с другом. Работали много, но ценность двигалась медленно.

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

Их мы совершили немало:

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

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

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

Расскажу о каждой ступеньке подробнее.

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

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

От приоритизации ценности выстраиваются приоритеты обоих бэклогов.

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

Что даёт такой бэклог?

Ценность для бизнеса. Выручка, или ARPA, удержание, LTV и маржинальность. Когда команда создаёт ценный продукт, метрики перестают прыгать, а бизнес начинает расти предсказуемо.

Ценность для пользователя. Приоритизация помогает быстрее закрывать Jobs-to-Be-Done, а значит — снимать боль и повышать любовь к продукту.

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

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

Далее прописываем субъект ценности — конкретный сегмент аудитории.

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

И — границы. Чего точно не делаем.

В задачах бэклога ценности уже есть подтверждённая проблема, понятна причина и найдено проверенное решение. Но нет сроков и деталей реализации. Главное — есть внятный ответ на вопрос «зачем?». Только после валидации ценности начинается приоритизация: что сейчас берём в работу и из чего будет складываться дорожная карта.

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

Мы скорим ценность в гугл-таблицах по кастомизированному RICE с настроенными формулами. Приоритизируем в формате размеров — S, M, L, XL. Определяем объём задачи и добавляем повышающие коэффициенты, если это фича для фокусного сегмента. Итоговая оценка складывается из влияния на фокусные метрики, важности для целевых сегментов, масштаба проблемы и объёма усилий.

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

О нём дальше.

Бэклог поставки — очередь действий команды по доставке ценности пользователю. Отвечает на вопрос: как и в какой последовательности доставляем ценность?

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

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

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

А вот после валидации начинается «разбор на детали». Появляются конкретные задачи, которые уже уходят в бэклог поставки: API, фронтенд, бэкенд, аналитика и прочее.

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

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

У команды разработки своя пропускная способность — сколько задач на какой объём времени реально сделать. Это обсуждается на встречах.

Также в бэклоге поставки лежат баги.

Итого в бэклоге поставки система приоритизации определяет очередь. Задачам присваивается оценка по времени и внешний сигнал приоритета:

• красный — высокий приоритет, делаем в первую очередь
• жёлтый — средний, идёт по очереди
• зелёный — низкий, ждёт очереди

Это помогает набирать задачи в ближайший спринт на каждого разработчика.

Первое — прозрачность

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

Второе — глубина

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

Третье — логика в структуре команды

Под конкретные ценности можно собирать отдельные команды. Так работает подход Team Topologies. По нему одна команда отвечает за активацию, вторая — за баги и стабильность, третья ускоряет остальных. Команды взаимодействуют друг с другом, чтобы ускорить разработку и поставку ценности

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