В 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 Story Map:
«Всё время чувствую себя неловко, когда рассказываю топ-менеджеру большой компании о том, что мы разбили его систему на «эпики» и «истории».
Сам Джефф Паттон, любитель понятных метафор, сравнивает структуру карты со скелетом. Ряд активностей составляет хребет продукта. Пользовательские истории - рёбра.
Активности из хребта — суть продукта, ответ на вопрос, зачем он существует и как работает. Суть легко потерять из виду, если фокусироваться только на рёбрах - отдельных шагах, низкоуровневых задачках пользователя. Это и происходит, когда команда работает по плоскому бэклогу.
Но если в бэклоге есть хребет из активностей, команда всегда сможет легко ответить, зачем она работает над той или иной задачей. Достаточно лишь взглянуть, к какой активности (или эпику) относится задача.
Профиты USM для команды и продукта
Представление бэклога в виде User Story Map решает несколько взаимосвязанных проблем разработки. Вот что даёт карта пользовательских историй команде:
Цельное видение клиентского опыта
Карта пользовательских историй отражает реальные сценарии взаимодействия пользователя с продуктом. Как правило, User Story Map строится на основе Customer Journey Map. Если последняя описывает опыт клиента от взаимодействия с брендом во всех каналах, то USM работает локально, в рамках конкретного канала, например, приложения. Сам принцип построения и формат карты позволяют увидеть логические несостыковки и потенциальные проблемные места в опыте пользователя.
Цельное видение продукта
За десятками и сотнями рядовых задач нередко размывается образ продукта. Для чего создан продукт? Как он работает? Какие проблемы решает? В командах, работающих по плоскому бэклогу, ответить на эти вопросы часто может лишь продакт-менеджер или продакт-оунер. Бэклог в виде карты историй позволяет на любом этапе разработки составить общее представление о продукте, причем даже сотруднику, который только что присоединился к команде.
Чёткие приоритеты в разработке
Структура карты историй отражает путь пользователя в естественном порядке: последовательность задач соответствует последовательности действий реального пользователя. Именно в таком порядке логично строить и процесс разработки. Например, вначале нужно реализовать авторизацию, и только потом — форму заказа, который нельзя сделать без авторизации. Такой подход гарантирует, что продукт уйдёт в тестирование с полным набором функций, необходимых для выполнения сценария.
Кроме того, USM помогает «нарезать» продукт на версии и, таким образом, планировать релизы. Каждая версия продукта, попадающая к пользователю, самодостаточна. В ней есть всё, что нужно пользователю для выполнения задач ближайшей версии продукта. И при этом нет ничего избыточного, что понадобится для задач последующих версий.
USM как инструмент клиентоцентричной разработки
Карта пользовательских историй на уровне философии компании – то, что отличает продуктоцентричный и клиентоцентричный подходы к бизнесу.
Мы живём в эпоху экономики впечатлений и опыта. Человек делает выбор в пользу бренда, который слушает и слышит своего клиента, отвечает на его запросы и решает его проблемы.
И пока продуктоцентричная компания создаёт идеальный продукт для идеального клиента (которого в действительности может и не существовать), все решения клиентоцентричной компании строятся вокруг реального клиента и его потребностей.