Продукт
Что такое User Story Map и как её построить
Что такое User Story Map, чем карта пользовательских историй лучше плоского бэклога и как за одну встречу разложить продукт на шаги пути пользователя и нарезать первый релиз. Разбираем устройство карты, ход сессии, пример интернет-магазина и частые ошибки.
На этой странице
- Что такое User Story Map
- Что такое пользовательская история
- Из чего состоит карта
- Чем карта отличается от плоского бэклога
- Как построить User Story Map: сессия по шагам
- Как выбрать MVP по карте
- Если команда работает удалённо
- Что делать с картой после сессии
- Пример: карта интернет-магазина
- Частые ошибки
- User Story Map в NodePanel
- Чек-лист: карта готова, если…
- Вопросы и ответы
Что такое User Story Map#
User Story Map (карта пользовательских историй, story mapping) — это способ разложить продукт так, как его проходит пользователь. Сверху слева направо идут крупные действия человека — от первого знакомства до результата. Под каждым действием — истории: что именно нужно сделать в продукте, чтобы человек справился. А горизонтальные полосы делят истории на релизы: что войдёт в первую версию, что во вторую.
Методику описал и популяризировал Джефф Паттон, автор книги о story mapping. Его главная мысль: плоский список задач теряет картину целиком. Глядя на сотню пунктов бэклога, трудно ответить, сможет ли пользователь пройти путь от начала до конца в ближайшем релизе. Карта отвечает на этот вопрос одним взглядом.
Что такое пользовательская история#
Пользовательская история (user story) — короткое описание возможности с точки зрения того, кто ей пользуется. Классический шаблон: «Как <роль>, я хочу <действие>, чтобы <ценность>». Например: «Как покупатель, я хочу отфильтровать товары по цене, чтобы не листать то, что мне не по карману».
- Роль — кто пользуется: покупатель, администратор, гость. Удобно, когда роли совпадают с описанными персонами, — подробнее на странице портрет пользователя.
- Действие — что человек хочет сделать, а не какую кнопку нажать.
- Ценность — зачем ему это. Именно эта часть помогает спорить о приоритетах.
На карте истории обычно пишут короче — «Фильтр по цене», а полную формулировку и критерии готовности держат в описании карточки или в трекере задач.
Из чего состоит карта#
У карты три уровня по вертикали и одна ось времени по горизонтали. Названия в разных командах отличаются, но устройство одно и то же.
- Хребет (backbone), или активности. Крупные цели пользователя на пути: «Найти товар», «Оформить заказ», «Получить заказ». Они идут слева направо в том порядке, в каком человек их проходит. Хребет не делится на релизы: без любой из активностей путь не пройти.
- Шаги (задачи пользователя). Из чего состоит каждая активность: «Поиск», «Карточка товара», «Корзина», «Оплата». Это всё ещё действия человека, а не экраны или компоненты системы.
- Детали (истории). Конкретные варианты реализации шага, сверху вниз по важности: «Поиск по названию» выше, чем «Голосовой поиск».
- Срезы релизов. Горизонтальные полосы поперёк всей карты. Всё, что выше линии, входит в релиз. Первый срез — самый тонкий вариант, при котором пользователь проходит путь целиком.
Чем карта отличается от плоского бэклога#
Плоский бэклог — это список, отсортированный по приоритету. Он удобен, чтобы брать задачи в работу, но плохо отвечает на вопрос «что мы на самом деле выпускаем». Карта не заменяет бэклог, а наводит в нём порядок: из неё задачи переходят в список уже с понятным контекстом.
Так хуже
Так лучше
Как построить User Story Map: сессия по шагам#
Карту лучше строить вместе: продакт-менеджер, разработчики, дизайнер, тестировщик, иногда поддержка и продажи. Каждый видит путь пользователя со своей стороны, и пробелы находятся быстрее.
Договоритесь о пользователе и цели
Чей путь раскладываете и чего человек хочет добиться. Если ролей несколько, начните с главной.
Расскажите путь целиком
Пройдите историю пользователя от начала до конца и выпишите крупные действия. Это будущий хребет.
Выстройте хребет
Расставьте активности слева направо в порядке пути. Проверьте вслух: «Сначала человек… потом… потом…».
Разбейте активности на шаги
Под каждой активностью — шаги пользователя. Пустых мест быть не должно: если шага нет, путь обрывается.
Накидайте истории
Под каждым шагом — варианты реализации, от простого к сложному. На этом этапе не спорьте о сроках.
Отсортируйте по вертикали
Внутри каждой колонки поднимите вверх то, без чего шаг не работает, а желательное опустите вниз.
Проведите линию первого релиза
Минимальный набор, при котором пользователь проходит весь путь. Обычно это заметно меньше, чем хочется.
Нарежьте следующие релизы
Каждый следующий срез улучшает путь: добавляет удобство, скорость, новые варианты. Назовите цель каждого среза.
Как выбрать MVP по карте#
MVP на карте — это не «самые важные задачи», а самый тонкий срез через все активности. Если в первый релиз вошли отличный поиск и красивая карточка товара, но нет оплаты, пользователь ничего не купит. Поэтому линия первого релиза проходит под каждой колонкой хребта, пусть и на уровне самого простого варианта: оплата только картой, доставка только самовывозом, возврат через поддержку.
- В каждой колонке над линией есть хотя бы одна история.
- Пользователь может пройти путь от начала до конца без обходных путей.
- Всё, что делает путь удобнее, но не обязательно, — ниже линии.
Если команда работает удалённо#
Сессию можно провести и без общей комнаты со стеной стикеров. Главное — общий холст, который видят все одновременно, и ведущий, который держит порядок шагов. Удобно заранее подготовить доску: подписать цель, оставить место для хребта и нарисовать пустые рамки релизов.
- Хребет выстраивайте вслух вместе, а истории под шагами участники могут накидывать параллельно, каждый в своей колонке.
- Спорные истории не обсуждайте сразу: отметьте их и вернитесь после того, как карта заполнена целиком.
- Линию первого релиза проводите в конце, когда все видят всю карту, — иначе срез получится по одному шагу.
Что делать с картой после сессии#
Карта — не замена трекеру задач, а источник для него. После встречи истории первого среза уточняют: дописывают формулировку «Как <роль>, я хочу…, чтобы…», критерии готовности и оценку. Затем они попадают в бэклог в том порядке, который подсказывает карта: сначала всё, что нужно для сквозного пути, потом улучшения. Саму карту оставляют на виду и возвращаются к ней на планировании: передвигают истории между срезами, отмечают сделанное, добавляют то, что узнали от пользователей.
Пример: карта интернет-магазина#
Вернёмся к схеме выше. Пользователь — покупатель, который заказывает товар впервые. Хребет: «Найти товар», «Оформить заказ», «Получить заказ». Под ними шесть шагов — от поиска до возврата.
- Первый релиз закрывает весь путь самым простым способом: поиск по названию, фото и цена в карточке, корзина с изменением количества, оплата картой, самовывоз, возврат через поддержку.
- Второй релиз делает путь удобнее: фильтры по цене, отзывы, отложенные товары, оплата частями, курьер и заявка на возврат онлайн.
- Что видно сразу: возврат есть уже в первой версии, пусть и вручную. В плоском бэклоге он легко уехал бы в конец списка, и первые же покупатели остались бы без ответа.
Учебный пример намеренно небольшой. Настоящая карта магазина больше: появятся роли продавца и оператора, личный кабинет, уведомления. Для каждой роли удобно делать свою карту, а общий путь склеивать по точкам, где роли встречаются.
Частые ошибки#
- Хребет из экранов и модулей. «Главная», «Каталог», «Админка» — это устройство системы, а не путь человека. Активности называют глаголами пользователя.
- Технические задачи вместо историй. «Настроить базу данных» не история: у неё нет пользователя и ценности. Такие работы живут в бэклоге рядом с историями, которым они нужны.
- MVP без сквозного пути. В первый релиз попали лучшие функции одного шага, а соседний шаг пуст.
- Карту делает один человек. Получается его взгляд на продукт, а не общая договорённость; пробелы всплывают уже в разработке.
- Карту не обновляют. После первого релиза появляются отзывы и данные — карту стоит пересмотреть и перерезать следующие срезы.
- Слишком мелкая детализация. Сто карточек под одним шагом говорят о том, что шаг надо разделить или вынести в отдельную карту.
User Story Map в NodePanel#
В NodePanel есть готовый шаблон User Story Map: этапы пути пользователя сверху и истории по релизам под ними. Создайте доску из шаблона и замените тексты своими.
- Релизы удобно оформлять группами: группа — это рамка с названием, и её можно двигать вместе с историями.
- Следующий этап хребта — выделите последний и нажмите Tab: блок встанет справа со связью.
- Историю, которую уже обсуждают подробно, можно сделать карточкой со статусом, метками и чек-листом критериев.
- Карту собирают вместе в реальном времени, а спорные истории обсуждают в комментариях.
- Показ по шагам превращает группы в слайды: удобно пройтись по релизам на встрече.
Как это работает для команды — на странице User Story Map на онлайн-доске. Для ролей пригодится шаблон портрета пользователя. Попробовать редактор можно без регистрации — в песочнице.
Чек-лист: карта готова, если…#
- Понятно, чей путь на карте и какая у человека цель.
- Хребет читается слева направо как связная история.
- Активности и шаги названы действиями пользователя, а не экранами.
- Под каждым шагом есть хотя бы одна история.
- Истории в колонках отсортированы от необходимого к желательному.
- Первый релиз проходит через все активности.
- У каждого среза есть цель, понятная пользователю.
- Карту строили вместе: продукт, разработка, дизайн, тестирование.
- Назначено, когда карту пересмотрят после релиза.
Вопросы и ответы#
Что такое User Story Map простыми словами?
Это карта, на которой путь пользователя разложен слева направо, а под каждым шагом пути — истории о том, что нужно сделать в продукте. Горизонтальные полосы делят истории на релизы.
Чем User Story Map отличается от бэклога?
Бэклог — один список по приоритету, а карта показывает задачи в контексте пути пользователя. По карте видно, сможет ли человек пройти весь путь в ближайшем релизе и где остались пробелы.
Кто должен участвовать в построении карты историй?
Обычно продакт-менеджер, разработчики, дизайнер и тестировщик, а при необходимости поддержка и продажи. Чем больше разных взглядов на путь пользователя, тем меньше пробелов останется на карте.
Сколько времени занимает построение User Story Map?
Черновик небольшого продукта или крупной функции обычно собирают за одну рабочую встречу. Дальше карту дорабатывают по мере обсуждений и пересматривают после каждого релиза.
Можно ли использовать User Story Map без Scrum?
Да, карта не привязана к конкретной методологии. Она помогает договориться о пути пользователя и составе релизов в любой команде, которая выпускает продукт частями.