Руководство по сбору требований в формате User Story Mapping: Дисциплина метода, 2/3
Инструменты проектирования
Apr 25, 2019 · 11 min read
Во второй статье серии мы сосредоточимся на порядке создания карты. В предыдущей подробно рассмотрен центральный элемент карты User Story Mapping — пользовательская история.
Понадобится пример. Давайте представим, что собираемся улучшить работу аэропорта, а именно, повысить качество такого сервиса как туалет. Я намеренно опущу вводные по целям. Выбранный пример хорош тем, что прост, вне области информационных технологий и будет понятен большинству.
Пространственная структура карты
Карта User Story Map состоит из четырёх слоёв: действующих лиц, активностей, историй и детализированных задач.
Этап 1. Запись историй
Порядок действий
Принципы и рекомендации
Типичные ошибки
Этап 2. Планирование релизов
Порядок действий
Принципы и рекомендации
Этап 3. Ведение проекта по карте
Несомненно трекинг проект а по карте — занятие для дисциплинированных команд. На моей практике редкие проекты доживали до второго-третьего релиза с первозданной картой. Обычно поддерживать карту ленятся. Истории на грядущий релиз либо собирают в кучку из бэклога, либо строят новую мини карту. Если вы решились вести проект как положено, вот некоторые руководства.
Порядок действий
Принципы и рекомендации
Рекомендации для ведущего
Как вы могли заметить, метод требует дисциплины и умственного напряжения. Без хорошего ведущего сессия сбора требований рискует затянуться, либо выжать из участников все соки. Ниже несколько рекомендаций для ведущих сессий в формате ответов на вопросы моих коллеги.
С чего начинать
У нас карта историй, и любая большая история с чего-то да начинается. Вопрос «С чего всё начинается?» — отличная отправная точка.
Какие вопросы задавать
Теоретически вы можете обойтись формальным набором вопросов, типа «А что происходит дальше?», который рекурсивно будет вести вас вдоль хребта карты. Однако вряд ли вы так достигнете глубины, и уж точно поверхностными вопросами не добиться расположения и должного участия других участников сессии.
Работа над картой USM — это продолжение беседы, начавшейся в момент выяснения целей проекта и знакомства с процессами как они есть, если уже существует некоторая система. В ходе этих первых встреч вы формируете базис для понимания, откуда сможете черпать вопросы. Если таких встреч не было, придётся сымпровизировать и провести их подобие в начале сессии USM. Задача-минимум здесь — понять очертания бизнес-ландшафта: цели бизнеса, гипотезы их достижения.
Когда вам будут рассказывать истории, ваша основная работа разложить задачи и мотивацию действующих лиц. Для этого важно вытащить и записать истинную ценность рассказываемых историй. Участники, не со зла, будут изображать не проблему, а варианты решения — так уж мы, люди, устроены. Чтобы разобраться в том, что под всем этим лежит, придётся заглубляться. Скорее всего, вашими рабочими лошадками будут «Пять почему», «Зачем?», «Чтобы что?». Ну и конечно, терпение и юмор.
Что делать если «идёт с трудом»
Начинающих ведущих беспокоят паузы с неловким молчанием, либо наоборот чересчур активные стейкхолдеры, за которыми трудно поспеть. К тому же в области ближайшего развития люди всегда испытывают синдром самозванца, и неоправданно много волнуются.
Я рекомендую ведущему снять с себя ложное убеждение о важность «держать лицо», и делать видимой каждую проблему, которую вы встречаете. Задумались — скажите над чем вы задумались или, лучше, пригласите к этому всю команду. Так не возникнет ожидающей паузы, и вы не потеряете динамику. Не знаете куда двигаться дальше — так и скажите: «Коллеги, похоже мы в тупике и вот почему…».
Как понять успешно ли я веду?
Если вы всё верно организовали, то дело обстоит так. Льётся интересная беседа, на доске появляется карточки историй, вокруг них возникает дискуссия, карточки переписываются, все участники вовлечены. К концу сессии пройден некоторый участок карты в требуемом вам формате. К концу нескольких сессий получена карта, обладающая известной на текущий момент полнотой.
Как определить готова ли карта
Как понять, что полнота достигнута и можно остановиться? Это трудный вопрос. Пуленепробиваемых рекомендации здесь нет, есть несколько уловок.
Полноты трудно достичь, наблюдая за тем, что уже найдено. Когда вы спросите участников, «всё ли здесь учтено» и получите ответ «да», важно понимать, что это значит «мы посмотрели на эти истории и не вспомнили ничего нового». Ключами для поиска отсутствующих историй могут быть память участников и системная логика, проверяющая целостность и работоспособность описываемой системы. Некоторые истории удаётся обнаружить только когда кто-то начал работать над реализацией и посмотрел на историю с другого угла, либо когда недостающие истории были встречены позже в жизни. От этого никак не уберечься. Важно быть готовыми принимать изменения и новые требования в любой момент работы над продуктом.
И всё же, как понять, что сейчас можно остановиться. Как ведущий, я обращаюсь к участникам и спрашиваю «что мы ещё не учли»? В поиске пропущенных историй помогает общий пересмотр карты, когда громко озвучиваются активности и истории из хребта USM. В это время и по ходу записи я сам слежу за системной сборкой — чтобы всё было непротиворечиво, а записанные ценности обеспечивали работоспособность историй. Когда все участники выражают ощущение достижения полноты, сессия завершается.
Гайд по 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) Создается таблица с примерами.
В данном примере мы должны показать связь между количеством постов в блоге и тем, какое сообщение увидит пользователь.Например:
Карта пользовательских историй (User Story Mapping, USM)
Техника визуального представления последовательности действий клиента в проектируемом решении. При этом используется двухмерная сетка: по горизонтали отражаем последовательность действий, по вертикали — вариации действий на конкретном шаге.
Канвас ценностного предложения (Value Proposition Canvas, VPC)
Шаблон, который помогает проектировать ценностное предложение разрабатываемого решения.
Шаблон состоит из двух частей:
Техника визуализации для формирования бэклога продукта, для генерации гипотез по развитию продукта и др. Декомпозирует влияние на достижение цели через призму клиентов, коллег, смежных отделов, конкурентов, инвесторов и других заинтересованных лиц. Состоит из блоков:
«Зачем?» → «Кто?» → «Как?» → «Что нам сделать, чтобы всё что слева случилось?»
Карта потока ценности (Value Stream Mapping, VSM)
Визуализация последовательности шагов, осуществление которых необходимо для того, чтобы предоставить клиенту продукт или услугу. Это практика из бережливого производства (Lean). Используется для оптимизации всего процесса доставки ценности, а не только одного этапа процесса за счет других этапов.
Карта сервиса Service Blueprint
Техника проектирование точек контакта клиента с услугой, продуктом или компанией. Визуализация включает в себя сценарии использования, точки касания, видимые клиенту (интерфейсные решения) и точки касания, не видимые клиенту (внутренние системы). Может использоваться для оцифровки текущих процессов и опыта клиентов.
Минимально жизнеспособный продукт (Minimal Viable Product, MVP)
Решение, достаточное для получение обратной связи по дальнейшему развитию продукта. Обладает минимальными, но достаточными для удовлетворения первых потребителей функциями.
Мы хотим, чтобы компании были крутыми, а люди в них — счастливыми
User Story Mapping и функциональная архитектура
Каждый, кто запускал IT-проекты или участвовал в продуктовых исследованиях, наверняка слышал про метод персон Алана Купера и User Story. И пусть некоторые считают персон нерабочей и устаревшей методологией — я убеждён, что это всего лишь результат многолетней вандализации метода.
В этой статье я хочу рассказать о том, как «продолжение» User Story может не только улучшить UX продуктов, но и решить кое-какие фундаментальные проблемы их разработки.
Цифровые продукты редко запускаются гладко. Правки к сценариям, функциональности и макетам зачастую возникают прямо в процессе реализации. Никто никогда не в курсе, куда несётся поезд продуктовой разработки — а обратное чувство, чаще всего, обманчиво.
Персоны и User Story — это такая прикольная штуковина для того, чтобы погрузить всех участников в проектный процесс, выявить и подсветить истинные задачи пользователей. Однако сами по себе персоны практически не влияют на процесс создания продуктов, лишь на их функциональность. Чего нельзя сказать о следующем этапе развития пользовательских историй — о User Story Mapping.
Об этом подходе написано уже немало, в том числе и на русском языке. Но большинство таких статей (на мой субъективный взгляд) либо весьма поверхностны, либо имеют серьёзный перекос в сторону именно UX, практически игнорируя аспект управления и развития продукта. Однако я искренне благодарен авторам таких статей, ибо понахватал оттуда приличное количество тезисов и умозаключений.
§ Проблемы
Для начала давайте разберём некоторые глобальные трудности и барьеры, возникающие при создании цифровых продуктов.
§ Требования к продукту плохо структурированы по отношению друг к другу
Нет иерархии и последовательности требований. Не всегда понятно, какая задача какую блокирует и от какой зависит. Чаще всего зависимость задачи проставляется исключительно командой разработчиков или тимлидом — но они не владеют общим видением продукта, руководствуясь только своими представлениями о локальном участке архитектуры. То есть они не видят всю связь, весь flow бизнеса и пользователя целиком. Не тот уровень абстракции.
Это, разумеется, влияет на глобальную архитектуру, на качество кода и самого продукта, на динамику разработки. Что, в свою очередь, приводит к многократному увеличению стоимости поддержки и развития.
Каждое требование — это определённая функция или функциональный раздел продукта. Если команда разработки не понимает взаимосвязи между функциями в создаваемой ими системе, то такие проекты гарантированно обречены на «историческое» развитие. Так рождаются огромные «монолиты», которые очень и очень быстро переходят в разряд с трудом поддерживаемых «legacy».
§ Требования к продукту не приоритизированы с точки зрения ценности для пользователей
Порядок реализации задач формируется по наитию, по сложности разработки, по желанию клиента, по чему угодно — но только не по важности для пользователей. В итоге разработка и выпуск новых версий затягиваются.
Ядро функциональности, пресловутый MVP, собирается, исходя из представлений команды о продукте. Даже если команда думает, что полагается на результаты исследований — на сложных проектах эти результаты ещё необходимо как-то структурировать и визуализировать. Иначе высока вероятность «рассинхрона», отсутствия единого информационного поля внутри команды.
Последствия в этом случае весьма печальны, вплоть до полной невостребованности продукта аудиторией.
§ Отсутствует единое понимание стратегии разработки, последовательности и состава релизов
Отсутствие стратегического подхода влечёт за собой не только архитектурные ошибки (опять), но и заставляет нервничать стейкхолдеров и владельцев продукта. Прогнозы в такой ситуации строить крайне сложно.
Как это решается в большинстве случаев? Продуктовая команда либо строит лишь краткосрочные планы, либо составляет план релизов буквально «наугад». Однако инвесторы не любят неопределенности. Если вы не можете предоставить им хотя бы примерный таймлайн или просто последовательность и функциональный состав релизов, то у меня для вас плохие новости. Ваш проект рискует остаться без финансирования.
Кто-то мне скажет, что это не всегда возможно. Часто исследования идут бок о бок с разработкой. Те же гибкие методологии, в конце концов. Однако даже здесь нужно опираться на определённый фундамент, базис. Ну и кроме того, гибкие методологии имеют весьма ограниченный ореол применения.
§ Функциональные границы проекта очерчены слишком высокоуровнево или даже вовсе отсутствуют
Бизнес требует внедрения всё новых фич, разработка затягивается, бэклог растёт, команда выгорает. Продукт получается, мягко говоря, странным.
Случалось ли у вас, что клиент/начальник/инвестор начинал каждую неделю приносить новые функции в проект? И обычный вначале лендинг в итоге превращался в космолёт-монстр, с админкой, функцией телепортации и собственным мобильным приложением?
Фичи должны добавляться последовательно и обоснованно (см. предыдущие проблемы). Функция не может жить «сама по себе», в отрыве от остальных частей продукта. И вот конечный порядок и взаимосвязь функций системы, состав её компонентов — это и есть границы проекта.
§ User Story Mapping
Как я уже сказал, все эти проблемы (и не только) решают карты историй. Вот вам хорошее определение USM:
Карта историй работает сразу в двух измерениях: показывает не только приоритет историй, но и то, как они связаны между собой и с более крупными задачами пользователей. Карта помогает команде понять, как можно скомпоновать истории, чтобы получить продукт, готовый к релизу.
Крис Симс (в переводе Ольги Жолудовой и Рината Шайхутдинова)
По факту, карта историй — это набор упрощённых User Stories: собранные, отсортированные и приоритизированные. Сама методология простая, на высоком уровне с ней справится даже новичок. Но если копнуть глубже, то там окажется целое поле работы для исследователей, продактов и архитекторов.
В этой статье в качестве иллюстрации для составления USM мы будем использовать небольшую браузерную игру с программой лояльности какого-нибудь банка. В ней есть регистрация, игровой персонаж, его убежище, сражения и баллы лояльности.
Следующие ниже изображения-схемы могут быть не очень хорошо читаемы на небольших экранах мобильных устройств. В этом случае рекомендую посмотреть их на десктопе или перевернуть смартфон в «ландшафт».
§ Шаг 1. Выявляем активности
Сначала нужно собрать список основных активностей пользователей. В нашем примере игры их пять:
Это — ключевые, главные «категории» действий пользователя в игре. Они включают в себя всю остальную деятельность. Если использовать терминологию функциональной архитектуры, то здесь мы создаём глобальные функциональные разделы.
§ Шаг 2. Разворачиваем активности в задачи
Разбивка активностей на задачи
Теперь мы раскладываем их (активности) на задачи. Например, активность «Регистрация и логин» превращается в три задачи:
Заметьте, здесь нет отдельно «логина» или «регистрации». Это более глубокий уровень, задачи же — это такие «категории» пользовательских историй. В функциональной архитектуре это тоже функциональные разделы, но уже не глобальные, а обычные.
§ Шаг 3. Задачи детализируем до конкретных историй
Детализация задач историями
И, наконец, истории (жёлтые карточки) — они расположены в порядке приоритета — сверху критичные, внизу наименее важные. Приоритет обычно выстраивается, исходя из нескольких условий:
Именно в таком порядке: сначала пользователи, потом бизнес, потом технологии. Понятно, что зачастую бизнес-задачи оказываются важнее пользовательских, и в этом случае карточки немножко двигаются. Иногда реалии рынка действительно сильнее влияют на продукт, чем желания пользователей. Аккуратнее с этим, руководствуйтесь здравым смыслом.
В случае нашего примера, задача «Регистрация и логин через e-mail» разложилась на 2 истории:
Истории — это функции будущей системы. У них есть взаимосвязи и порядок. Например, мы не можем реализовать функцию «Выбор навыков аватара для улучшения» по результатам сражения до того, как, собственно, реализуем сам «Подбор параметров аватара» в момент создания персонажа.
В результате этапа мы понимаем, какая задача из каких историй состоит и к какой она относится активности. Мы понимаем, какие истории нужно сделать в первую очередь. Мы можем планировать спринты и релизы.
§ Шаг 4. Делаем из приоритетов схему релизов
Разделение задач на релизы
Напомню, что истории — это всего лишь функции будущей системы. Понимая это, мы просто переносим те истории, которые не критичны или требуют на этом этапе слишком много ресурсов, в следующий релиз. Точно так же можно выделить MVP.
Например, нам проще сделать логин и регистрацию через соцсети — и регистрацию через e-mail мы отодвигаем на второй релиз. Пользователям не так важна покупка амуниции — и она тоже вылетает из MVP.
§ Дополнительно: цветовая индикация и структура
Структура User Story Mapping
Принято разделять USM на две структурных части:
И да, цветом стикеров можно помечать отдельные категории событий/действий, дополнительную важность (например, для бизнеса), типы пользователей и так далее. Всё, что посчитаете важным.
С помощью User Story Mapping можно не только планировать новые продукты, но и улучшать уже существующие — например, приоритизировать бэклог.
USM позволяет на очень простом визуальном языке донести до всех участников команды не только функциональный состав продукта, но и порядок проектирования и реализации. Если вы хотите выполнить глубокое функциональное проектирование будущего продукта, то User Story Mapping — отличное начало для этого.
Помните только, что слепое следование методологиями убивает профессионализм. Комбинируйте, не бойтесь отойти от канонов, если уверены в своих действиях.
Описанный подход к проектированию уже несколько лет успешно применяется в стенах нашей Цифровой Артели Eleven, а мой партнёр, Вадим Митякин, даже пишет об этом книгу.
Все свои материалы я аккумулирую в своём tg-канале, подписывайтесь.
