Руководство по сбору требований в формате User Story Mapping

Часть 1. Пользовательская история

Andrew Shapiro
Apr 5 · 9 min read

Что больше всего отличает опытного дизайнера и проектировщика от начинающего, так это способность грамотно «снимать задачу с клиента». Навык этот совокупный, нарабатывается, как и прочие, многократным подходом к снаряду. При этом ни новичок, ни опытный не защищены от ошибок. Хорошая методология помогает их избегать, делая обозримым то, что без неё с трудом влезало в голову.

В этой серии статей я хочу поделиться опытом применения наиболее крепкого и полезного, на мой взгляд, метода сбора требований к будущему цифровому продукту. Метод со мной уже девять лет. Работает прекрасно как в заказной, так и в продуктовой разработке. Я провёл сотни часов с заказчиками, записывая требования именно по этой методологии, поэтому в этих статьях содержится не только метод, но и рекомендации как проводить сессии с заказчиком.

Мне есть с чем сравнить. Приходилось писать и пространные ТЗ, и оттачивать запись полезного действия в формате понимания задачи, составлять дотошные сценарии использования, строить UML-диаграммы. С точки зрения выживаемости описанный ниже метод в моей личной практике обошёл все остальные.

Суть метода и его место

  1. Формализация проблемной ситуации и обнаружение продукта (Product Discovery).
  2. Проектирование, разработка, тестирование, внедрение.
  3. Эволюционирование путём прилаживания к реальности.

Первая фаза с обнаружением продукта чаще всего не заканчивается с началом разработки, и осознание продукта длится на протяжении нескольких, а то и всех циклов его эволюции. Тем, кто работает над проектом, важно разделять общее видение, договорённости о целях, ценностях и способах их достижения. Все эти сведения я буду называть для краткости требованиями.

User Story Mapping, далее USM или сторимаппинг — это метод сбора требований и планирования релизов программного продукта. Он сконцентрирован на пользовательских историях и задачах, связанных с ними.

На входе метода: гипотезы состава стейкхолдеров, их интересов и основных планируемых эффектов ближайшего релиза. Их важно получить заранее. Хорошо, если предварительно было сделано картирование процессов в форматах Customer Journey Map и/или Service Blueprint.

На выходе: набор задач на проектирование и разработку, привязанных к потоку пользовательских историй.

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

USM пришел из IT-сообщества, развивающего принципы Agile, в ответ на проблему, связанную с трудностями приоритезации и планирования работ над бездной историй. Первая версия метода описана в статье Джеффа Паттона — автора метода, проектировщика интерфейса, а ныне консультанта по работе над продуктами.

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

Структура пользовательской истории

Классически история записывается на самоклейку Post-it, чтобы не быть сложносочинённой — размеры бумажного формата помогают не растечься мыслью по древу. Запись ведётся в процессе беседы команды со всеми важными стейкхолдерами. Чтобы избежать фантазий проектировщиков и разработчиков, все участники беседы должны прийти к соглашению, что зафиксированная история отвечает целям и интересам всех стейкхолдеров.

До появления пользовательских историй использовался формат сценариев использования (Use Cases). К сожалению такие сценарии, лишены эмпатии к человеку, для которого создаётся программа. В сценариях использования его обычно называли презрительным и обезличенным «юзером». Чтобы исправить эту ситуацию апологеты гуманности в парадигме User Centered Design сместили акцент на роль человеческого фактора. Появился метод персон, помогающий создать модели групп будущих пользователей и хоть как-то передать команде разработки понимание целей, задач и чаяний людей, для которых создаётся продукт.

Любая пользовательская истории записывается для персоны или функциональной роли в системе. Самый просто пример двух различных функциональных ролей: продавец и покупатель. Иногда несколько ролей могут объединяться в одном человеке.

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

Классический шаблон

Я, как __роль/персона__,
хочу __действие__,
чтобы __ценность__.

Примеры:

Я, как рекламодатель, хочу привлекать для своих баннеров только трафик автомобильной тематики, чтобы эффективно использовать рекламный бюджет.Я, как спикер, хочу на время сделать свою электронную визитку доступной всем присутствующим в аудитории, чтобы не тратить время на раздачу и обеспечить актуальность данных.

Действующее лицо, способ достижения, ценность

Истории, записываемая для понятной всем роли или персоны, состоит из двух частей: ценности и способа её достижения.

Самая важная часть истории — ценностная. «Я как такой-то хочу сделать то-то, чтобы что?». Последняя часть рисует образ полезного действия, достигаемого в истории. Полезное действие помогает увидеть главную цель действующего лица, и направляет проектировщика на способы достижения этой цели.

Примеры:

