User story mapping инструкция по применению

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

→ Аудио-версию этой статьи вы можете прослушать на канале Listen IT

User Story Mapping (USM, карта пользовательских историй) – инструмент целостного проектирования продукта на основе пользовательского пути.

Для чего применяется USM?

• Для проектирования пользовательского опыта в продукте
• Для определения границ MVP (минимальной работоспособной версии продукта) и планирования релизов на базе пользовательского сценария
• Для формирования единого понимания пользователя у команды разработки и заинтересованных лиц

Как построить User Story Mapping?

Для построения USM вам потребуется:

• Инструмент визуализации: стикеры или электронный инструмент вроде Miro или Mural
• Владелец продукта и команда разработки
• Представление о пользовательском сценарии (если у вас уже есть построенный CJM – берите его за основу)
• 1-2 часа

Ваша задача — спроектировать по шагам действия пользователя в продукте на основе его реального сценария.

Еще 50 инструментов для владельца продукта

Описания продуктовых практик и подходов, сгруппированные по 7 темам

Темы: анализ рынка, сегментация, описание и исследование клиентов, проектирование решений, управление бэклогом, управление продуктом, метрики.

Рассмотрим USM на примере

Магазин цветов решил запустить сайт. Визуализируем опыт клиентов с помощью техники USM.

1. Расскажите историю клиента по шагам

Картинка с сайта: scrumtrek.ru

1. Сгруппируйте действия клиента в этапы

Картинка с сайта: scrumtrek.ru

1. Заполнение пробелов в истории (User Story)

Картинка с сайта: scrumtrek.ru

1. Приоритезируйте истории внутри каждого этапа пути

Картинка с сайта: scrumtrek.ru

1. Выделите релизы

Картинка с сайта: scrumtrek.ru

1. Насладитесь приоритизированным бэклогом

Картинка с сайта: scrumtrek.ru

Обратите внимание, что итоговый приоритет определяется сценарием пользователя. Мы идем слева направо, и только затем по версиям – ведь мы хотим принести больше ценности пользователю. А для пользователя, как правило, ценность тем выше, чем более полно наш продукт закрывает его сценарий.

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

Мы учим строить USM на тренинге «Владелец продукта: краткий курс выживания».

---

P.S.: Серию статей про продуктовые инструменты Роман Баранов и Дмитрий Кустов пишут, используя технику pair writing.

Подключайтесь к Telegram-каналу, где мы делимся практиками и опытом.

Уровень сложностиПростой

Время на прочтение7 мин

Количество просмотров15K

Что такое User Story Mapping?

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

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

Что такое User Story?

Пользовательская История — это описание какой-либо фичи продукта, рассказанное с точки зрения её пользователя. Буквально рассказ о том, как именно фича используется конкретным пользователем. Пользовательские Истории при описании функционала software продукта, ставят во главу угла именно пользователя.

При написании Пользовательских Историй зачастую используется следующая схема:

As a [type of user],
I want [some particular feature],
So that [some benefit] is received.

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

Как [тип пользователя],
Я хочу [описание какого-то действия],
Чтобы [описание цели].

При составлении Пользовательских Историй важно понимать какой уровень детализации Вам необходим. Например, следующая история это плохой пример:

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

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

• открыть сайт онлайн магазина

• найти нужный товар

• просмотреть его характеристики

• прочитать отзывы на него

• добавить его в корзину

• залогиниться для сохранения истории покупок

• ввести данные банковской карты

• оплатить

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

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

Как выглядит User Story Mapping?

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

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

Карта Пользовательских Историй, это метод визуального моделирования и планирования, поэтому для визуализации моей истории, я буду использовать сервис Miro (Online Whiteboard & Visual Collaboration Platform | Miro).

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

Картинка с сайта: habr.com

Каркас

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

Картинка с сайта: habr.com

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

То, что мы только что сделали, этот набор стикеров, из которых состоит наша история, называется Каркас (или Backbone, в зарубежной литературе). Именно он является основой Пользовательской Истории, и именно на него мы будем наслаивать остальные элементы, а именно генерировать мелкие истории в формате задач, а так же выделять части чего-то единого.

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

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

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

Картинка с сайта: habr.com

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

Но и это ещё не всё. Пока мы просто организуем наше представление о действиях пользователя. Мы прописываем саму историю. Однако, поскольку Карты Пользовательских Историй являются ещё и инструментом планирования задач, самое время про это и поговорить.

Задачи

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

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

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

В случае с моей картой, стикеры-задачи могут выглядеть так:

Картинка с сайта: habr.com

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

• все они имели схожую смысловую структуру

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

Итак, трюк следующий — помните схему, по которой составляются Пользовательские Истории: As a [user], I want [something], So that [achieve some benefit] А теперь немного изменим её, заменив общие термины на элементы карты:

As a [user],
I want [task],
So that [backbone element]

Моя схема написана на русском, так что, давайте, следуя этой схеме, попробуем составить несколько историй для разработчика:

1) Как клиент онлайн магазина, Я хочу использовать строку поиска, Чтобы найти нужный товар
2) Как клиент онлайн магазина, Я хочу использовать номер телефона, Чтобы залогиниться в системе
3) Как клиент онлайн магазина, Я хочу просмотреть описание товара, Чтобы посмотреть информацию о товаре

Каждая из Задач, в подобном написании, представляет из себя Пользовательскую Историю. В таком случае, каждый из оранжевых стикеров — представляет из себя Epic (то есть, большую задачу, которая состоит из ряда историй). Если уж совсем точно, то — оранжевые тикеты, это Epic’и в JIRA, тикеты-задачи — это User Story в JIRA. Каждая из User Story в JIRA, затем может быть разбита на несколько тикетов, в рамках которых разработчик реализует те или иные части фичи.

