Приложение разрабатывают для того, чтобы его использовали. Очевидно? Да, но только до тех пор, пока не коснулись практики.

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

На рабочем поле по горизонтальной оси в хронологическом порядке располагаются события, которые пользователь проходит для достижения цели. А под каждым событием — шаги, которые выполняет на этом этапе. Эти шаги называются User Story.

Например, есть событие «Поиск товара». Для него нужно описать User Stories для поиска товаров, фильтров по цене и по рейтингу. Такую карту обычно делают либо на доске, а User Stories пишут на стикерах, либо в онлайн-сервисах таких как Miro. Когда карта будет готова, все члены команды будут видеть, как фича, над которой они работают, соотносится с продуктом.

Фреймворк Story Mapping придумал основатель компании Jeff Patton & Associates, Джеф Паттон. В прошлом Джеф был product-менеджером. В своей работе он понял, что техническая документация не помогает в разработке продукта, а скорее создает трудности. Её можно по-разному интерпретировать, она быстро устаревает. Из-за этого возникает множество недопониманий.

Если при чтении документации члены команды пассивно воспринимают информацию, то Story Mapping — это процесс, в котором все принимают активное участие. Пока составляется карта, проясняется множество вопросов. По окончании процесса все уходят с пониманием того, как должен работать продукт.

Кроме того, так как в составлении карты принимает участие вся команда, это позволяет избавиться от иерархии в управлении. Но самое главное, Story Map — это «живой» документ. Карта будет меняться, её будут пересматривать с целью, как еще улучшить продукт.

Story Mapping служит ключевым целям:

1. Помогает видеть картину целиком. И, как следствие, понимать, зачем делаем те или иные задачи.

2. Позволяет увидеть пробелы. Например, в карте есть User Srories поиска товаров и оплаты заказа. Смотря на карту, становится понятно, что один шаг пропущен: не хватает добавления в корзину.

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

Самое замечательное в Story Mapping, что её можно использовать на любом этапе жизненного цикла продукта.

• Работаете над MVP? Карта пользовательских историй — отличный способ определить минимальную функциональность, необходимую для проверки концепции. Она не позволит «забыть» о важных частях пользовательского опыта.

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

• Ищите способ сократить время работы? Story Map поможет понять, какую работу делать не нужно и расставить приоритеты, так как все задачи рассматриваются вместе с контекстом.

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

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

Чтобы использовать Story Mapping в карте, нужно сделать следующее.

1. Оценку функционала
Карту можно дополнить оценкой затрат ресурсов. Это могут быть человеко-часы, дни, недели или какая-либо другая оценка, которая даст представление о том, сколько времени займет каждая задача. Также можно сгруппировать функционал с точки зрения связанности в реализации. Часто корректная работа одного функционала возможна, только если сделаны другие задачи.

2. Распределить задачи по релизам
Если проект на стадии MVP, то нужно сосредоточится на том, чтобы на каждом этапе в приложении добавлялись полностью реализованные пользовательские истории. Да, функционал может не иметь всего задуманного, но должен позволять достигать нужные для пользователя цели.
Если проект в стадии планомерного развития, то ориентируйтесь на оценку затрат ресурсов. Но учитывайте, что в процессе реализации могут возникать дополнительные задачи.

3. Определение результатов
Что будет сделано в продукте к каждому релизу с точки зрения пользовательского опыта?
Например, если вы делаете маркетплейс, это может быть функция получения персонализированных рекомендаций. Соответственно, этап работы можно считать успешным, если удалось выкатить эту фичу.

Story Mapping — это возможность решить проблемы, с которыми часто сталкиваются менеджеры IT-продукта. С помощью неё можно доносить общие цели и задачи, не «читая лекции» своим коллегам. Можно создать среду для совместной работы, в которой каждый будет участвовать в разработке стратегии продукта. И можно достичь консенсуса и понимания целей еще до того, как команда напишет хоть одну строчку кода.

Однако Story Mapping небыстрый процесс. Возможно, придется убеждать руководство в том, что это полезное использование времени команды. Но, в конце концов, если продукт не помогает клиентам, они откажутся от него. Поэтому главное о чем нужно думать при разработке — это о том, как именно будут пользоваться сервисом. А в этом Story Mapping отлично поможет в этом.

Мы вдохновлялись

1. Story Mapping
2. Синди Альвес, «Как создать продукт, который купят»