Как составить требования к функционалу продукта с помощью инструмента User Story Map

Что такое User Story Map

User Story Map (карта пользовательских историй или USM) — это визуальное представление последовательности пользовательских действий относительно продукта. Он помогает команде визуализировать общую картину, понять и организовать требования к продукту на основе User Flow (пути пользователя) и приоритетов бизнеса.

Методика User Story Mapping была разработана Джеффом Паттоном и впервые представлена широкой публике в 2005 году в статье в журнале Better Software. Он описал подход к планированию историй, который стал основой для методики User Story Mapping.

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

USM состоит из нескольких уровней, которые включают Epics (эпики — широкие категории функциональности), User Stories (пользовательские истории — конкретные функциональные требования) и User Tasks (пользовательские задачи — шаги для выполнения пользовательских историй).

Читайте по теме: Что такое себестоимость продукции и как ее рассчитать

Почему User Story Mapping эффективен?

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

• Понимание продукта. USM обеспечивает комплексное видение всего продукта, позволяя команде видеть, как отдельные функции сочетаются для создания цельного пользовательского опыта.
• Ориентация на пользователя. Акцент на пользовательских историях помогает команде сосредоточиться на задачах конечных пользователей, обеспечивая разработку продукта, который достигнет product market fit (соответствие продукта ожиданиям аудитории и рынка).
• Коммуникация в команде. USM служит общим языком для всех участников продукта, от разработчиков до стейкхолдеров.
• Приоритизация разработки и гибкость в планировании. Благодаря визуализации пользовательских историй и их приоритетности, команда может сосредоточить внимание на создании наибольшей ценности для пользователя. А также гибко подходить к планированию релизов и адаптироваться к изменяющимся условиям без потери общей картины продукта.
• Эффективное масштабирование. USM облегчает масштабирование продукта, предоставляя четкое видение того, как новые функции вписываются в общую структуру и влияют на пользовательский опыт.

Несмотря на плюсы методологии User Story Mapping, существует также и ряд недостатков, которые нужно понимать прежде, чем внедрять этот инструмент в свои производственные процессы. Ключевые недостатки следующие:

• USM подходит не для всех типов проектов. Некоторые проекты могут быть сложными декомпозиции на пользовательские истории и состоять в основном из технических задач, не имеющих прямого влияния на пользовательский опыт.
• Поддержка актуальности USM может потребовать значительного времени и усилий, особенно в больших активно развивающихся продуктах.
• USM может оказаться сложным для внедрения в команды, незнакомые с Agile-принципами и методикой User Story Mapping.

Ключевое отличие USM от традиционной документации заключается в гибкости подхода. Поэтому USM — это артефакт документации в рамках Agile-методологий разработки. Традиционные методы управления требованиями обычно описывают проект целиком и больше подходят для Waterfall подхода.

При этом User Story Map все еще остается эффективным инструментом для подготовки качественных требований к продукту. Даже при реализации крупных проектов, USM можно использовать как часть PRD, описывающую пользовательский опыт (Product Requirements Document или документ, описывающий требования к продукту).

Как создать User Story Map: пошаговое руководство

Рассмотрим процесс создания USM на примере интернет-магазина. Сначала для обеспечения эффективности процесса нужно подобрать хороший инструмент для работы с USM. Я предпочитаю использовать Miro со стандартным шаблоном User Story Map.

Также есть альтернативы, такие как Mural и другие, но они выглядят менее эффективными, так как их шаблоны USM не поддерживают автоматическое масштабирование. Это важная функция, которая позволяет менеджеру продукта сконцентрироваться на основной задаче — подготовке качественных требований к продукту.

Далее необходимо приступить к самой разработке карты пользовательских историй.

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

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

Следующим этапом формируются пользовательские истории. Общепринятая формулировка User Stories выглядит следующим образом: «Как <роль>, я хочу иметь возможность <сделать что-то>, чтобы <получить определенный результат>».

