Как управлять бэклогом продукта, а не быть его рабом

Учимся считать бизнес-ценность задачи и расставлять приоритеты.

cover-6102a72b99ee7108744021.jpg

Чтобы не утонуть в потоке задач, в первую очередь нужно выполнять те, которые помогут продукту быстрее «взлететь».

Как работать с бэклогом, приоритизировать задачи и искать точки роста продукта среди таких, казалось бы, одинаковых элементов — разбираемся вместе с Артемом Авладеевым, Chief Product Officer банка ВТБ.

Артем развивал продукты в финтехе (банки «Открытие», «Росбанк», «Россельхозбанк»), логистике и e-commerce, также консультировал компании «Лукойл» и «Работа.ру». Сейчас менторит перспективные IT-проекты в Preppy Incubator.

Что такое бэклог продукта

Бэклог — один из важнейших элементов продуктовой разработки. Фактически, это план работы над продуктом.

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

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

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

Также бэклог напрямую связан с: 

Бэклог продукта имеет три основных структурных элемента: 

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

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

Как работать с бэклогом спринта 

Бэклог продукта строится на месяцы вперед без конечного срока, задачи выполняются и добавляются. Он раскладывается на циклы разработки — спринты, которые обычно длятся от 1 до 3 недель.

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

По результатам спринта Product Owner анализирует результаты — это помогает прогнозировать скорость движения команды. В Scrum-подходе трудоемкость задач измеряется не в человеко-днях, а в стори-поинтах

Например, РО и команда запланировали выполнить 30 задач за спринт, но успели — 28. Это сигнал, что спринт был перегружен, и в следующий нужно взять 29 задач. 

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

Как расставляются приоритеты в бэклоге продукта 

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

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

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

Как рассчитать бизнес-ценность задачи 

Product Owner исследует целевую аудиторию, конъюнктуру рынка и рассчитывает бизнес-ценность задачи на основании этих данных. Например, что приоритетнее при разработке кроссплатформенного продукта: мобильное приложение или веб-версия? Новые фичи в приложении для iOS или Android? 

Недостаточно знать количество пользователей. Например, даже если аудитория на iOS — 100 000, на Android — 60 000, решение не очевидно. На бизнес-ценность может влиять платежеспособность разных аудиторий, конверсия в покупку услуг и т. д. 

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

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

Анализ показал: программу развернули для уже существующих клиентов, но в кризисный период у этой аудитории была другая потребность — рефинансирование старых кредитов. Только небольшая доля пользователей подала заявки на получение новых кредитов. Когда программу вывели на внешний рынок, упростив форму подачи заявки (например, добавили возможность экспорта выписок из другого банка), количество заявок выросло. 

Рекомендуем почитать:

img-credit-60c745e532a2a035699963.jpg

История кредита: от долгового рабства — до кредитной карты

Читать

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

Кто добавляет задачи в бэклог 

Источники наполнения бэклога:

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

На грумингах Product Owner обозначает приоритетные задачи и ожидаемые результаты. Команда может задавать уточняющие вопросы и важно, чтобы РО мог аргументированно ответить. Далее, по Scrum-гайду, команда сама принимает решения, как дойти из точки А в Б. 

Кто должен иметь доступ к бэклогу

Это зависит от оргструктуры компании. Например, в стартапе это только РО (зачастую он же — владелец бизнеса) и команда. В больших компаниях может быть много команд и руководителей бизнес-юнитов. И доступ к бэклогам команд нужен всем руководителям, а также Scrum-мастеру, для синхронизации. 

Например, компания развивает продукт, связанный с перевозками, и есть несколько направлений — такси, каршеринг, аренда велосипедов и электросамокатов. Chief Product Officer совместно с владельцем продукта каскадируют общую бизнес-цель — например, рост выручки в следующем квартале +200 млн рублей, по направлениям. 

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

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

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

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

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

Как Product Owner ищет точки роста продукта 

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

Например, РО прогнозировал, что фича привлечет 10 000 пользователей, а она «выстрелила» до 500 000. Необходимо понять, почему это произошло, и учитывать в бизнес-оценке следующих задач. Это помогает планировать дальнейшие шаги, снижает неопределенность. Выводы подскажут точки роста — зоны в продукте, улучшения которых влекут за собой значительный рост бизнес-показателей. 

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

Следующий шаг — рекламная кампания и плата пользователям за установку — увеличила фейковый трафик (когда приложение ставят, но не авторизуются) и пустой трафик (авторизуются, но не пользуются). То есть ценности фича тоже не принесла. 

Тогда Product Owner предложил добавить опцию «Приведи друга»: пользователям предложили отправить ссылки с приглашениями, и за каждого добавленного по рекомендации юзера платили деньги. Эта фича взлетела, потому что оказалось, что такая опция удобна двум категориям: семьям, где больше двух взрослых делают покупки, и работникам объектов (например, строительства). 

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