Top.Mail.Ru
Колонки

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

Колонки
Ярослав Муромцев
Ярослав Муромцев

Продакт-менеджер «Альфа-Банка»

Ахмед Садулаев

Что такое User Story Map и для чего он нужен? Продакт-менеджер «Альфа-Банка» Ярослав Муромцев рассказывает об особенностях, преимуществах и недостатках фреймворка. Кроме того, эксперт на практическом примере объясняет, как применять этот инструмент.

Как составить требования к функционалу продукта с помощью инструмента 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 не поддерживают автоматическое масштабирование. Это важная функция, которая позволяет менеджеру продукта сконцентрироваться на основной задаче — подготовке качественных требований к продукту.

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

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

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

Скелет продукта в USM

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

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

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

Пользовательские истории в USM

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

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

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

Пример задач в USM

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

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

MVP:

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

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

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

Бэклог:

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

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

Пример USM 1

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

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

Пример USM 2

 

Применение 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

Подписывайтесь на наш Telegram-канал, чтобы быть в курсе последних новостей и событий!

Нашли опечатку? Выделите текст и нажмите Ctrl + Enter

Материалы по теме

  1. 1 7 советов, которые помогут вендору грамотно организовать поддержку партнеров
  2. 2 Как развивать бизнес через партнерскую сеть
  3. 3 5 этапов успешного A/B-тестирования
  4. 4 Проверка для вендоров: семь условий, чтобы ваш продукт захотели продавать партнеры
  5. 5 Личный опыт: что нужно учитывать, создавая международный сервис?
Relocation Map
Интерактивный гид по сервисам и компаниям, связанным с релокацией
Перейти