User Story Map: что это такое и как карта пользовательских историй экономит бюджет на разработке

Объясняем простыми словами, как один лист со стикерами помогает бизнесу не выкидывать деньги на лишние функции, быстрее запустить MVP и не потерять из виду конечного клиента.

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

Корень проблемы в том, что у команды нет общей картинки, как клиент пользуется продуктом. Есть длинный список задач в Jira или Trello, есть требования заказчика, есть спецификации. Но нет единого взгляда сверху, который показывает: вот так клиент проходит путь, вот это для него критично, а вот это можно отложить.

Именно эту дыру закрывает User Story Map - карта пользовательских историй. Инструмент придумал Джефф Паттон, один из ветеранов гибкой разработки, ещё в 2008 году. С тех пор USM стала стандартом де-факто в продуктовых командах по всему миру: от стартапов до Сбера и Яндекса.

User Story Map - это визуальная карта, на которой расписан путь пользователя по продукту и все задачи разработки, привязанные к шагам этого пути. Вместо плоского списка из 200 задач в бэклоге у команды появляется двумерная картина: по горизонтали показано, что человек делает с продуктом, по вертикали показаны приоритеты и релизы.

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

Карта строится в три горизонтальных ряда. Сверху вниз. От крупного к мелкому.

1. Активности. Это крупные действия пользователя, из которых складывается работа с продуктом. Для интернет-магазина это «найти товар», «положить в корзину», «оформить заказ», «оплатить», «получить заказ». Для приложения такси это «заказать машину», «отследить поездку», «оплатить», «оценить водителя». Активности расставлены слева направо в той последовательности, в которой клиент реально через них проходит.
2. Шаги внутри каждой активности. Например, под «оформить заказ» лежат: указать адрес, выбрать способ доставки, ввести контакты. Это всё ещё уровень пользователя, не уровень разработки. Шаги отвечают на вопрос «что человек делает», а не «что мы для этого пишем в коде».
3. Пользовательские истории. Это уже конкретные задачи, которые попадут в бэклог разработки. Под шагом «выбрать способ оплаты» лежат: «оплата картой», «оплата по СБП», «Apple Pay», «оплата при получении». Каждая история это отдельная карточка, которую можно отдать программисту.

И тут начинается самое интересное. Карту режут горизонтальными линиями на релизы. Верхний срез это MVP, минимально работающий продукт: по одной самой простой истории под каждым шагом. Без него клиент не сможет дойти от поиска товара до получения заказа. Дальше идёт второй релиз, третий и так далее. То, что добавит удобства, но без чего жить можно.

Люди часто думают, что USM — это игрушка для скрам-мастеров и продактов. На самом деле первым выгоду получает заказчик и владелец бизнеса. В чем эта выгода?

1. Видно, на что уходят деньги. Когда перед вами 200 задач в Jira с непонятными названиями, оценить, что важно невозможно. Когда перед вами карта, на которой каждая задача стоит на своём месте под шагом клиента, диалог с командой превращается из «давайте делать ещё одну форму» в «эта функция в таком-то релизе и зачем она клиенту».
2. Понятен MVP. Самая распространённая ошибка стартапов и новых проектов, это пытаться сразу сделать «полную» версию продукта. Полгода разработки, миллионы рублей, релиз и ... тишина. USM показывает, какой минимальный набор функций даст клиенту пройти весь путь от начала до конца. С этим набором уже можно выходить на рынок и собирать обратную связь.
3. Команда не делает лишнего. Когда у разработчика есть только список задач, он берёт верхнюю и делает её. Когда у него есть карта, он видит, как его задача связана с остальными и зачем нужна клиенту. Лишние «улучшения», которые никто не просил, отваливаются сами собой.
4. Заказчик и команда говорят на одном языке. Бизнес мыслит сценариями: «клиент зашёл, выбрал, оплатил». Разработка мыслит задачами: «фронтенд формы оплаты, бэкенд валидации, интеграция со Сбербанк Онлайн». Карта это переводчик между двумя мирами. На ней одна и та же сущность видна и сверху, и снизу.

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

