Где карта, Билли? Что такое User Story Map и как она помогает создавать продукты для людей

‍

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

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

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

Что такое User Story Map

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

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

Что такое User Story

Как понятно из термина, user story map — это карта, состоящая из пользовательских историй. А пользовательская история — это что?

Пользовательская история, или User Story — простой, интуитивно понятный способ сформулировать требование к элементу разрабатываемого продукта. Пользовательская история говорит голосом пользователя и строится по шаблону:

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

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

При этом история не навязывает конкретную форму решения. Она помогает держать в фокусе действительно важные вещи — пользователя и его потребности. На практике встречается вариация пользовательских историй — Job Stories. О них в другой раз:)

Что не так с плоским бэклогом

С подачи Паттона концепция User Story Map стала распространяться в среде продуктовых разработчиков в середине нулевых. До этого общей практикой был так называемый «плоский бэклог», flat backlog.

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

Человеку, не знакомому с разработкой, может показаться, что с этим подходом всё в порядке — ведь из формулировки ясно, что делать. Недостатки становятся видны, если взглянуть на него с позиции гибких методологий разработки.

• Плоский бэклог не даёт общего представления о продукте. Если продукт достаточно большой и сложный — в плоском бэклоге видны все отдельные функции, но по ним сложно судить, как работает система целиком. Глядя на множество разрозненных задач, невозможно понять главную ценность для пользователя, увидеть связи и зависимости между элементами.
  ‍
• Плоский бэклог не помогает команде планировать релизы. Это особенно важно, когда продукт новый. Нужно очертить границы первой версии (MVP), а затем определиться с функционалом последующих. В плоском бэклоге всё выглядит одинаково важным. И столь же одинаково неважным.
  ‍
• Плоский бэклог не помогает расставить приоритеты. Команда не может делать всё сразу, а значит, необходимо выделить задачи, за которые нужно взяться в первую очередь, затем те, что пойдут в работу следом и так далее. Сам Паттон признаётся, что худшие часы жизни он провёл на собраниях, где команда пыталась приоритезировать задачи.

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

Сам Джефф Паттон описывает проблему плоского бэклога через метафору с деревом:

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

Как устроена USM

Как говорит сам автор концепции, в основе карты пользовательских историй предельно простая идея.

Наверху карты — большие истории. Сам Паттон называет их activities — активности. Это сравнительно крупная задача, которую выполняет пользователь с помощью продукта. Активность может состоять из множества шагов, у неё нет единого общего линейного сценария — то есть к одному и тому же результату можно прийти разными путями.

На карте активности выстраивают слева направо в том порядке, в котором пользователь сталкивается с ними внутри продукта. Рассмотрим это на примере реального проекта компании arcsinus — сервиса подбора персонала для крупного заказчика. Одна из персон — пользователей сервиса — менеджер по персоналу. Его активности в продукте выглядят так:

Вот одна из активностей: «Оформление кандидата на работу». Формулировка предельно общая.

Активность — сущность слишком большая для одной задачи. Её невозможно разработать за один спринт. Значит, требуется дальнейшая декомпозиция.

Уровнем ниже — собственно user stories, пользовательские истории. Внутри пользовательской активности «Оформление» может быть как минимум два вероятных сценария развития: «Оформить кандидата» и «Не оформить кандидата».

‍

Это и есть ключевая сущность USM — история. Согласно трёхчастной структуре, о которой мы говорили выше, история будет звучать так:

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

Ещё один уровнем ниже находятся user tasks, или пользовательские задачи. Это шаги, на которые можно разбить пользовательскую историю, мелкие действия, которые пользователь предпринимает, чтобы достичь цели. В нашем примере задача пользователя может выглядеть так:

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

На практике в командах вместо слова «активность» часто используют термин «эпик». Его придумал не Джефф, и он не любит этот термин. «Я не „Беовульфа“ написал, — иронизирует он. — В моих историях мифический герой не убивает дракона магическим мечом. Я просто описываю общую картину того, что хочет сделать пользователь». Термин «история» ему тоже не очень нравился, но с ним он смирился.

Сам Джефф — любитель понятных метафор — сравнивает cтруктуру карты со скелетом. Ряд активностей — это хребет продукта. Пользовательские истории — рёбра.

Активности из хребта — это суть продукта, ответ на вопрос, зачем он существует и как работает. Суть легко потерять из виду, если фокусироваться только на рёбрах — отдельных шагах, низкоуровневых задачках пользователя. Это и происходит, когда команда работает по плоскому бэклогу.

Но если в бэклоге есть хребет из активностей — команда всегда сможет легко ответить, зачем она работает над той или иной задачей. Достаточно лишь взглянуть, к какой активности (или эпику, если этот термин принят в компании) относится задача.

Профиты USM для команды и продукта

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

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

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

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

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

USM — инструмент клиентоцентричной разработки

На уровне философии компании карта пользовательских историй — это то, что отличает продуктоцентричный и клиентоцентричный подходы к бизнесу.

Мы живём в эпоху экономики впечатлений и опыта. Человек делает выбор в пользу бренда, который слушает и слышит своего клиента, отвечает на его запросы и решает его проблемы.

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

User Story Map — инструмент клиентоцентричной разработки. Пользовательские истории — это голос клиента, а карта историй отражает то, что ждёт клиент от продукта.

TL; DR

→ User Story Map — лучшая практика для планирования разработки, пришедшая на смену «плоскому бэклогу» в середине нулевых.

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

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

→ User Story Map — атрибут актуального клиентоцентричного подхода к разработке. Работая по бэклогу в форме USM, команда разрабатывает продукт, решающий реальные проблемы реальных пользователей.

‍

Этот материал опубликован на it-world.ru.