User Story Map и ее роль в создании продукта для компании

Как мы теряем helicopter view продукта

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

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

Но что не так с «плоским бэклогом»

«Плоский бэклог» — классический способ планирования шагов проекта. Это список низкоуровневых задач, таких как «сделать форму приема заявок», например. То есть обычный to-do лист. Четко и ясно. Так в чем же проблема?

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

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

Паттон иллюстрирует проблему «плоского бэклога» через метафору дерева:

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

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

Работая с «плоским бэклогом», команды разработки тратят десятки часов впустую, пытаясь приоритизировать задачи в to-do листах: в них все выглядит одинаково важным и столь же одинаково неважным.

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

User Story Mapping был предложен Джеффом Паттоном в противоположность «плоскому бэклогу», чтобы помочь командам справиться с этими проблемами.

User Story Mapping — разбираемся с термином

User Story Mapping (USM) — это фреймворк гибкого подхода к этапу планирования, карта, которая визуализирует путь клиента, взаимодействующего с продуктом.

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

Для построения пользовательской истории удобно пользоваться следующей формулой:

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

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

Принципы построения USM

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

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

Вот одна из активностей — «Оформление кандидата на работу».

Если расписать эту пользовательскую историю по формуле выше, она будет звучать так:

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

«Оформление» — слишком большая сущность для одной задачи, ее невозможно разработать за один спринт. Значит, ее нужно декомпозировать.

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

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

Таким образом, активность может включать несколько пользовательских историй. Пользовательская история, в свою очередь, может состоять из нескольких пользовательских задач.

Что карта пользовательских историй дает команде

Представление бэклога в виде User Story Map решает несколько важных задач разработки.

Целостное восприятие клиентского опыта
Карта пользовательских историй демонстрирует реальные сценарии взаимодействия пользователей с продуктом. Обычно User Story Map создается на основе Customer Journey Map (карта пути клиента, CJM). Она охватывает весь опыт клиента при взаимодействии с брендом через различные каналы, а USM сосредотачивается на конкретном канале, например, на приложении. Такой подход и формат карты помогают выявить логические несоответствия и потенциальные проблемные моменты в пользовательском опыте.

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

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

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