СЕРИЯ «ИНСТРУМЕНТЫ ПРОЕКТИРОВАНИЯ»
User Story Mapping. Обзор и форматы историй
Полное руководство по сбору требований в формате User Story Mapping. 1-я статья
Что больше всего отличает опытного дизайнера и проектировщика от начинающего, так это способность грамотно «снимать задачу с клиента». Навык этот совокупный, нарабатывается, как и прочие, многократным подходом к снаряду. При этом ни новичок, ни опытный не защищены от ошибок. Хорошая методология помогает их избегать, делая обозримым то, что без неё с трудом влезало в голову.
В этой серии статей я хочу поделиться опытом применения наиболее крепкого и полезного, на мой взгляд, метода сбора требований к будущему цифровому продукту. Метод со мной уже девять лет. Работает прекрасно как в заказной, так и в продуктовой разработке. Я провёл сотни часов с заказчиками, записывая требования именно по этой методологии, поэтому в этих статьях содержится не только метод, но и рекомендации как проводить сессии с заказчиком.
Мне есть с чем сравнить. Приходилось писать и пространные ТЗ, и оттачивать запись полезного действия в формате понимания задачи, составлять дотошные сценарии использования, строить UML-диаграммы. С точки зрения выживаемости описанный ниже метод в моей личной практике обошёл все остальные.
В этой серии статей я хочу поделиться опытом применения наиболее крепкого и полезного, на мой взгляд, метода сбора требований к будущему цифровому продукту. Метод со мной уже девять лет. Работает прекрасно как в заказной, так и в продуктовой разработке. Я провёл сотни часов с заказчиками, записывая требования именно по этой методологии, поэтому в этих статьях содержится не только метод, но и рекомендации как проводить сессии с заказчиком.
Мне есть с чем сравнить. Приходилось писать и пространные ТЗ, и оттачивать запись полезного действия в формате понимания задачи, составлять дотошные сценарии использования, строить UML-диаграммы. С точки зрения выживаемости описанный ниже метод в моей личной практике обошёл все остальные.
Суть метода и его место
Цикл продуктовой разработки состоит примерно из следующих этапов.
Первая фаза с обнаружением продукта чаще всего не заканчивается с началом разработки, и осознание продукта длится на протяжении нескольких, а то и всех циклов его эволюции. Тем, кто работает над проектом, важно разделять общее видение, договорённости о целях, ценностях и способах их достижения. Все эти сведения я буду называть для краткости требованиями.
User Story Mapping, далее USM или сторимаппинг — это метод сбора требований и планирования релизов программного продукта. Он сконцентрирован на пользовательских историях и задачах, связанных с ними.
На входе метода: гипотезы состава стейкхолдеров, их интересов и основных планируемых эффектов ближайшего релиза. Их важно получить заранее. Хорошо, если предварительно было сделано картирование процессов в форматах картография процесс-опыт, Customer Journey Map, Service Blueprint или BPMN.
На выходе: набор задач на проектирование и разработку, привязанных к потоку пользовательских историй.
Метод предлагает фиксировать требования в виде двухмерной карты, где карточки с пользовательскими историями располагаются в хронологическом порядке, а соответствующие им задачи для команды разработки расположены под ними согласно росту глубины проработки. Принципы сбора требований и планирования на основе такой карты описаны ниже, а пока пару слов о том откуда появился метод.
- Формализация проблемной ситуации и обнаружение продукта (Product Discovery).
- Проектирование, разработка, тестирование, внедрение.
- Эволюционирование путём прилаживания к реальности.
Первая фаза с обнаружением продукта чаще всего не заканчивается с началом разработки, и осознание продукта длится на протяжении нескольких, а то и всех циклов его эволюции. Тем, кто работает над проектом, важно разделять общее видение, договорённости о целях, ценностях и способах их достижения. Все эти сведения я буду называть для краткости требованиями.
User Story Mapping, далее USM или сторимаппинг — это метод сбора требований и планирования релизов программного продукта. Он сконцентрирован на пользовательских историях и задачах, связанных с ними.
На входе метода: гипотезы состава стейкхолдеров, их интересов и основных планируемых эффектов ближайшего релиза. Их важно получить заранее. Хорошо, если предварительно было сделано картирование процессов в форматах картография процесс-опыт, Customer Journey Map, Service Blueprint или BPMN.
На выходе: набор задач на проектирование и разработку, привязанных к потоку пользовательских историй.
Метод предлагает фиксировать требования в виде двухмерной карты, где карточки с пользовательскими историями располагаются в хронологическом порядке, а соответствующие им задачи для команды разработки расположены под ними согласно росту глубины проработки. Принципы сбора требований и планирования на основе такой карты описаны ниже, а пока пару слов о том откуда появился метод.
Фрагмент типичной карты User Story Mapping (USM) из проекта системы обработки логистических заказов
USM пришел из IT-сообщества, развивающего принципы Agile, в ответ на проблему, связанную с трудностями приоритезации и планирования работ над бездной историй. Первая версия метода описана в статье Джеффа Паттона — автора метода, проектировщика интерфейса, а ныне консультанта по работе над продуктами.
Карта историй создаётся преимущественно для нового продукта, продукта, который мы собираемся сделать. Впрочем, карта может быть составлена и для действующего продукта, когда вы хотите его частично или полностью переделать и требуется описать объём имеющейся функциональности.
Карта историй создаётся преимущественно для нового продукта, продукта, который мы собираемся сделать. Впрочем, карта может быть составлена и для действующего продукта, когда вы хотите его частично или полностью переделать и требуется описать объём имеющейся функциональности.
§1. Пользовательская история
Структура пользовательской истории
Разберёмся с атомом USM — пользовательской историей. Это одна из нестрогих форм записи функциональных требований к программному обеспечению.
Классически история записывается на самоклейку Post-it, чтобы не быть сложносочинённой — размеры бумажного формата помогают не растечься мыслью по древу. Запись ведётся в процессе беседы команды со всеми важными стейкхолдерами. Чтобы избежать фантазий проектировщиков и разработчиков, все участники беседы должны прийти к соглашению, что зафиксированная история отвечает целям и интересам всех стейкхолдеров.
До появления пользовательских историй использовался формат сценариев использования (Use Cases). К сожалению такие сценарии, лишены эмпатии к человеку, для которого создаётся программа. В сценариях использования его обычно называли презрительным и обезличенным «юзером». Чтобы исправить эту ситуацию апологеты гуманности в парадигме User Centered Design сместили акцент на роль человеческого фактора. Появился метод персон, помогающий создать модели групп будущих пользователей и хоть как-то передать команде разработки понимание целей, задач и чаяний людей, для которых создаётся продукт.
Любая пользовательская истории записывается для персоны или функциональной роли в системе. Самый просто пример двух различных функциональных ролей: продавец и покупатель. Иногда несколько ролей могут объединяться в одном человеке.
Не стану приводить в этой статье примеры персон и способов их создания на эту тему написано достаточно. К тому же, насколько могу судить из опыта сообщества и собственного, персоны трудны в создании и валидации, они содержат множество лишних предположений. Мы, в Byndyusoft, преимущественно используем функциональные роли при записи историй. Далее буду обозначать субъекта истории действующим лицом — под ним может пониматься как персона так и функциональная роль.
Классически история записывается на самоклейку Post-it, чтобы не быть сложносочинённой — размеры бумажного формата помогают не растечься мыслью по древу. Запись ведётся в процессе беседы команды со всеми важными стейкхолдерами. Чтобы избежать фантазий проектировщиков и разработчиков, все участники беседы должны прийти к соглашению, что зафиксированная история отвечает целям и интересам всех стейкхолдеров.
До появления пользовательских историй использовался формат сценариев использования (Use Cases). К сожалению такие сценарии, лишены эмпатии к человеку, для которого создаётся программа. В сценариях использования его обычно называли презрительным и обезличенным «юзером». Чтобы исправить эту ситуацию апологеты гуманности в парадигме User Centered Design сместили акцент на роль человеческого фактора. Появился метод персон, помогающий создать модели групп будущих пользователей и хоть как-то передать команде разработки понимание целей, задач и чаяний людей, для которых создаётся продукт.
Любая пользовательская истории записывается для персоны или функциональной роли в системе. Самый просто пример двух различных функциональных ролей: продавец и покупатель. Иногда несколько ролей могут объединяться в одном человеке.
Не стану приводить в этой статье примеры персон и способов их создания на эту тему написано достаточно. К тому же, насколько могу судить из опыта сообщества и собственного, персоны трудны в создании и валидации, они содержат множество лишних предположений. Мы, в Byndyusoft, преимущественно используем функциональные роли при записи историй. Далее буду обозначать субъекта истории действующим лицом — под ним может пониматься как персона так и функциональная роль.
Классический шаблон
Вернёмся к историям. Классическим форматом является следующий:
Я, как <роль/персона>, хочу <действие>, чтобы <ценность>.
Примеры историй в этом классическом шаблоне:
Я, как рекламодатель, хочу привлекать для своих баннеров только трафик автомобильной тематики, чтобы эффективно использовать рекламный бюджет.
⎯
Я, как спикер, хочу на время сделать свою электронную визитку доступной всем присутствующим в аудитории, чтобы не тратить время на раздачу и обеспечить актуальность данных.
⎯
Я, как спикер, хочу на время сделать свою электронную визитку доступной всем присутствующим в аудитории, чтобы не тратить время на раздачу и обеспечить актуальность данных.
Действующее лицо, способ достижения, ценность
Важно понимать для какого действующего лица записывается история. Обычно действующее лицо «выносят за скобку», чтобы не повторять его в каждой карточке. Для этого над историями вешают карточку с изображением функциональной роли или персоны и подписью.
Фрагмент карты USM. Логист — действующее лицо. Он вынесен на самый верхний уровень на эпиками и историями. Все истории с этого места и далее направо относятся к нему.
Истории, записываемая для понятной всем роли или персоны, состоит из двух частей: ценности и способа её достижения.
Самая важная часть истории — ценностная. «Я как такой-то хочу сделать то-то, чтобы что?». Последняя часть рисует образ полезного действия, достигаемого в истории. Полезное действие помогает увидеть главную цель действующего лица, и направляет проектировщика на способы достижения этой цели.
Примеры:
Самая важная часть истории — ценностная. «Я как такой-то хочу сделать то-то, чтобы что?». Последняя часть рисует образ полезного действия, достигаемого в истории. Полезное действие помогает увидеть главную цель действующего лица, и направляет проектировщика на способы достижения этой цели.
Примеры:
[Бухгалтер] Понимает какую работу важно сделать в первую очередь, чтобы избежать штрафа в результате сдвига срока
⎯
[Маркетолог] Видит воронку продаж на основе демонстрационных данных, чтобы разобраться в том как работает сервис; понимает, что важно подождать пока накопятся данные
⎯
[Маркетолог] Видит воронку продаж на основе демонстрационных данных, чтобы разобраться в том как работает сервис; понимает, что важно подождать пока накопятся данные
Без ценности в историю можно записать любую ерунду, и это не будет заметно. Ценность — как лакмусовая бумажка для истории. Пока записываешь ценность, несколько раз переформулируешь и всю историю.
Например, кто-то формулирует историю как-то так.
Например, кто-то формулирует историю как-то так.
[Продавец] Получает мгновенное уведомление о поступившем заказе
Образа решения не возникает, видение ситуации не передано. Почему здесь важна мгновенность? На этот вопрос нужно получить ответ в процессе сбора требований и записать его в виде ценности в историю. Например, выяснится, что заказ могут передать другому продавцу, если вовремя не отреагировать. Тогда впору записать историю так:
[Продавец] Узнаёт о новом заказе и оставшемся на его обработку времени, чтобы отреагировать вовремя и не упустить заказ
Если вопрос «зачем мгновенность» оставить без ответа, история будет содержать скрытый риск, который весьма вероятно увеличит количество итераций переделки. Лучше выяснить это до начала проектирования и разработки, иначе у вас история с миной замедленного действия:
[Продавец] Получает мгновенное уведомление о поступившем заказе, чтобы <неизвестный риск>
Пример USM без записи ценностей. Каждая карточка содержит слишком много предположений о действии, потому что не проведено согласование с ценностью
Избегание излишних ограничивающих подробностей
Часть с описанием способа достижения полезного действия наиболее вариативна. Здесь в запись историй прокрадывается дизайн. Фиксируя определенный образ достижения полезного действия, мы постулируем один из вариантов работы системы. Важно это понимать и не привносить в историю излишне жестких ограничений. Ограничения важны для проектирования, однако лишние ограничения, возникшие из фантазий, отсекут хорошие решения. Излишняя детализация здесь возникает из-за того, что людям проще мыслить готовыми решениями. Пользователи будущей системы и стейкхолдеры выдают на-гора конкретные варианты того как именно должно быть исполнена история. Важно уйти от излишней конкретики и записать историю без подробностей реализации.
Чтобы избежать лишних подробностей и ограничений на уровне языка интерфейса, рекомендуется избегать названий интерфейсных элементов и паттернов в тексте историй.
Ниже плохой вариант истории:
Чтобы избежать лишних подробностей и ограничений на уровне языка интерфейса, рекомендуется избегать названий интерфейсных элементов и паттернов в тексте историй.
Ниже плохой вариант истории:
Получает пуш-уведомление :-( с информацией о входящем заказе, чтобы вовремя подготовить его к отправке
Плохой, потому что содержит излишнее ограничение на уровне подходов в реализации: пуш-уведомление — это конкретный приём подачи сообщения на мобильных устройствах.
Выбор конкретных способов реализации зависит от имеющихся технологических и временных ресурсов. Лучше записать ту же историю более обще:
Выбор конкретных способов реализации зависит от имеющихся технологических и временных ресурсов. Лучше записать ту же историю более обще:
Вовремя узнаёт о входящем заказе, чтобы успеть подготовиться к его отправке
И при планировании на слое задач — мы обсудим его позже — повесить карточку с описанием того как именно в ближайшем релизе будет реализовываться история. Делая так, мы оставляем историю на один уровень абстракции выше.
Предъявление и изменение данных — вот и весь ваш хвалённый IT
С точки зрения технических систем, любой интерфейс — это трансмиссия — то, что передаёт информацию от передатчика к получателю и обратно.
Я заметил, что все истории в разработке программного обеспечения распадаются на два класса. Все они про предъявление данных и манипуляцию ими. Мы либо что-то показываем, либо влияем каким-то образом на систему, либо делаем и то, и другое.
Исходя их вышесказанного, чаще всего одни и те же слова попадают в запись историй. Вот примеры глаголов, которые мы чаще всего используем в записи историй:
Я заметил, что все истории в разработке программного обеспечения распадаются на два класса. Все они про предъявление данных и манипуляцию ими. Мы либо что-то показываем, либо влияем каким-то образом на систему, либо делаем и то, и другое.
Исходя их вышесказанного, чаще всего одни и те же слова попадают в запись историй. Вот примеры глаголов, которые мы чаще всего используем в записи историй:
У каждого проектировщика или команды может сложиться свой ограниченный набор функциональных глаголов.
Полезные форматы историй
При записи историй удобно придерживаться шаблонов. Это помогает не упустить важного и окупается когда вы, зная форматы, расходуете меньше внимания на поиск того как записать только что озвученное. Особенно это важно, если вы только начинаете использовать картирование историй для сбора требований. Вот несколько форматов, которые показали себя хорошо на практике.
Классический укороченный
В этом шаблоне как и во всех остальных далее действующее лицо вынесено за пределы карточки. В формате также опущен глагол «хочу», записывается сразу действие и ценность.
Действие в форме глагола в третьем лице, чтобы ценность
Пример:
Видит разницу между плановыми и фактическими расходами на бензин во времени и по территории, чтобы выяснить причины расхождений
Вопросы и утверждения
Большинство историй на демонстрацию и изменение данных будет казаться неуклюжими для записи в классической форме из-за того, что записываемая ценность кажется самоочевидной. Если записывать по классике, получается масло-масленное:
Видит баланс счёта, чтобы понять сколько денежных средств осталось.
⎯
Модифицирует карточку товара, чтобы внести изменения
⎯
Модифицирует карточку товара, чтобы внести изменения
В этих случаях хорошо себя показали истории-вопросы и истории утверждения. Пару примеров историй-вопросов:
Сколько денежных средств на счёте?
⎯
Какой следующий пункт назначения в текущем рейсе?
⎯
Какой следующий пункт назначения в текущем рейсе?
Здесь ценность очевидна, а суть истории в том, что человек получает ответ на волновавший его вопрос.
Для сравнения ниже одна и та же история в классическом формате и формате истории-вопроса:
Для сравнения ниже одна и та же история в классическом формате и формате истории-вопроса:
Классический формат
Логист видит какие строки файла не обработались по неизвестной нештатной причине, чтобы найти их и понять что с ними не так
Формат вопросов
Файл принят к парcингу?
Какие строки в файле содержат ошибки и что с этим делать?
Логист видит какие строки файла не обработались по неизвестной нештатной причине, чтобы найти их и понять что с ними не так
Формат вопросов
Файл принят к парcингу?
Какие строки в файле содержат ошибки и что с этим делать?
То же самое относится и к историям про модификацию данных. Для простоты записи мы иногда используем такую форму утверждения:
Варианты историй-утверждений
— Вот мой номер телефона.
— Эти возвращенные товары получил!
— Вот мой номер телефона.
— Эти возвращенные товары получил!
Истории про изменение
Зачастую ценность описать проще, если показать два состояния системы: текущее с проблемой и новое — лишенное проблемы. В этом случае пригождается формат историй на изменение:
Вместо того, чтобы <старое действие>, <новое действие>
Историю про рекламодателя можно переписать в формате изменения:
Классический укороченный
Привлекает только трафик определённой тематики, чтобы эффективно использовать рекламный бюджет
История-изменение
Вместо бесконтрольных трат бюджета, выбирает на какие тематики его потратить
Привлекает только трафик определённой тематики, чтобы эффективно использовать рекламный бюджет
История-изменение
Вместо бесконтрольных трат бюджета, выбирает на какие тематики его потратить
Этот формат истории легко запомнить, представляя схему перехода от вреда к пользе: Бесконтрольные траты (вред) → расходы только на выбранные тематики (польза).
Критерии готовности истории
Как понять, что история закончена? Я смотрю на следующие индикаторы.
⎯
Соблюдён формат или история содержит все важные части: ценность, способ достижения, действующее лицо.
⎯
Формулировка несёт образ решения — при прочтении истории в воображении рождается одно или несколько вариантов решения, желание и готовность приступить к проектированию или разработке. Если остаются вопросы, следует переписать историю.
Как понять, что история спланирована или реализована полностью в определенной версии программного продукта? Здесь есть два способа. По одному из них на обороте стикера с историей записывают перечень критериев её готовности (Definition of Done). Другой — фиксировать все подробности отдельными карточки с детальными задачами под историей. Достижение полноты проверяется по этому перечню или набору карточек.
❏
❏
Продолжение