Customer Journey Map (CJM) — карта пути клиента в широком смысле. Она охватывает всё: как клиент узнал о бренде, что чувствовал, какие сомнения у него были, через какие точки касания он прошёл — рекламу, сайт, звонок менеджера, доставку, поддержку. CJM смотрит на клиента целиком, как на человека с эмоциями и историей. Её делают маркетологи и сервис-дизайнеры, чтобы найти узкие места в опыте.

User Story Map — карта пути клиента внутри одного продукта. Она не интересуется, как человек узнал о приложении и что он чувствовал в рекламе. Она показывает, что человек делает в самом приложении и какие функции для этого нужны. Её делают продуктовые команды, чтобы спланировать разработку.

Грубо: CJM отвечает на вопрос «как улучшить опыт клиента», USM — на вопрос «что и в каком порядке нам строить». Хорошая практика — использовать оба инструмента вместе. CJM подсвечивает проблемы, которые нужно решить. USM превращает решение в план разработки.

Кстати, про CJM и связанную с ней концепцию Jobs To Be Done у нас в блоге есть отдельная статья — почитайте, если хотите глубже разобраться, что вообще нужно клиентам и как это превратить в продукт.

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

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

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

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

Затем команда режет карту на релизы. В MVP попадает простой минимум: список ресторанов без фильтров, обычное меню без отзывов, оплата только картой, статус заказа без карты курьера. С таким приложением уже можно выйти на рынок, отдать его сотне клиентов и посмотреть, как они себя ведут.

Во второй релиз идут фильтры, рейтинги, отзывы, СБП, отслеживание курьера на карте. В третий — персональные рекомендации, корпоративные счета, программа лояльности.

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

Карту можно собрать на чём угодно: от стены с физическими стикерами до специализированных программ. Самые популярные варианты:

1. Miro и FigJam — онлайн-доски со стикерами. Универсальное решение для удалённых команд: каждый видит карту в реальном времени, можно одновременно двигать стикеры, оставлять комментарии. Подходит, если у вас уже один из этих сервисов используется для других задач.
2. Kaiten — российский сервис управления задачами с отдельным модулем User Stories. Удобство в том, что истории с карты можно сразу превратить в задачи на канбан-доске и отслеживать статус. Хороший вариант для команд, работающих по Agile.
3. StoriesOnBoard — специализированный инструмент только под USM. Если карта большая и над ней работает несколько команд, специализированный сервис удобнее универсальной доски: в нём предусмотрены релизы, версии, экспорт в Jira.
4. Бумага и стикеры на стене. Паттон в своей книге напрямую советует начинать именно так. Когда команда сидит вместе в офисе, физическая карта на стене работает лучше любого софта: её видно постоянно, к ней подходят, обсуждают, переклеивают стикеры. Цифровую же карту приходится специально открывать.

Не каждому проекту USM пойдёт на пользу. Есть ситуации, когда она лишняя или даже вредна.

1. Маленький проект на одного-двух разработчиков, где владелец сам пишет код. Карта нужна, когда команда от 3-4 человек и больше, и людям важно прийти к общему пониманию.
2. Чисто технические продукты без явного пользовательского пути. Например, движок базы данных или библиотека для разработчиков. Там нет «клиента, который проходит шаги»; есть API, контракты, тесты. USM тут будет натянутой.
3. Проекты с жёстким, заранее зафиксированным ТЗ, где менять ничего нельзя. Карта работает в гибких подходах, где приоритеты могут меняться от релиза к релизу. Если контракт говорит «сделать вот ровно эти 50 функций», карта превратится в декорацию.

Пробуйте! Собирайте карту со своей командой.

Час с пачкой стикеров часто заменяет неделю обсуждений в чатах.

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