Руководство по сбору требований в формате User Story Mapping: Пользовательская история, 1/3

Инструменты проектирования

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

Цикл продуктовой разработки состоит примерно из следующих этапов.

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

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

Разберёмся с атомом USM — пользовательской историей. Это одна из нестрогих форм записи функциональных требований к программному обеспечению.

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

Вернёмся к историям. Классическим форматом является следующий:

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

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

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

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

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

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

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

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

С точки зрения технических систем, любой интерфейс — это трансмиссия — то, что передаёт информацию от передатчика к получателю и обратно.

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

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

Действие в форме глагола в третьем лице,
чтобы ценность
Видит разницу между плановыми и фактическими расходами на бензин во времени и по территории, чтобы выяснить причины расхождений
Видит баланс счёта, чтобы понять сколько денежных средств осталось.
Модифицирует карточку товара, чтобы внести изменения
Сколько денежных средств на счёте?
Какой следующий пункт назначения в текущем рейсе?
Классический формат
Логист видит какие строки файла не обработались по неизвестной нештатной причине, чтобы найти их и понять что с ними не так
Формат вопросов
Файл принят к парcингу?
Какие строки в файле содержат ошибки и что с этим делать?
Варианты историй-утверждений
— Вот мой номер телефона.
— Эти возвращенные товары получил!
Вместо того, чтобы __старое действие__,
__новое действие__
Классический укороченный         
Привлекает только трафик определённой тематики, чтобы эффективно использовать рекламный бюджет
История-изменение
Вместо бесконтрольных трат бюджета, выбирает на какие тематики его потратить

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

Как понять, что история закончена? Я смотрю на следующие индикаторы.

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

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

  • Часть 2. Алгоритм проведения и рекомендации для ведущего
  • Часть 3. Чистка историй от ложных требований. Критика метода
  • Переход от историй к реализации

--

--

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

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store