User Story Mapping: пример построения

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

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

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

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

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

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

Давайте создадим карту для процесса покупки товара в интернет-магазине.

Для построения User Story Mapping участникам команды нужно представить себя на месте пользователя и ответить на несколько вопросов.

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

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

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

Активности и задачи дублируют друг друга — это неинформативно.

Задачи повторяют содержание историй и карта становится слишком широкой и сложно воспринимаемой.

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

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

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

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

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

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