User Story Mapping как метод приоритизации бэклога продукта

Привет, я Андрей, в роли Product-менеджера развиваю b2b-продукты в Совкомбанк Технологии.

Вы читаете адаптированный перевод статьи What is Story Mapping Feature Prioritization? Overview, Guide, Examples, and Template от компании Savio, B2B SaaS платформы для работы с обратной связью пользователей.

Статья является частью полного гайда  «Построение и приоритезация RoadMap продукта».

Этот материал отлично дополняют:

• 14 маркетинговых стратегий продвижения Tech/IT-компаний, от компании Breadcrumbs
• Метод персон: что это такое и как с его помощью сегментировать целевую аудиторию
• Идеальная дорожная карта продукта (Product Roadmap) в Tech/IT-компании, от HubSpot

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

Представьте: у вас огромный бэклог продукта, и вы ищите способ пересобрать его, чтобы найти самое важное. Что вы будете делать?

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

Вот как работает этот инструмент и что о нем нужно знать 👇

Основные факты про User Story Mapping

• User Story Mapping — техника совместной визуальной работы (visual and collaborative technique), которая помогает приоритизировать функционал или определить MVP (минимально жизнеспособный продукт). Популярный метод среди agile/scrum-фреймворков.
• Благодаря визуальному представлению пути пользователя, целей на каждом шаге, вы сможете упорядочить и сформировать понимание, как пользователи действительно используют ваш продукт.
• Для команды продукта, карта помогает понять, с какими барьерами сталкиваются пользователи, а также определить приоритет новых фич, которые улучшат пользовательский опыт.
• Единственный недостаток инструмента в том, что построение карты может отнимать много времени и привести к тому, что вы будете отдавать приоритет функциям, которые уже не соответствуют потребностям и целям.

Развитие и история User Story Mapping

Есть разные варианты визуализации пути пользователя, такие как карта пути клиента (customer journey mapping) или карта взаимодействия (experience mapping) — все это визуальное представление шагов, которые пользователь совершает при взаимодействии с продуктом, услугой или системой. Для команды продукта такие инструменты помогают понять потребности пользователей, болевые точки и даже эмоции на каждом этапе взаимодействия. Это помогает разрабатывать более эффективные решения и оптимизировать общий пользовательский опыт.

Джефф Паттон, один из первых пропагандистов инструмента User Story Mapping, пришел к его использованию, потому что идея «плоского» бэклога (flat backlog), которая использовалась чаще всего, не имела для него смысла. Он утверждает, что плоский бэклог (flat backlog) упускает важный контекст, т.к. отрезан от полного взгляда на всю систему и действия пользователей.

Что такое пользовательские истории (user story)?

Пользовательские истории (user story) — это описание функции или задачи дизайна пользовательским языком. Чаще всего, они имеют следующий формат: 

«Как [тип пользователя], я хочу [действие], чтобы [достичь цели]».

Например, user story для корзины в интернет-магазине может быть такой: «Как зарегистрированный клиент, я хочу добавить разные товары в корзину, чтобы иметь возможность приобрести все товары одновременно».

Что такое карта историй (story map)?

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

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

Это пример User Story Mapping. Она разделена на действия, шаги и детали

Карточки представляют три уровня детализации:

• Действия (Activities) — это основные действия, которые пользователи выполняют при использовании вашего продукта. Например, в СRM-системе одно из действий может быть «управление продажами». В этом случае, пользовательская история для этого действия может звучать так: «Как директор B2B SaaS-компания, я хочу иметь возможность отслеживать наши сделки по продажам и доходы».
• Шаги (Steps), также называемые «задачи» — это более мелкие истории, связанные с действием. Для CRM-системы в рамках действия «управление продажами» задачами могут быть «создание счетов-фактур», «учет платежей клиента» и «напоминание клиентам о просроченных счетах». В Agile-методологиях разработки такие шаги часто являются «эпиками» для команды.
• Детали (Details), также называемые «подзадачи» — это еще более мелкие части внутри задачи. Например, для задачи «создание счета-фактуры» в CRM-системе, подзадачами могут быть «редактирование даты», «изменение цен», «расчет налогов» и так далее.

В процессе построения карты историй (story map), все подзадачи (details) вы распределяете по задачам (steps), а задачи по видам действий (activities). Не забывайте, также компоновать истории (и соответствующие им задачи, подзадачи) в том порядке, в котором пользователь обычно их выполняет.

В результате получается своего рода «скелет»: в верхней части находятся основные действия, которые пользователи выполняют с вашим продуктом, а ниже — связанные задачи и подзадачи.

Вместе они составляют целую систему, которая представляет ваш продукт.

Паттон описал получившуюся карту как своего рода скелет, где «ребра» (шаги и детали) свисают с «позвоночника» (действий)

Как построить User Story Mapping — пошаговое руководство и примеры

Карты историй (Story mapping) — это ценный инструмент, который поможет визуализировать и распределить приоритеты функционала на основе целей и опыта пользователей. Вот пошаговое руководство по построению User Story Mapping 👇

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

Вы также можете использовать любые онлайн-доски, такие как: Miro, FigJam или Российские аналоги от крупных корпораций: Контур Толк Доски, Яндекс Доски, МТС Линк Доски, VK WorkSpace Доска, Unidraw (от Т-Банка) и др.

Первую версию советую собирать с помощью стикеров и маркеров, а для оцифровки сервис найдется 👌

Шаг 1: Соберите команду для работы

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

Совет: Ориентируйтесь на группу из 4 – 8 человек. Вы также можете сделать все в одиночку, но вы не получите такого же качества и пользы, которую можно получить от совместной работы.