[Бухгалтер] Понимает какую работу важно сделать в первую очередь, чтобы избежать штрафа в результате сдвига срока[Маркетолог] Видит воронку продаж на основе демонстрационных данных, чтобы разобраться в том как работает сервис; понимает, что важно подождать пока накопятся данные

Без ценности в историю можно записать любую ерунду, и это не будет заметно. Ценность — как лакмусовая бумажка для истории. Пока записываешь ценность, несколько раз переформулируешь и всю историю.

Например, кто-то формулирует историю как-то так.

[Продавец] Получает мгновенное уведомление о поступившем заказе

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

[Продавец] Узнаёт о новом заказе и оставшемся на его обработку времени, чтобы отреагировать вовремя и не упустить заказ

Если вопрос «зачем мгновенность» оставить без ответа, история будет содержать скрытый риск, который весьма вероятно увеличит количество итераций переделки. Лучше выяснить это до начала проектирования и разработки, иначе у вас история с миной замедленного действия:

[Продавец] Получает мгновенное уведомление о поступившем заказе, чтобы <неизвестный риск>
Пример USM без записи ценностей. Каждая карточка содержит слишком много предположений о действии, потому что не проведено согласование с ценностью

Избегание излишних ограничивающих подробностей

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

Ниже плохой вариант истории:

Получает пуш-уведомление :-( с информацией о входящем заказе, чтобы вовремя подготовить его к отправке

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

Выбор конкретных способов реализации зависит от имеющихся технологических и временных ресурсов. Лучше записать ту же историю более обще:

Вовремя узнаёт о входящем заказе, чтобы успеть подготовиться к его отправке

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

Предъявление и изменение данных — вот и весь ваш хвалённый IT

Я заметил, что все истории в разработке программного обеспечения распадаются на два класса. Все они про предъявление данных и манипуляцию ими. Мы либо что-то показываем, либо влияем каким-то образом на систему, либо делаем и то, и другое.

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

У каждого проектировщика или команды может сложиться свой набор.

Полезные форматы историй

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

Действие в форме глагола в третьем лице,
чтобы ценность

Пример:

Видит разницу между плановыми и фактическими расходами на бензин во времени и по территории, чтобы выяснить причины расхождений

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

Видит баланс счёта, чтобы понять сколько денежных средств осталось.
Модифицирует карточку товара, чтобы внести изменения

В этих случаях хорошо себя показали истории-вопросы и истории утверждения. Пару примеров историй-вопросов:

Сколько денежных средств на счёте?
Какой следующий пункт назначения в текущем рейсе?

Здесь ценность очевидна, а суть истории в том, что человек получает ответ на волновавший его вопрос.

Для сравнения ниже одна и та же история в классическом формате и формате истории-вопроса:

Классический формат
Логист видит какие строки файла не обработались по неизвестной нештатной причине, чтобы найти их и понять что с ними не так
Формат вопросов
Файл принят к парcингу?
Какие строки в файле содержат ошибки и что с этим делать?

То же самое относится и к историям про модификацию данных. Для простоты записи мы иногда используем такую форму утверждения:

Варианты историй-утверждений
— Вот мой номер телефона.
— Эти возвращенные товары получил!

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

Вместо того, чтобы __старое действие__,
__новое действие__

Историю про рекламодателя можно переписать в формате изменения:

Классический укороченный         
Привлекает только трафик определённой тематики, чтобы эффективно использовать рекламный бюджет
История-изменение
Вместо бесконтрольных трат бюджета, выбирает на какие тематики его потратить

Этот формат истории легко запомнить, представляя схему перехода от вреда к пользе: Бесконтрольные траты (вред) → расходы только на выбранные тематики (польза).

Критерии готовности истории

  • Соблюдён формат или история содержит все важные части: ценность, способ достижения, действующее лицо.
  • Формулировка несёт образ решения — при прочтении истории в воображении рождается одно или несколько вариантов решения, желание и готовность приступить к проектированию или разработке. Если остаются вопросы, следует переписать историю.

Как понять, что история спланирована или реализована полностью в определенной версии программного продукта? Здесь есть два способа. По одному из них на обороте стикера с историей записывают перечень критериев её готовности (Definition of Done). Другой — фиксировать все подробности отдельными карточки с детальными задачами под историей. Достижение полноты проверяется по этому перечню или набору карточек.


Другие статьи серии

  • Часть 3. Чистка историй от ложных требований. Критика метода
  • Переход от историй к реализации

Буду рад вашим замечаниям, критике и любым другим вариантам разговора на тему картирования историй и сбора требований. Комментируйте или пишите — andrew@ashapiro.ru

Andrew Shapiro

Written by

Interaction Designer, Art Director at http://Byndyusoft.com