User Story Map — один из непременных инструментов разработки цифровых продуктов. Сложно представить, что когда-то команды обходились без него. О том, как жила продуктовая разработка до появления USM и как сегодня она помогает создавать продукты для людей, журналу IT News рассказывает Павел Голуб, сооснователь и директор по развитию компании arcsinus.
В 2008 году Джефф Паттон, эксперт по гибкой разработке и дизайн-мышлению, в одном из своих постов описывал жалобу, которую часто слышал от команд разработки: «Работая над большим продуктом, мы теряем целостное видение, перестаём понимать, зачем делаем тот или иной элемент». Рефлексируя над этим, Паттон пришёл к выводу: команды теряют helicopter view продукта, потому что работают по «плоскому бэклогу» (упорядоченному, без иерархии, списку элементов планирования проекта (продукта)). И в качестве альтернативы предложил бэклог в форме карты пользовательских историй.
Карта пользовательских историй (User Story Mapping) — популярный фреймворк гибкого подхода к разработке, точнее, к этапу планирования. Она представляет собой визуализацию пути, который клиент проходит, взаимодействуя с продуктом. USM включает в себя все задачи, которые пользователь обычно выполняет в ходе этого путешествия.
Что такое User Story
Как понятно из самого термина, User Story Map — карта, состоящая из пользовательских историй. А что собой представляет непосредственно пользовательская история (User Story)? Это простой, интуитивно понятный способ сформулировать требование к элементу разрабатываемого продукта. Пользовательская история говорит голосом пользователя и строится по следующему шаблону:
Как [представитель группы пользователей]
я хочу [выполнить задачу]
чтобы [достичь цели]
Сила такого подхода заключается в простоте. Мы рассматриваем конкретного пользователя, понимаем, что он хочет сделать и какой результат ожидает получить. В этой формулировке есть все данные для поиска решения.
При этом история не навязывает конкретную форму решения. Она помогает держать в фокусе действительно важные вещи — пользователя и его потребности.
Что не так с плоским бэклогом
С подачи Паттона, в середине нулевых концепция User Story Map стала распространяться в среде продуктовых разработчиков. До этого общей практикой был так называемый «плоский бэклог» (flat backlog). Он представляет собой список проектных задач, похожий на to-do list, который мы составляем в начале дня, или список покупок, который набрасываем по дороге в магазин. Плоский бэклог состоит из множества низкоуровневых задач типа «сделать форму отправки контактов».
Человеку, не знакомому с разработкой, может показаться, что с этим подходом всё в порядке, ведь из самой формулировки ясно, что делать. Недостатки становятся видны, если взглянуть на него с позиции гибких методологий разработки.
Плоский бэклог не даёт общего представления о продукте
Если продукт достаточно большой и сложный, в плоском бэклоге видны все отдельные функции. Но по ним сложно судить, как работает система целиком. Глядя на множество разрозненных задач, невозможно понять главную ценность для пользователя, увидеть связи и зависимости между элементами.
Плоский бэклог не помогает команде планировать релизы
Это особенно важно, когда речь идет о разработке нового продукта. Нужно очертить границы первой версии (MVP), а затем определиться с функционалом последующих. В плоском бэклоге всё выглядит одинаково важным. И столь же одинаково неважным.
Плоский бэклог не помогает расставить приоритеты
Команда не может делать всё сразу. Значит, необходимо выделить задачи, за которые нужно взяться в первую очередь, затем те, что пойдут в работу следом, и так далее. Сам Паттон признаётся, что худшие часы жизни он провёл на собраниях, где команда пыталась приоритизировать задачи.
Даже если плоский бэклог состоит из задач, сформулированных как пользовательские истории, проблема с приоритетами сохраняется. Хорошо, что задачи фокусируются на потребностях пользователя. Но это только половина дела. За вторую половину отвечает сам принцип организации этих историй — карта.
Сам Джефф Паттон описывает проблему плоского бэклога, приводя через метафору с деревом:
«Мы уделяем много времени работе с нашими клиентами. Мы стараемся понять их цели, пользователей, определить основные части будущей системы. Затем мы переходим к деталям — элементам функционала, которые нужно создать. Я представляю себе это как дерево. Ствол — цели и ожидаемые выгоды для бизнеса. Большие ветви — пользователи, маленькие ветки — их потребности. Наконец, листья — это пользовательские истории, достаточно маленькие, чтобы отдать их в разработку. Проделана большая работа, и у всех участников есть общее видение системы. И тут мы будто срываем все листья с дерева и сваливаем их в мешок, а затем срубаем дерево. Вот что для меня значит плоский бэклог. Он как мешок с листьями — неструктурированная масса элементов, лишённых контекста».
Принципы построения USM
Как говорит сам автор концепции, в основе карты пользовательских историй лежит предельно простая идея.
Наверху карты — большие истории. Паттон дал им название activities (активности).
На практике в командах вместо слова «активность» часто используют термин «эпик». Каждая активность — сравнительно крупная задача, которую выполняет пользователь с помощью продукта. Активность может состоять из множества шагов, у неё нет единого общего линейного сценария, и к одному и тому же результату можно прийти разными путями.
Активности выстраивают на карте слева направо в том порядке, в котором пользователь сталкивается с ними внутри продукта.
Рассмотрим это на примере реального проекта компании arcsinus — сервиса подбора персонала для крупного заказчика. Одна из персон – пользователей сервиса — менеджер по персоналу. Его активности в продукте выглядят так:
Вот одна из активностей: «Оформление кандидата на работу». Формулировка предельно общая.
Активность — слишком большая сущность для одной задачи. Её невозможно разработать за один спринт. Значит, требуется дальнейшая декомпозиция.
Уровнем ниже располагаются непосредственно user stories (пользовательские истории). Внутри пользовательской активности «Оформление» может быть как минимум два вероятных сценария развития: «Оформить кандидата» и «Не оформить кандидата».
Это и есть ключевая сущность USM — история. Согласно трёхчастной структуре, о которой говорилось выше, история будет звучать так:
«Как менеджер по персоналу я хочу оформить кандидата, чтобы завершить цикл найма и закрыть вакансию».
Ещё одним уровнем ниже располагаются user tasks (пользовательские задачи). Это шаги, на которые можно разбить пользовательскую историю, мелкие действия, которые пользователь предпринимает, чтобы достичь цели. В нашем примере задача пользователя может выглядеть так:
Таким образом, активность может включать несколько пользовательских историй. Пользовательская история, в свою очередь, может состоять из нескольких пользовательских задач.
Джефф Паттон, автор методологии User Story Map:
«Всё время чувствую себя неловко, когда рассказываю топ-менеджеру большой компании о том, что мы разбили его систему на «эпики» и «истории».
Сам Джефф Паттон, любитель понятных метафор, сравнивает структуру карты со скелетом. Ряд активностей составляет хребет продукта. Пользовательские истории — рёбра.
Активности из хребта — суть продукта, ответ на вопрос, зачем он существует и как работает. Суть легко потерять из виду, если фокусироваться только на рёбрах — отдельных шагах, низкоуровневых задачках пользователя. Это и происходит, когда команда работает по плоскому бэклогу.
Но если в бэклоге есть хребет из активностей, команда всегда сможет легко ответить, зачем она работает над той или иной задачей. Достаточно лишь взглянуть, к какой активности (или эпику) относится задача.
Профиты USM для команды и продукта
Представление бэклога в виде User Story Map решает несколько взаимосвязанных проблем разработки. Вот что даёт карта пользовательских историй команде:
Цельное видение клиентского опыта
Карта пользовательских историй отражает реальные сценарии взаимодействия пользователя с продуктом. Как правило, User Story Map строится на основе Customer Journey Map. Если последняя описывает опыт клиента от взаимодействия с брендом во всех каналах, то USM работает локально, в рамках конкретного канала, например, приложения. Сам принцип построения и формат карты позволяют увидеть логические несостыковки и потенциальные проблемные места в опыте пользователя.
Цельное видение продукта
За десятками и сотнями рядовых задач нередко размывается образ продукта. Для чего создан продукт? Как он работает? Какие проблемы решает? В командах, работающих по плоскому бэклогу, ответить на эти вопросы часто может лишь продакт-менеджер или продакт-оунер. Бэклог в виде карты историй позволяет на любом этапе разработки составить общее представление о продукте, причем даже сотруднику, который только что присоединился к команде.
Чёткие приоритеты в разработке
Структура карты историй отражает путь пользователя в естественном порядке: последовательность задач соответствует последовательности действий реального пользователя. Именно в таком порядке логично строить и процесс разработки. Например, вначале нужно реализовать авторизацию, и только потом — форму заказа, который нельзя сделать без авторизации. Такой подход гарантирует, что продукт уйдёт в тестирование с полным набором функций, необходимых для выполнения сценария.
Кроме того, USM помогает «нарезать» продукт на версии и, таким образом, планировать релизы. Каждая версия продукта, попадающая к пользователю, самодостаточна. В ней есть всё, что нужно пользователю для выполнения задач ближайшей версии продукта. И при этом нет ничего избыточного, что понадобится для задач последующих версий.
USM как инструмент клиентоцентричной разработки
Карта пользовательских историй на уровне философии компании – то, что отличает продуктоцентричный и клиентоцентричный подходы к бизнесу.
Мы живём в эпоху экономики впечатлений и опыта. Человек делает выбор в пользу бренда, который слушает и слышит своего клиента, отвечает на его запросы и решает его проблемы.
И пока продуктоцентричная компания создаёт идеальный продукт для идеального клиента (которого в действительности может и не существовать), все решения клиентоцентричной компании строятся вокруг реального клиента и его потребностей.