Шаг 2: Определите портреты пользователей и их цели

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

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

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

Шаг 3: Определите действия, задачи и подзадачи

Здесь вы определяете, какой функционал будет у вашего продукта и что он делает.

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

Шаг 4: Постройте карту историй вашего пользователя

Распределите истории пользователей на своей карте.

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

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

В результате вы должны получить визуальное представление о том, как пользователи используют ваш продукт.

Шаг 5: Планируйте релизы

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

Если вы построили карту по нашему примеру, то вы можете провести горизонтальные линии по всей доске, чтобы определить функционал каждого релиза. Вверху будут расположены, самые важные функции, которые будут входить в ваш минимальный жизнеспособный продукт (MVP). Функционал ниже можно отложить на будущие версии.

Пример карты с планами релизов. В этом примере функции ранжированы по приоритетности выпуска

Шаг 6: Смотрите и корректируйте

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

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

Когда стоит использовать story mapping?

Для планирования MVP: Чаще всего считают, что построение карты пользователя особенно полезно, когда вы формируете состав фичей, которые должны стать частью минимально жизнеспособного продукта .

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

Преимущества приоритизации через story mapping

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

Потребности пользователя (Customer-centric)

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

Контекст (Context)

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

Улучшенная коммуникация в команде (Improved communication)

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

Упрощенная система планирования (Simplified planning)

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

Адаптивность (Adaptability)

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

Подводные камни и как их избежать

Мы рассмотрели преимущества использования User Story Mapping, но как у любого инструмента, здесь есть свои нюансы и подводные камни, о которых вы и команда должны знать заранее.

1. Необходимость глубокого исследования пользователей

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

Как избежать этого: Будьте уверены, что хорошо познакомились со своими пользователями, услышали их голос (voice of your customer). Для этого можно использовать следующие методы:

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

2. Избыточный акцент на пользователях

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

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

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

3. Временные затраты

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

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

Альтернативные методы приоритизации

Если вам не нравится или не подходит приоритизация User Story Mapping, то не волнуйтесь, есть много других методов приоритизации, которые вы можете использовать вместо него. Вот несколько из них:

• Модель ICE (Impact, Confidence, Ease). Метод оценки ICE основывается на приоритизации функций на основе 3-х параметров: эффективность (Impact), вера в успех функции (Confidence) и простота реализации (Ease).
• Матрица ценности и усилий (Value x Effort matrix). Упрощенная версия метода ICE, которая не учитывает веру в успех. Я не люблю этот вариант — думаю, что лучше использовать ICE.
• Модель RICE (Reach, Impact, Confidence, Effort). Близкий родственник ICE. Отличие в том, что помимо эффективности (Impact) вы также оцениваете охват функции. Вместо простоты реализации (Ease), оцениваются усилия на реализацию (Effort), поэтому формула меняется.
• Взвешенная оценка (Weighted Scoring). Похожа на ICE, RICE и Value x Effort, но считается более гибким вариантом, поскольку позволяет включать в оценку любые факторы, которые вы хотите.
• Метод MoSCoW. При оценке метод предлагает делить функции на 4 группы: обязательно должны быть (Must have), желательно должны быть (Should have), возможно будут (Could have) и могли бы быть (Would have). Я не считаю метод полезным, но некоторым командам он нравится.
• Метод Кано. Этот метод распределяет функции по категориям в зависимости от того, как они влияют на пользовательский опыт. Мне нравится, что он ориентирован на пользователя, но для правильной реализации требуется много работы.
• Метод Savio. Наш собственный метод, который мы используем. Если кратко, то вы отслеживаете, о чем просят пользователи, и сопоставляете эти запросы с другими данными (например, MRR — регулярный ежемесячный доход). Затем вы можете определить приоритетность функций в RoadMap, которые лучше всего соответствуют вашим бизнес-целям.

Заключение и шаблоны

Карты пользовательских историй (User Story Mapping) — это эффективный и универсальный метод, который помогает командам визуализировать продукт, определять приоритеты и планировать релизы на основе опыта пользователей. Этот метод широко распространен в Agile-командах.

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

• Начните с глубокого понимания потребностей пользователей (можете позвать их для построения карты).
• Убедитесь, что не забыли оставить время для работы над задачами технического долга и стратегических бизнес-функций.
• Если это первая итерация работы над картой, убедитесь, что ваша команда понимает весь процесс и знает, сколько времени потребуется инвестировать.

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

Хотите попробовать на практике? Начните приоритизировать бэклог продукта на основе бесплатного шаблона от Savio. Или начните с построения своей первой карты в нашем инструменте от Savio.

Еще сомневаетесь? Справедливо изучите все варианты приоритизации и выберите подходящий для вашей команды и продукта 👌

С вами был Андрей Попов, продакт-менеджер Совкомбанк Технологий 🚀 Сохраняйте гайд от Карима Майана, чтобы всегда помнить о методе User Story Mapping, структурировать идеи и отдавать приоритет тем фичам, которые пользователи действительно будут ценить.

Для меня User Story Mapping — это один из основных фреймворков, чтобы не забывать о ценности и пути пользователя. Для приоритизации бэклога я использую метод RICE, который позволяет учитывать не только ценность для пользователя, но и охват, веру в успех и ресурсы на запуск. Такой подход помогает не только отвечать потребностям пользователей, но и эффективно использовать ресурсы команды.

User Story Mapping — это не просто инструмент, а способ мышления, позволяющий держать фокус на пользователе и создавать продукты, которые действительно приносят пользу. Если у вас появились вопросы или нужна помощь с развитием продукта, на связи! 👋