User Story Mapping - что это такое и как построить

Правильно оценить этапы проекта при создании или доработке программного продукта (сервиса), устранить пробелы в бэклоге, спланировать релизы и грамотно распределить задачи между ними, определить критерии готовности MVP, наметить пути улучшения пользовательских сценариев – во всем этом (и в ряде других вопросов) вам поможет User Story Mapping (далее – USM). Если переводить этот термин дословно, получается «карта пользовательских историй». А по сути она представляет собой визуализацию пути пользователя при работе с разрабатываемым продуктом/сервисом.

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

Из каких элементов и как строится User Story Map

К основным элементам карты относятся:

• Действующие роли/лица (акторы, Users, Actors).

• Активности пользователей (Activities).

• Пользовательские истории (User Stories).

• Задачи пользователей (User Tasks).

Схематически скелет USM с основными компонентами можно изобразить так:

Действующие роли/лица

Как правило, User Story Mapping строится для одного конкретного действующего лица, которое будет использовать программный продукт или сервис. Пусть это будет покупатель интернет-магазина (для примера).

Пользовательские истории

После того, как определено действующее лицо, для него разрабатываются пользовательские истории (обратите, внимание, не активности, которые указаны вторым пунктом в списке выше). Пусть для нашего пользователя из примера будут следующие User Stories:

• Найти нужный товар в каталоге.

• Изучить описание товара.

• Ознакомиться с фото товара.

• Добавить товар в корзину.

• Указать адрес доставки и выбрать удобное время.

• Ввести данные банковской карты для оплаты.

• Подтвердить оплату (с помощь Push, SMS или иным способом).

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

При подготовке цепочки User Stories опираются на цели пользователя, на то, чего он хочет/должен достигнуть при реализации определенной истории. Довольно часто при этом применяют подход «Роль — желание — выгода». В рассматриваемом случае «Покупатель хочет приобрести товары в интернет-магазине с доставкой на дом».

Активности пользователей (Activities)

Далее при подготовке карты определяются активности пользователей (часто их еще называют этапами). В один этап может быть включена одна или несколько User Stories.

Для рассматриваемого примера с интернет-магазином можно выделить следующие активности пользователя (этапы):

• Поиск нужного товара.

• Ознакомление с информацией о товаре.

• Добавление товара в корзину.

• Приобретение товара.

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

Добавление задач пользователей (User Tasks)

На данном этапе в карту добавляются обязательные и необязательные действия пользователей (User Tasks), выполнение которых требуется для реализации того или иного сценария. 

Для рассматриваемого нами примера перечень User Tasks может выглядеть так:

• Для этапа Поиск нужного товара: отфильтровать предложения по рейтингу, отфильтровать предложения по стоимости.

• Для этапа Ознакомление с информацией о товаре: почитать отзывы, посмотреть рейтинг, выбрать модификацию.

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

• Для этапа Приобретение товара: запомнить карту, выбрать способ оплаты.

Здесь же задачи пользователя приоритезируются. Более важные помещаются выше, менее важные и срочные – ниже.

По результатам этого этапа карта для рассматриваемого примера может выглядеть так:

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

Для нашего примера с интернет-магазином заполненный скелет USM на конечном этапе может выглядеть так:

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

Как сделать выводы о готовности USM и пригодности к использованию

Один из первых критериев, на который нужно смотреть во время оценки готовности карты, – соблюдение ее формата. В UMS должны присутствовать все ее компоненты. Если чего-то не будет (например, не определено действующее лицо), работать с такой User Story Map нельзя.

Также необходимо проанализировать формулировки, используемые в карте. Они должны нести образ решения задачи. Т.е., если при изучении истории в уме рисуется один или несколько вариантов решения, возникает желание и проявляется желание приступить к работе, значит, все сделано правильно и USM составлена грамотно, ее можно брать в работу. Если же при изучении появляется много вопросов с неочевидными ответами, User Story Map стоит переработать, т.к. из-за отсутствия понимания ожидаемого результата достичь намеченных целей не получится.

Также стоит понимать, что готовая история – не «монолит». Т.е. при необходимости что-то в ней можно менять (например, скорректировать приоритет задач пользователя и их распределение по релизам). Но делать это необходимо с обязательным согласованием со всеми участниками процесса подготовки USM и доведением информации до всех участвующих в разработке/доработке программного продукта (сервиса).

Инструменты для построения User Story Map

С помощью каких инструментов строить USM? Вариантов здесь несколько. 

С этой задачей неплохо справляются даже обычные бумажные стикеры. Можно собрать команду в одном месте и наклеивать на рабочую доску цветные наклейки, на которых будут обозначены все составляющие User Story Map. Способ довольно простой в реализации. Но есть вопросы к тому, как карту хранить: эти стикеры должны быть постоянно где-то наклеены. А если в компании в настоящий момент используется несколько USM? Тогда вся переговорка будет обклеена ими.

Поэтому многие пользуются специализированными программами и онлайн-инструментами для создания USM. Вариантов масса. Это может быть, например диаграмма .drawio, над которой работает один или несколько участников. Некоторые команды используют для совместной работы над USM популярный сервис Miro. Есть даже специализированные сервисы, которые созданы специально для работы с User Story Map. Пример – CardBoard.com.

Если над продуктом/сервисом работает географически распределенная команда, при разработке карт USM не обойтись без IP-телефонии. Используя виртуальную АТС, вы сможете обеспечить команду качественной связью. Для сессий по построению User Story Map будут полезными такие функции ВАТС, как проведение конференций (аудио и видео), запись разговоров (плюс их перевод в текст, поиск нужных фрагментов по ключевым фразам), передача файлов.

Видно, что карта пользовательских историй – довольно мощный инструмент, который поможет навести порядок в разработке программных продуктов и сервисов. Благодаря ему в основу бэклога помещаются ценности для юзера, т.е. в разработку берется то, что действительно имеет определенную важность и ценность. USM также помогает экономить время. Ведь при ее использовании команда не совершает лишней, ненужной работы, ни в отдельно взятом этапе разработки, ни в целом. Также при применении User Story Map можно говорить о высоком качестве разработки. Ведь при правильном подходе к ее составлению каждая история обсуждается и детально прорабатывается. А значит минимизируется вероятность возникновения ситуаций, когда будет появляться непредвиденное поведение разрабатываемого продукта в ответ на действия пользователя.