Тут мы рассмотрели Impact Map — быстрый рабочий способ выработать черновой скоуп решения и окружающего его контекста на базе исходных бизнес-целей. Сегодня поговорим о User Story Map как о технике для более глубокой проработки и визуализации скоупа, выродившегося из Impact Map (если пользовать их в связке), или технике для проработки скоупа с нуля (если использовать US Map как самостоятельную боевую приблуду).
Что такое User Story Map? Несложный перевод кричит, что это карта пользовательских историй. Т. е. это некая визуальная модель, которая показывает пользовательские истории (а это единички скоупа в Agile-разработке) упорядоченными определенным образом. Как артефакт US Map — это набор пользовательских историй, систематизированных в двух разрезах: месту в логическом пути пользователя системы и приоритету с позиции ценности для пользователя.
Как нам прийти к описанному результату?
1) Понять, кто наши пользователи, и структурировать их, т. е. классифицировать по какому-либо признаку. В системах для автоматизации деятельности организаций таким признаком чаще всего выступают роли. Сразу оговорюсь, что это не только для данного класса применимо — роли могут прослеживаться во многих IT-решениях, вне зависимости от предназначения, плюс вместо ролей могут быть права доступа или иные единицы, реализующие авторизацию, но давайте упростим и будем использовать именно «роли» как механизм разграничения прав доступа в этой заметке. Роли определяются задачами, которые пользователи должны выполнять в системе.
Для масс-продуктов роли зачастую не выделимы: например, для Калькулятора Windows все пользователи имеют одинаковые права в плане доступа к нему. В таких случаях можно использовать персоны — технику сегментации целевой аудитории по «человеческим», признакам: возраст, пол, семейное положение и т. п. — в зависимости от того, что является теми признаками, которые определят разные сценарии использования системы. И снова оговорка: персоны — это самостоятельная UX-техника, и она не противоречит ролям. Никто не мешает использовать ее и в дополнение к ролям в системах, где есть разграничение прав доступа. Просто чаще всего по наблюдениям аналитики прибегают к ней именно в описанной ситуации.
Для примера из предыдущей статьи, если мы изучим актеров (второй уровень Impact Map) и то, будут ли они пользоваться системой (четвертый уровень), вырисовываются следующие роли:
- Сотрудник
- Повар
- Бухгалтер (назовем сотрудника отдела учета расходов для упрощения так)
Если применим магию анализа, то придем к тому, что кому-то также необходимо будет админить систему — в частности, управлять пользовательскими аккаунтами перечисленных выше ролей, а потому добавим сюда и четвертую роль:
- Администратор
2) Первый уровень US Map — это цели пользователей (user goals или user activities). Для каждой категории пользователей из п. 1 выше нам нужно сформулировать их крупные цели в системе и расположить их в логическом порядке пользования системой, слева-направо.
Давайте их выделим и расположим на картинке, взяв черновой скоуп, который мы сгенерировали через Impact Map, и закрывая на ходу пробелы. Я использовал Miro и шаблон для User Story Map для Miro, который легко находится поиском в Интернете, но есть море альтернатив.
3) Далее для каждой цели определим путь, который пользователю необходимо или который пользователь может пройти (user journey), в виде крупных шагов на пути к цели. Это будет вторым уровнем карты. Упорядочим их также в порядке логического прохождения слева-направо.
Пока что не стоит сильно заморачиваться на том, насколько аккуратно мы декомпозировали шаги. Успеем позже этим заняться.
4) На третьем уровне опишем, что в деталях пользователю нужно сделать в решении, чтобы выполнить шаг второго уровня. Т. е. декомпозируем шаги на более гранулярные единицы. По факту на этом этапе мы формулируем user stories. Поэтому либо сейчас и сразу, либо на следующем шаге (в зависимости от прокачанности и навыков параллелизма), можно пользоваться известными рекомендациями (например, INVEST) и собственными наработанными практиками по декомпозиции user stories. Данная статья не о том, какими должны быть US, но в Телеграм-канале мы уже говорили о об этом:
В рамках шага, для которого формулируем user stories, упорядочим истории по вертикали от наиболее приоритетных (ценных для пользователя) к менее приоритетным.
- Заметка о декомпозиции user stories
- Ошибки в формировании скоупа (включая US): тут, тут и тут
- Частые ошибки в проработке US: тут, тут, тут, тут и аж тут
В рамках шага, для которого формулируем user stories, упорядочим истории по вертикали от наиболее приоритетных (ценных для пользователя) к менее приоритетным.
5) Теперь пора «причесать» карту. Основное, что нам нужно от нее получить, — это контент для product backlog, т. е. epics (на базе шагов из уровня 2), user stories (пункты в уровне 3) и их приоритизацию. А потому, пользуясь нашим опытом или же теорией о том, какими должны быть эпики и US (см. предыдущий шаг) самое время сделать следующее:
- Убрать дублирующиеся эпики и истории и перегруппировать, если видится в этом удобство для формирования бэклога.
- Переформулировать/поменять названия на однозначные, понятные и, желательно, уникальные.
- Поменять разбивку, если видится резонным. Эпики — это всего лишь структуризация US по областям. В многоуровневой структуризации, например, не особо много смысла в плане наглядности, если в эпике — одна история или, наоборот, сотня.
- Обеспечить историям INVEST и любые иные практически ценные для нас качества, если не думали об этом на предыдущем этапе. Сделать их относительно независимыми, самостоятельно ценными и хотя бы более-менее небольшими для удобства планирования и разработки. Качественнее мы это еще успеем сделать в дальнейших активностях на проекте, поэтому пока — предварительно.
6) На последнем шаге мы можем отметить план релизов на этой карте или как минимум выделить MVP.
Итоговая карта у нас выглядит вот так (разделитель отделяет MVP от того, что пойдет в бэклог "на будущее"):
Что ещё хочется отметить:
1) Можно ваять одну большую карту или несколько карт поменьше — для каждой категории пользователей в отдельности.
2) В примере выше, как и с Impact Mapping ранее, я «думал» в одно лицо. Но продублирую тут кусок из предыдущей заметки: лучше всего agile-техники работают тогда, когда вы делаете это совместно с ключевыми стейкхолдерами. Как понимаете, если идеи для контента будут генерировать еще и заказчик, его сведущие люди, представители пользователей, плюс умные люди с вашей стороны (UX-специалист и лид-девелоперы, например), шансы на полноту и релевантность актуальным потребностям пользователей, а также на верную приоритизацию, резко возрастут.
3) Контент для каждого этапа можно вырабатывать с разной степенью тщания. "Подумать" индивидуальным или коллективным разумом в рамках воркшопа — это наиболее простой вариант. Однако усложнениям нет предела: персоны можно прорабатывать долго и усиленно, эмпатируя целевым пользователям; сценарии для формирования целей, эпиков и US также можно вырабатывать не просто брейнстормя шаги, а по факту качественного ресерча целевой аудитории, проведения опросов , интервью и прочих исследований. Естественно, чем тщательнее команда подойдет к получению входной в карту информации, тем надежнее получится скоуп.
Но вернемся к теме заметок — как сформировать скоуп быстро и сердито — и подытожим связку из двух техник:
Но вернемся к теме заметок — как сформировать скоуп быстро и сердито — и подытожим связку из двух техник:
- Собираем заказчика, представителей юзеров (при их доступности) и ключевых членов вашей команды на воркшоп по Impact Mapping. Туда желательно идти с пониманием целей проекта, но можно обсудить и выработать и на нем. Impact Map поможет из целей выработать черновой скоуп решения, плюс сопутствующие организационные и иные изменения у стейкхолдеров, необходимые, чтобы решение завелось и работало.
- Снова собираем тех же людей на воркшоп, но теперь уже с фокусом на более глубокую проработку скоупа именно IT-решения (которое, скорее всего, и будет единственной зоной ответственности вашей команды), где строим с ними User Story Map. User Story Map даст наполнение бэклога (скоуп) в виде эпиков и историй, установит начальные приоритеты единиц скоупа и сфокусирует всех участников на том, с какого по объёму релиза будем стартовать.
