book-open 1 test
UX-дизайн

Как построить карту историй (user story mapping), если проект уже в работе


Вы читаете перевод статьи “Mid-project Story Mapping Made Less Painful”. Над переводом работали: Ольга Жолудова и Ринат Шайхутдинов.

Если вы читали пост Дэвида про story mapping, то, скорее всего, загорелись идеей попробовать новый метод на практике. Обычно в этот момент начинают выползать самые разные страхи и сомнения.

Скорее всего вы думаете: “Проект уже запущен, неужели нужно все начинать сначала? И выбросить на ветер всю проделанную работу?” И вот вы все размышляете, как story mapping мог бы усилить ваш проект, и стоит ли оно того…

Что ж, ребята, хорошие новости! Даже если ваш проект уже в работе, вы все еще можете воспользоваться методом story mapping. Честно. Конечно, придется поработать, но оно того стоит.

Шаг 1. Строим карту (story map)

Начните с того, что имеете

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

Интересуетесь свежими статьями по продуктовому дизайну (UX/UI)? 🚀

Подписывайтесь на канал в Telegram | ВКонтакте, Instagram, Facebook

Если вы используете JIRA, VSTS/TFS или какой-то другой инструмент, просто распечатайте все свои тикеты. Да, даже закрытые (поймете, зачем они нужны, когда мы дойдем до шага “Заполнить пробелы”).

Далее, нужно рассортировать истории по группам, чтобы при необходимости вы быстро могли найти нужную. Не очень-то удобно перебирать стопку из 150 карточек в поисках той самой истории.  

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

Создайте карту пути пользователя (journey map)

Эта карта (journey map) будет скелетом карты историй (story map). Вам будет проще, если вы начнете работать с укрупненной картой пути пользователя, пока не вдаваясь в детали. Наша первая цель — наметить общий маршрут.  

Возьмите пачку стикеров, маркер и изоленту и забейте кусок стены. Для начала спросите себя: какой путь проходит пользователь в продукте? С чего он начинает? Самый простой подход — взять за основу путь основного персонажа. Каждый шаг пути мы будем писать на отдельном стикере.

Используйте существующие тикеты

Если вам встретятся какие-то шаги, которые уже есть в карточках пользовательских историй, не дублируйте их на стикерах, а просто приклейте карточки на скотч. Возможно, большинство шагов у вас уже есть. Если так, круто!!!

Вот так будет выглядеть ваша карта. Белые карточки — это распечатанные пользовательские истории из физического бэклога или из JIRА. Цветные квадратики — это новые стикеры.

Заполните пробелы

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

Тут-то и происходит все волшебство. Проблема бэклога на 150 тикетов в том, что все они разные по размеру и очередности. Здесь мы берем за основу 150 историй и равномерно распределяем по пути пользователя. С таким подходом легко обнаруживаются проблемные места. Вещи, которые мы считали никак не связанными, на самом деле оказываются взаимозависимыми. Мы обнаруживаем небольшие истории, которые можно объединить и легко закрыть в пределах одного спринта — и создать полезную фичу.

Как только соберете всю карту, начните искать темы, или, как мы называем их, “действия”. Это такие большие задачи, которые может осуществить пользователь и которые могут включать множество шагов. Сюда относятся такие крупные вещи, как “управлять письмом” или “обновить”.

Определите состав “релиза”

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

Итак, для начала убедимся, что этапы по каждому шагу расставлены по приоритету: маст-хэв опции должны быть сверху, а приятные мелочи — снизу. Затем возьмите изоленту и разметьте, какие этапы войдут в состав первого “релиза”.

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

Шаг 2. Упорядочиваем хаос

Очень важно правильно организовать карту, чтобы вы могли ее читать. Просто слова на стене выглядят слишком хаотично. Нужно, чтобы на основании карты вы могли рассказать простую историю, вдаваясь в детали только при необходимости, если это важно.

Эпик vs. История vs. Задача

Итак, действия в верхнем ряду считаются эпиками, “шаги” — историями, а то, что ниже — задачами? Или верхний ряд это что-то еще, а шаги — это эпики, а опции — истории? Короче, это не важно. Делайте так, как удобно вашей команде и как правильнее для вашего продукта. Если “шаги” можно завершить в рамках одного спринта, то они ближе к историям. А если они огромные и могут растянуться на 2-3 спринта — то это скорее эпики. Повторюсь, делайте так, как лучше вашей команде.

Цветовое кодирование персонажей

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

Поддерживаем актуальность карты

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

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