User story mapping что это
User Story Mapping – инструкция по применению
Четвертая статья из серии инструкций по инструментам, которые помогут сделать лучше ваши продукты и жизнь клиентов.
User Story Mapping (USM, карта пользовательских историй) – инструмент целостного проектирования продукта на основе пользовательского пути.
Для чего применяется USM?
Как построить User Story Mapping?
Для построения USM вам потребуется:
Ваша задача — спроектировать по шагам действия пользователя в продукте на основе его реального сценария.
Рассмотрим USM на примере
Магазин цветов решил запустить сайт. Визуализируем опыт клиентов с помощью техники USM.
Обратите внимание, что итоговый приоритет определяется сценарием пользователя. Мы идем слева направо, и только затем по версиям – ведь мы хотим принести больше ценности пользователю. А для пользователя, как правило, ценность тем выше, чем более полно наш продукт закрывает его сценарий.
User Story Mapping – мощный инструмент, позволяющий команде разработки за пару часов взглянуть на бэклог продукта глазами пользователя.
Руководство по сбору требований в формате User Story Mapping: Пользовательская история, 1/3
Инструменты проектирования
Apr 5, 2019 · 9 min read
Что больше всего отличает опытного дизайнера и проектировщика от начинающего, так это способность грамотно «снимать задачу с клиента». Навык этот совокупный, нарабатывается, как и прочие, многократным подходом к снаряду. При этом ни новичок, ни опытный не защищены от ошибок. Хорошая методология помогает их избегать, делая обозримым то, что без неё с трудом влезало в голову.
В этой серии статей я хочу поделиться опытом п рименения наиболее крепкого и полезного, на мой взгляд, метода сбора требований к будущему цифровому продукту. Метод со мной уже девять лет. Работает прекрасно как в заказной, так и в продуктовой разработке. Я провёл сотни часов с заказчиками, записывая требования именно по этой методологии, поэтому в этих статьях содержится не только метод, но и рекомендации как проводить сессии с заказчиком.
Мне есть с чем сравнить. Приходилось писать и пространные ТЗ, и оттачивать запись полезного действия в формате понимания задачи, составлять дотошные сценарии использования, строить UML-диаграммы. С точки зрения выживаемости описанный ниже метод в моей личной практике обошёл все остальные.
Суть метода и его место
Цикл продуктовой разработки состоит примерно из следующих этапов.
Первая фаза с обнаружением продукта чаще всего не заканчивается с началом разработки, и осознание продукта длится на протяжении нескольких, а то и всех циклов его эволюции. Тем, кто работает над проектом, важно разделять общее видение, договорённости о целях, ценностях и способах их достижения. Все эти сведения я буду называть для краткости требованиями.
User Story Mapping, далее USM или сторимаппинг — это метод сбора требований и планирования релизов программного продукта. Он сконцентрирован на пользовательских историях и задачах, связанных с ними.
На входе метода: гипотезы состава стейкхолдеров, их интересов и основных планируемых эффектов ближайшего релиза. Их важно получить заранее. Хорошо, если предварительно было сделано картирование процессов в форматах Customer Journey Map и/или Service Blueprint.
На выходе: набор задач на проектирование и разработку, привязанных к потоку пользовательских историй.
Метод предлагает фиксировать требования в виде двухмерной карты, где карточки с пользовательскими историями располагаются в хронологическом порядке, а соответствующие им задачи для команды разработки расположены под ними согласно росту глубины проработки. Принципы сбора требований и планирования на основе такой карты описаны ниже, а пока пару слов о том откуда появился метод.
USM пришел из IT-сообщества, развивающего принципы Agile, в ответ на проблему, связанную с трудностями приоритезации и планирования работ над бездной историй. Первая версия метода описана в статье Джеффа Паттона — автора метода, проектировщика интерфейса, а ныне консультанта по работе над продуктами.
Карта историй создаётся преимущественно для нового продукта, продукта, который мы собираемся сделать. Впрочем, карта может быть составлена и для действующего продукта, когда вы хотите его частично или полностью переделать и требуется описать объём имеющейся функциональности.
Структура пользовательской истории
Разберёмся с атомом USM — пользовательской историей. Это одна из нестрогих форм записи функциональных требований к программному обеспечению.
Классически история записывается на самоклейку Post-it, чтобы не быть сложносочинённой — размеры бумажного формата помогают не растечься мыслью по древу. Запись ведётся в процессе беседы команды со всеми важными стейкхолдерами. Чтобы избежать фантазий проектировщиков и разработчиков, все участники беседы должны прийти к соглашению, что зафиксированная история отвечает целям и интересам всех стейкхолдеров.
До появления пользовательских историй использовался формат сценариев использования (Use Cases). К сожалению такие сценарии, лишены эмпатии к человеку, для которого создаётся программа. В сценариях использования его обычно называли презрительным и обезличенным «юзером». Чтобы исправить эту ситуацию апологеты гуманности в парадигме User Centered Design сместили акцент на роль человеческого фактора. Появился метод персон, помогающий создать модели групп будущих пользователей и хоть как-то передать команде разработки понимание целей, задач и чаяний людей, для которых создаётся продукт.
Любая пользовательская истории записывается для персоны или функциональной роли в системе. Самый просто пример двух различных функциональных ролей: продавец и покупатель. Иногда несколько ролей могут объединяться в одном человеке.
Не стану приводить в этой статье примеры персон и способов их создания на эту тему написано достаточно. К тому же, насколько могу судить из опыта сообщества и собственного, персоны трудны в создании и валидации, они содержат множество лишних предположений. Мы, в Byndyusoft, преимущественно используем функциональные роли при записи историй. Далее буду обозначать субъекта истории действующим лицом — под ним может пониматься как персона так и функциональная роль.
Классический шаблон
Вернёмся к историям. Классическим форматом является следующий:
Действующее лицо, способ достижения, ценность
Важно понимать для какого действующего лица записывается история. Обычно действующее лицо «выносят за скобку», чтобы не повторять его в каждой карточке. Для этого над историями вешают карточку с изображением функциональной роли или персоны и подписью.
Истории, записываемая для понятной всем роли или персоны, состоит из двух частей: ценности и способа её достижения.
Самая важная часть истории — ценностная. «Я как такой-то хочу сделать то-то, чтобы что?». Последняя часть рисует образ полезного действия, достигаемого в истории. Полезное действие помогает увидеть главную цель действующего лица, и направляет проектировщика на способы достижения этой цели.
Без ценности в историю можно записать любую ерунду, и это не будет заметно. Ценность — как лакмусовая бумажка для истории. Пока записываешь ценность, несколько раз переформулируешь и всю историю.
Например, кто-то формулирует историю как-то так.
Образа решения не возникает, видение ситуации не передано. Почему здесь важна мгновенность? На этот вопрос нужно получить ответ в процессе сбора требований и записать его в виде ценности в историю. Например, выяснится, что заказ могут передать другому продавцу, если вовремя не отреагировать. Тогда впору записать историю так:
Если вопрос «зачем мгновенность» оставить без ответа, история будет содержать скрытый риск, который весьма вероятно увеличит количество итераций переделки. Лучше выяснить это до начала проектирования и разработки, иначе у вас история с миной замедленного действия:
Избегание излишних ограничивающих подробностей
Часть с описанием способа достижения полезного действия наиболее вариативна. Здесь в запись историй прокрадывается дизайн. Фиксируя определенный образ достижения полезного действия, мы постулируем один из вариантов работы системы. Важно это понимать и не привносить в историю излишне жестких ограничений. Ограничения важны для проектирования, однако лишние ограничения, возникшие из фантазий, отсекут хорошие решения. Излишняя детализация здесь возникает из-за того, что людям проще мыслить готовыми решениями. Пользователи будущей системы и стейкхолдеры выдают на-гора конкретные варианты того как именно должно быть исполнена история. Важно уйти от излишней конкретики и записать историю без подробностей реализации.
Чтобы избежать лишних подробностей и ограничений на уровне языка интерфейса, рекомендуется избегать названий интерфейсных элементов и паттернов в тексте историй.
Ниже плохой вариант истории:
Плохой, потому что содержит излишнее ограничение на уровне подходов в реализации: пуш-уведомление — это конкретный приём подачи сообщения на мобильных устройствах.
Выбор конкретных способов реализации зависит от имеющихся технологических и временных ресурсов. Лучше записать ту же историю более обще:
Предъявление и изменение данных — вот и весь ваш хвалённый IT
С точки зрения технических систем, любой интерфейс — это трансмиссия — то, что передаёт информацию от передатчика к получателю и обратно.
Я заметил, что все истории в разработке программного обеспечения распадаются на два класса. Все они про предъявление данных и манипуляцию ими. Мы либо что-то показываем, либо влияем каким-то образом на систему, либо делаем и то, и другое.
Исходя их вышесказанного, чаще всего одни и те же слова попадают в запись историй. Вот примеры глаголов, которые мы чаще всего используем в записи историй:
У каждого проектировщика или команды может сложиться свой набор.
Полезные форматы историй
При записи историй удобно придерживаться шаблонов. Это помогает не упустить важного и окупается когда вы, зная форматы, расходуете меньше внимания на поиск того как записать только что озвученное. Особенно это важно, если вы только начинаете использовать картирование историй для сбора требований. Вот несколько форматов, которые показали себя хорошо на практике.
Классический укороченный
В этом шаблоне как и во всех остальных далее действующее лицо вынесено за пределы карточки. В формате также опущен глагол «хочу», записывается сразу действие и ценность.
Вопросы и утверждения
Большинство историй на демонстрацию и изменение данных будет казаться неуклюжими для записи в классической форме из-за того, что записываемая ценность кажется самоочевидной. Если записывать по классике, получается масло-масленное:
В этих случаях хорошо себя показали истории-вопросы и истории утверждения. Пару примеров историй-вопросов:
Здесь ценность очевидна, а суть истории в том, что человек получает ответ на волновавший его вопрос.
Для сравнения ниже одна и та же история в классическом формате и формате истории-вопроса:
То же самое относится и к историям про модификацию данных. Для простоты записи мы иногда используем такую форму утверждения:
Истории про изменение
Зачастую ценность описать проще, если показать два состояния системы: текущее с проблемой и новое — лишенное проблемы. В этом случае пригождается формат историй на изменение:
Историю про рекламодателя можно переписать в формате изменения:
Этот формат истории легко запомнить, представляя схему перехода от вреда к пользе: Бесконтрольные траты (вред) → расходы только на выбранные тематики (польза).
Критерии готовности истории
Как понять, что история закончена? Я смотрю на следующие индикаторы.
Как понять, что история спланирована или реализована полностью в определенной версии программного продукта? Здесь есть два способа. По одному из них на обороте стикера с историей записывают перечень критериев её готовности (Definition of Done). Другой — фиксировать все подробности отдельными карточки с детальными задачами под историей. Достижение полноты проверяется по этому перечню или набору карточек.
Гайд по User Stories для Junior BA / PO / PM
Статья будет полезная Junior-специалистам, которые так или иначе работают с документацией на проекте. В статье рассматриваются как сами пользовательские истории, так и критерии, по которым можно написать хорошую историю. Из статьи читатель сможет подчерпнуть и как писать истории, и как правильно дополнить их деталями, и какие детали важны, и как не перегрузить историю.
Содержание:
Вводная информация о User Stories
Что такое User Stories
Сейчас User Stories являются одним из главных приемов работы бизнес-аналитиков и Product Owner. Бизнес-стейкхолдеры рассказывают эти истории, чтобы показать команде разработки суть и ценность задачи, которую надо реализовать. Они короткие, написаны деловым языком и поэтому понятны всем заинтересованным лицам проекта.
Дать емкое определение этому приёму сложно. Его внешняя простота заставляет сводить его описание к внешним характеристикам. Поэтому я, как автор, хотел бы дать читателю несколько определений.
В качестве первого ответа приведем «официальное» определение из книги М. Кона «Пользовательские истории: гибкая методология разработки ПО».
Пользовательские истории — это краткое описание функциональности, детали которой должны уточняться в ходе устных обсуждений между заинтересованными лицами проекта.
Такое определение не помогает разобраться в сути приема и его распространенности среди пользователей. Неужели главное — это записи или то, что детали должны уточняться? Думаю, нет. Поэтому я не бросил копания и начал смотреть другие источники. Множество сайтов предлагает такое определение:
Этот ответ тоже не удовлетворил моё любопытство. Такое определение ставит во главу угла формат. Ведь User Story может существовать и без какой-то части (As a user, I want to save data) и быть написанной без обсуждения интровертным продакт-овнером. Но самое главное — об этом будет ниже — User Story может быть написана по совершенно иному формату!
Пройдя круг обсуждений с ментором, прочитав и посмотрев много статей и видео, я понял, что главное в пользовательской истории — это ценность, которую пользователь получит от функции. Поэтому я попытался сгенерировать определение:
Очень важно отметить, что история и ее ценность может быть направлена не только на какую-то группу пользователей. Она может быть направлена на команду разработки (обновить компонент, добавить компонент, переделать код. ), Product Owner или представителей бизнеса.
Далее в статье я использую однострочные примеры пользовательских историй: «Как Х, я хочу Y, чтобы Z«. Тем не менее, многие аналитики использую другой подход, который считается даже более каноничным.
Так, истории пишутся в три строки:
Job Stories
В целом Job Stories — схожая с US техника. Можно назвать их приёмом-субститутом, ведь обычно они не используются вместе и выполняют максимально похожую функцию. Job Stories представляют требование в виде действия, которое выполняет пользователь. Они не описывают саму функцию, а лишь концентрируют внимание команды на потребности.
Job Stories концентрируются на психологической части фичи, на эмоциях, тревогах и прочем, что может возникнуть во время использования функции.
«Тело» JS делится на три части:
Situation: дает контекст обо всей JS, который помогает dev-команде придумать возможное решение.
Motivation: описывает невидимую руку, которая ведет юзера к использованию данной функции.
Expected Outcome: описывает, что получит юзер после использования функции.
Job Stories могут писаться по двум форматам:
В одну строку:
When X I want to Y so I can Z» или «When X, actor is Y so that Z.
В три строки:
When X
I want to Y
So I can Z.
When I want to withdraw money from my bank account, I want to know I have enough money in my account to withdraw some now so that I can go out to dinner with my friends.
Вопросы, которые следует задавать во время написания стори
Решает ли это настоящую проблему юзера?
Есть ли у такого решения какие-либо side effects? Влияет ли это на продукт в целом?
Какие последствия от такого решения?
А при работе с другими стейкхолдерами и выяснении первопричин нужды у них аналитик может использовать знаменитый приём «5 почему?».
Пример работы техники «5 почему».
Три С в User Story
Первое определение говорит о коммуникации и карточках, но не упоминает согласие. Эти три понятия образуют «the 3 C’s of User Stories».
Card — по задумке автора метода истории пишутся на физических карточках. В реальности они пишутся в Jira и Confluence, поэтому мы не так ограничены в детальности.
Conversation — каждая стори — это множество митингов вокруг нее, которые и направлены на понимание деталей.
Confirmation — перед началом работы клиент дает согласие на данное решение, а команда полностью уверена в выполнимости решения.
User Personas
Этот метод представляет собой детализированное описание пользователя продукта. Описание пользователя должно быть конкретным и детальным, ведь по его описанию члены команды должны понять, что это целевая аудитория приложения, которое они делают.
Создавая четкого и детального персонажа, аналитик требований или Product Owner уменьшает вероятность того, что нужды пользователя будут забыты или заменены на нужды тех членов проектной команды, которые ставят себя на место пользователей.
Карточка персонажа не обязана быть полностью правильной, но она обязана содержать максимальное количество деталей.
Наиболее важными деталями персонажа являются его имя, место работы (роль в системе), место проживания. Причём имя и роль в будущем могут использоваться и при написании историй:
Как Георгий, я хочу печатать документы, чтобы я мог работать над ними вне компьютера.
Стоит также отразить маркетинговые характеристики персонажа такие как предпочитаемые бренды, блюда, увлечения и хобби. Эти характеристики важны не только, чтобы знать для кого мы создаем ПО, но и как его рекламировать и продавать. Описание должно также раскрывать и характер персонажа. Он веселый или чаще хмурится? Он делится информацией в соцсетях или вовсе не ведет их?
В описании следует отразить и задачи, которые наиболее важны для персонажа в его работе с системой. Это поможет всей команде увидеть нужды персонажа и поможет создать стимул для покупки премиум-версии или подписки.
Не стоит забывать и об еще одной важной детали. Персонажи не могут «гулять» из продукта в продукт, но человек, который создаёт их описание, может обращаться к давно созданным образам как за вдохновением, так и за шаблоном описания.
Создав одного персонажа, можно отдохнуть и насладиться проделанной работой. Однако не стоит останавливаться, так как именно набор персонажей (от 3 до 10) поможет в будущем выстроить систему, которая поможет приоритизировать истории, благодаря пониманию того, что нужно тому или другому персонажу. А если что-то нужно двум из трех персонажей, то следует бросить все силы на эту функцию.
Что же в сухой практике использования User Personas?
Отрицательный персонаж
Не все персонажи должны создаваться, чтобы показать пользователей системы. Задача некоторых указать, кому в приложении нет места.
Создавая любое приложение для такси, мы вспомним, что в процессе заказа традиционно есть 3 участника: клиент, водитель, оператор. Скорее всего, задачей нашего приложения будет автоматизация работы оператора так, чтобы клиент мог связаться с водителем напрямую. В таком случае самому оператору в системе не будет места.
Ключевой персонаж
Ключевыми персонажами являются те, для кого и будет проводиться проектирование решения. Такой персонаж олицетворяет группу пользователей, которая будет либо чаще всего пользоваться приложением, либо имеет какие-то особенности, из-за которых им следует пользоваться приложением иначе. Такие персонажи заслуживают отдельных интерфейсов в системе.
Давайте вернемся к приложению для саппорта. В нем оба персонажа, которые всё-таки будут пользоваться системой, будут ключевыми. Так, тому, кто будет устранять жалобы, нужен интерфейс, который показывает жалобы и помогает выстроить маршрут. В тоже время клиенту, скорее всего, нужно посмотреть все его жалобы и оставить новую.
INVEST
По критериям INVEST мы можем судить, хорошо ли написана User Story и можно ли над ней работать.
I — Independent — Независимый
Следует избегать зависимости между историями, так как иногда это приводит к проблемам во время имплементации. (пример: задача А не может быть реализована без задачи Б, однако задача А — очень важна, а Б лишь желательно иметь в готовом продукте).
На практике это стремление не всегда достижимо. Например, в случае зависимости нескольких историй друг от друга, следует искать другой способ разбить их.
Мы хотим добавить в наш продукт поддержку банковских карт MasterCard, Visa и третьей системы. Тогда проще всего разделить эту стори на три. В первой, самой большой, разработчик должен добавить поддержку банковских карт в целом и какую-то из списка. А остальные две могут пойти в другую стори, которая зависит от первой.
N — Negotiable — Обсуждаемый
После написания черновика истории следует обсудить ее со стейкхолдерами и, возможно, внести изменения, исправить ошибки. В ходе обсуждения команда ещё не говорит о том, как данная история будет реализована, а обсуждается лишь то, как будет удовлетворяться нужда пользователя.
V — Valuable — Ценный
Каждая User Story должна нести пользу как пользователю, так и продукту, а описание должно создаваться так, чтобы ценность была наиболее очевидна. Так команда разработки будет понимать, зачем это нужно реализовывать.
Если ценность историй, которые несут новый функционал или улучшают старый, очевидна, то с теми, которые завязаны на технической стороне продукта, не все так очевидно. Но и истории, в рамках которой команда избавляется от легаси-кода, делает рефакторинг или переносит старый функционал на новую инфраструктуру (например, в новую базу данных) несут ценность для как для продукта, так и для пользователя. Скорее всего, пользователь ощутит их благодаря улучшению отзывчивости или скорости работы системы. Это следует отразить в описании такой задачи.
E — Estimable — Оцениваемый
История должна быть настолько ясно написана, чтобы у разработчика было достаточно понимания ведь без него он сможет выдать оценку, близкую к правде. Есть три причины, почему dev не может выдать оценку:
история слишком большая;
в описании недостаточно данных;
разработчику нужно больше опыта.
Однако подробнее об оценках поговорим в отделе “Оценка историй”.
S — Small — Компактный
Этот пункт говорит не о самом описании под историей, а о ее размере, времени на реализацию. На многих проектах команды устанавливают рамки, в которые должна уместиться история. Так, часто можно услышать о правиле, согласно которому история должна укладываться в рабочий день. Однако на других же пользовательской историей может считаться функция, на реализацию которой нужно несколько месяцев времени разработчика.
T — Testable — Тестируемый
Суть этого пункта не только в том, что команда тестировщиков должна понимать, что проверять, но и в том, что пользовательская история должна обладать чем-то, что можно посмотреть, запустить.
Однако не стоит забывать, что стоит писать истории так, чтобы QA-команда могла понять, какие кейсы и сценарии ей тестировать. Для создания этого понимания аналитику требований следует пользоваться критериями приемки и описанием сценариев по Gherkin. Подробнее об этих приемах можно прочитать в разделе “Как добавить деталей к истории”.
Как добавить деталей к истории?
Очень важно понимать, что когда работа над «телом» стори закончена, начинается работа над деталями, которые и помогут команде понять, что надо реализовать. Среди способов добавить детали самыми знаменитыми являются Acceptance Criteria и сценарии по Gherkin.
Acceptance Criteria
Что такое АС
Элемент User Stories, который дополняет их так, что команда начинает видеть историю в деталях. Этот инструмент помогает понять, что должно быть сделано, чтобы удовлетворить потребность бизнеса.
АС помогают увидеть фичу с точки зрения конечного пользователя, установить границы фичи и создать понимание того, что должно быть сделано и что будет проверяться.
Их надо понимать максимально буквально, потому что это те критерии по которым мы понимаем, выполнена история или нет.
Для чего нужны
Показывают фичу с точки зрения конечного юзера.
Для понимания задач бизнеса.
Достижения консенсуса с бизнесом относительно какой-то стори.
Служат базой для тестов.
Помогают эстимировать стори.
Правила написания
Мы пишем их не в форме should, а в настоящем времени (суть в том, что человек читает и видит, какими «способностями» обладает юзер или система).
Должны быть измеримы.
Пишутся ДО работы над задачей.
Включают функциональные и нефункциональные критерии.
Пользователь может выбрать цвет. Пример: есть дропдаун с цветами.
Не слишком узкие (привязаны к одному юз-кейсу-примеру) и не слишком широкие (понятно где сделано и как работает).
Не содержат технического арго.
Что делать, когда надо выбрать одно из нескольких решений?
Тогда на помощь приходит Evaluation Criteria. Используются, чтобы оценить ценность нескольких решений и выбрать нужное.
Компания хочет пообедать в итальянском веганском ресторане, где играет живая испанская гитара. Тогда ресторан, который подойдёт, должен соответствовать трем критериям:
1. Ресторан должен быть итальянским.
2. Ресторан должен быть должен подавать вегетарианские блюда.
3. В ресторане играет живая испанская гитара.
Gherkin
Scenario: Dr Bill posts to his own blog.
GIVEN I am logged in as Dr Bill
WHEN I try to post to my blog
THEN I should see «Your article was published»
Базовый синтаксис Gherkin
1) Пишется сценарий-скелет.
Scenario Outline: Dr Bill posts to his own blog.
Given I Have published
When I try to post a new blog
Then I should see
2) Создается таблица с примерами.
В данном примере мы должны показать связь между количеством постов в блоге и тем, какое сообщение увидит пользователь.Например: