Как применяли User Story Map
В B2B новые продукты обычно очень масштабные, с огромной предполагаемой функциональностью. Для того, чтобы выделить MVP, не упустив основной путь пользователя и не уйти в «фичеризм», мы используем карту пользовательских историй (User Story Map). Сегодня я дам краткую инструкцию, которая позволит быстро применить эту методику.
Описание методики
Итак, карта пользовательских историй или User Story Map — это метод описания требований к продукту, состоящий из определения ролей, проблем пользователей и связанных с ними сценариев решения (пример по ссылке в Miro).
Составляющие User Story Map:
- Персона
- Цели пользователей
- Шаги для достижения каждой цели
- Реализация шагов
Персона
Перед составлением User Story Map надо ответить на вопрос: кто эти люди, чьи цели будут рассматриваться на карте. Существует 2 способа:
- Персоны. Проверенные с помощью исследований или гипотетические.
- Предполагаемые роли пользователей продукта. Если по каким-то причинам нет возможности визуализировать персон, то это минимально допустимый вариант.
Персоны или роли выписываются на стикерах на доске.
Цели пользователей
Цели должны быть выбраны не слишком общие, но и не совсем частные.
То есть «Зарегистрироваться в системе» — не цель, а скорее шаг, а «Достичь богатства и процветания» — слишком общая формулировка. В нашем примере идеальная цель — «заказать пиццу», потому что она с одной стороны не слишком общая, как, например «поесть», но и не слишком частная, как «заказать пиццу в приложении A».
Шаги для достижения каждой цели
Шаги описывают этапы достижения цели не в рамках разрабатываемого продукта. В этот момент надо абстрагироваться от функциональности и представить на высоком уровне, как ваша персона обычно достигает поставленной цели.
Здесь есть одно основное правило: если шаг можно пропустить, то это «фича» и ее стоит разместить ниже. Шагов не должно быть много. В идеале 3–5.
Реализация шагов (список «фич»)
Шаги разрабатываются от простого к сложному, на начальном этапе записываются все идеи. В конечном итоге каждый стикер из этого этапа — это конечная задача или эпик в Jira.
Далее проходит этап приоритезации карточек (списка «фич»). Все карточки разбиваются по релизам. Если определяется MVP, то необходимо выделить карточки, которые позволяют пользователю пройти шаги и достичь цели, но при этом разрабатываются минимальными средствами. Ниже пример из нашего логистического продукта, который показывает постепенное усложнение функциональности для прохождения шага.
Частые вопросы и сложности
- Роль администратора со стороны продукта следует рассматривать отдельно.
- В этой методологии не рассматриваются задачи, связанные с инфраструктурой продукта. Их можно определить отдельно, заведя колонку «Инфраструктурные задачи» рядом с пользовательскими историями, чтобы видеть полную картину задач для разработки.
- Оптимальное количество целей — 5. Если получается больше, лучше подумать еще раз и объединить их.
- Шагов для достижения цели не должно быть много. Не бойтесь переносить их в «фичи».
- Сессии User Story Map лучше разбить, чтобы каждая занимала не более двух часов. Лучше провести несколько встреч.
- Сначала следует расписать все роли, цели и шаги, а потом способы реализации по каждому шагу.
- Если карта строится для уже работающего продукта, необходимо сначала построить карту текущего состояния.
- Уведомительные письма не надо описывать отдельным шагом. Но стоит сразу проговорить с командой, что уведомительные письма включены по умолчанию в другие шаги.
Результат и дальнейшее использование
Результатом работы с User Story Map являются созданные в Jira и разбитые по релизам задачи (в Miro можно сразу привязать к карточке ссылку на задачу в Jira). Называть задачи стоит от первого лица по следующей формуле:
Я, как {роль}, хочу {название шага}, чтобы {цель}.
Например, «Я, как организатор торговой процедуры, хочу скачать предложения участников, чтобы представить результаты процедуры на тендерном комитете».
Каждая история должна быть завершенной и работать независимо от других.