Вот несколько примеров:

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

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

• Показывать список категорий товаров;
• Показывать товары в выбранной категории;
• Реализовать функцию поиска товаров по названию;
• Реализовать фильтры по цене и популярности;
• Ввести виртуального помощника для подбора товаров;
• Добавить видео обзоры на страницу товара;
• Внедрить AR-примерку товаров.

Декомпозируем все наши пользовательские истории на задачи и заполним User Story Map.

Получился достаточно крупный USM. Такой большой объем работы нельзя выполнить сразу. К тому же, продакт-менеджер стремится к минимальному time to market. Поэтому необходимо приоритизировать задачи для команды, выделить MVP, следующий релиз, а остальное положить в бэклог.

На примере той же user story разобьем задачи по релизам:

MVP:

• Показывать список категорий товаров;
• Показывать товары в выбранной категории.

Следующий релиз:

• Реализовать функцию поиска товаров по названию;
• Реализовать фильтры по цене и популярности.

Бэклог:

• Ввести виртуального помощника для подбора товаров;
• Добавить видео обзоры на страницу товара;
• Внедрить AR-примерку товаров.

Приоритизируем таким же образом все остальные пользовательские истории.

Наш USM готов к тому, чтобы брать его в оценку и далее в работу. Оценку можно произвести там же в Miro с помощью встроенного инструмента Poker Planning.

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

Применение User Story Map на практике: кейс из опыта

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

Чтобы USM стал частью производственного процесса, пришлось пройти несколько этапов:

1. Понять, как «приземлить» фреймворк на существующие производственные процессы компании. Так как я работал в корпорации, использовать Agile-методологии зачастую оказывалось достаточно непросто, потому что существует огромное количество других команд, которые придерживаются de-facto waterfall подхода.
2. Вторым шагом нужно было познакомить команды с концепцией User Story Mapping и подчеркнуть ее ценность для улучшения процессов разработки. Я организовал серию мастер-классов и рабочих сессий, чтобы демонстрировать принципы работы с USM, обучая команды тому, как создавать и использовать карты пользовательских историй.
3. После введения команд в курс дела, я сконцентрировался на перестройке внутренних процессов. Это требовало от команд отхода от привычного ожидания полностью сформированных требований и перехода к активному участию в разработке карт пользовательских историй. Мы начали регулярно собираться для обсуждения и обновления USM, вовлекая в процесс всех участников команд разработки.

Внедрение User Story Mapping оказалось непростой задачей. Тем не менее, преодолев начальные трудности и сопротивление изменениям, мы смогли значительно улучшить наши процессы. Команды стали лучше понимать цели и задачи продукта, а также более эффективно декомпозировать, оценивать и приоритизировать задачи.

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

Читайте также:

Какому бизнесу никогда не дадут в долг: чек-лист для самопроверки

Что такое диаграмма Ганта и как ее построить

Как получить максимум

• Начните с целей. Определите ключевые бизнес-цели и задачи пользователя, которые должен решить ваш продукт. Это поможет сосредоточиться на создании ценности для пользователя.
• Вовлекайте команду. User Story Mapping должен быть коллаборативным процессом. Привлеките в процесс разработки всех участников команды, включая разработчиков, дизайнеров, аналитиков.
• Используйте визуализацию. Визуальное представление помогает команде и вам лучше понять структуру продукта, его функциональные возможности и приоритеты разработки.
• Определяйте приоритеты. Используйте карту для определения приоритетов разработки. Сосредоточьтесь на функциях, которые принесут максимальную ценность пользователям на ранних этапах.
• Оставляйте акцент на важном. Избегайте создания слишком детализированных карт, которые могут сбивать с толку и затруднять понимание общей картины.
• Динамично обновляйте карту. User Story Map должен быть живым документом, который регулярно обновляется в соответствии с полученной обратной связью от пользователей и изменениями в продукте.

Фото на обложке: Unsplash