Планирование

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

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

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

• важность или

• релизы

В случае с важностью, обычно используют три уровня: Must, Should, Could. Первый означает первоочерёдную ценность задач и означает, что они обязаны быть выполнены. Второй — что задачи важны и хорошо бы их выполнить. Третий — необязательны и могут быть не выполнены. Пример деления по важности выглядит следующим образом:

Картинка с сайта: habr.com

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

Второй способ, вместо важности — разделение на релизы. Выглядит следующим образом:

Картинка с сайта: habr.com

Как можно заметить, выглядит это примерно так же, как и вариант выше, однако, насчёт привязки к номеру версии software решения, мы можем планировать Пользовательские Истории к выпуску в определённых версиях нашего софта.

Процесс моделирования

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

Прежде всего, подобные карты создаются не одним человеком, а группой людей, включающей себя бизнес-ориентированных людей (Product Owner’а например), заинтересованных в фиче людей и разработчиков. Моделирование карты происходит в формате воркшопа, то есть — живого общения с обсуждениями и разноцветными стикерами на флипчартах и стенах.

Основных шагов в ходе воркшопа пять:

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

2. Создание большой картины. На этом этапе накидываются основные идеи о составе истории. Происходит первоначальное создание каркаса фичи.

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

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

5. Стратегия разработки и релизов. На этом этапе уже планируются задачи в разработку. Если нужно, карта актуализируется ещё. Цель этого этапа связать планирование на карте непосредственно с разработкой фичи.

Словарь терминов

• Карта Пользовательских Историй — она же User Story Mapping; метод визуального описания и планирования задач.

• Пользовательская История — она же User Story; это способ описания взаимодействия пользователя с software системой в формате нарративного повествования.

• Каркас — он же Backbone; основной набор шагов Пользовательской Истории.

• Активности — это группа задач, имеющих схожие цели.

Дополнительные материалы

• [1] https://www.jpattonassociates.com/wp-content/uploads/2015/03/story_mapping.pdf Отличный pdf документ-памятка по рассматриваему сегодня методу

• [2] Книга «Пользовательские истории. Искусство гибкой разработки ПО» Паттон Джефф – купить книгу ISBN 978-5-496-02931-5 с быстрой доставкой в интернет-магазине OZON

Оригинал этой статьи, а также многие другие на разные темы об IT и разработке, можно найти на моём сайте #fullstackguy.

#fullstackguy в Telegram. Подписаться!

Привет, я Андрей, в роли 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

Картинка с сайта: hightime.media

Кофаундер компании 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)?

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

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

Картинка с сайта: hightime.media

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

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

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

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

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

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

Картинка с сайта: hightime.media

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Картинка с сайта: hightime.media

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

Шаг 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 — это не просто инструмент, а способ мышления, позволяющий держать фокус на пользователе и создавать продукты, которые действительно приносят пользу. Если у вас появились вопросы или нужна помощь с развитием продукта, на связи! 👋

User Story Mapping — это метод проектирования продукта, разработанный scrum-мастером Джеффом Паттоном. Помогает визуально отображать пользовательские истории. С помощью этого инструмента можно определить, как покупатели взаимодействуют с продуктом и понять, какие его функции имеют для них большую или меньшую ценность.

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

• 1. User Persona — вымышленный портрет пользователя с его желаниями и проблемами. В карте может быть несколько типов клиентов, в том числе тех, кто платит за товар или услугу и пользуется ими бесплатно.
• 2. User Story — короткое описание задачи, которую разные пользователи хотят и могут решить с помощью продукта. Как правило, такие описания составляют по шаблону: роль — желание — выгода. Например, User Story пользователя приложения для доставки еды можно записать так: я как сотрудник, работающий в офисе, хочу выбрать блюда, которые доставят быстро, чтобы успеть пообедать.

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

• 3. User Journey — основа карты, на которой описаны общие действия пользователя с продуктом. Они расположены по горизонтали и представляют собой шаги, которые совершает пользователь. Например, вход в свой аккаунт в приложении для доставки еды, выбор товаров и оформление заказа.

Как составить User Story Map

Разберём пошаговый план сборки карты пользовательских историй.

Шаг 1. Собрать команду и подготовить инструменты

Чтобы собрать User Story Map, понадобится опыт сотрудников из разных команд. Идеальный состав — UX-дизайнер, редактор, продакт-менеджер, лид маркетинга, аналитик, сотрудник отдела продаж. Вести встречу может владелец продукта, продакт-менеджер или скрам-мастер. Важно, чтобы на встрече было не больше 10 человек, иначе процессом будет сложно управлять.

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

Шаг 2. Установить рамки

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

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

Картинка с сайта: crmgroup.ru

Границы функций продукта на User Story Map

Шаг 4. Определить типы пользователей

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

Шаг 5. Составить User Journey

На этом этапе нужно зафиксировать последовательность действий покупателя. Сделайте это для каждого сегмента либо выделите универсальные действия. Такими действиями могут быть:

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

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

Шаг 6: Написать истории пользователей

Сначала для каждого сегмента нужно записать истории в формате «роль — желание — выгода». Затем с помощью этих историй нужно дополнить все пробелы в карте. Например, составляя историю, вы поймёте, что пользователю нужно прикрепить платёжную карту к профилю в приложении. Значит, этот этап нужно добавить в карту, а затем реализовать в одном из релизов.

Шаг 7: Расставить приоритеты в историях и наметьте MVP

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

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

Шаг 8. Определить цели для следующих релизов

Когда вы определите MVP, то можно строить планы на следующие релизы. Если промежутки между релизами больше квартала, то лучше перед следующим обновлением ещё раз обсудить User Story Map.

Шаг 9 Упорядочить истории пользователей, которые не вошли на карту

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