User story mapping: как посмотреть на проект глазами пользователя

Один из важнейших принципов Agile звучит так: «Люди и их взаимодействие важнее процессов и инструментов». Это не означает, что последние не важны, суть этого высказывания следующая — их легко можно изменить и подстроить под свои нужды.

Люди в этом принципе — не только  участники команды и заинтересованные стороны. Это еще и пользователи продукта, над которым работает команда. Чтобы сделать продукт полезным и удобным для пользователя, команде стоит сменить угол зрения. С этим вам помогут Пользовательские истории.

Что такое пользовательские истории?

Пользовательские истории (User stories) — это описание работы элемента или функции, составленное с точки зрения пользователя и написанные простым неформальным языком. Этот инструмент помогает команде делать продукт более ориентированным на пользователей.

Главная ценность user stories — в емком и понятном описании цели желаемой функции. После прочтения текста истории у всех участников команды должно быть понимание, зачем функция нужна пользователю и как приблизительно должна работать.

Зачем вводить пользовательские истории?

У пользовательских историй есть ряд преимуществ для Agile-проектов:

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

В своих формулировках пользовательские истории в общих чертах объясняют, что необходимо сделать команде для их воплощения.  

Пользовательские истории — не задачи. У них есть три ключевых отличия:

*Пользовательский опыт (User experience) — это сочетание всех полученных пользователем умений, знаний и впечатлений после взаимодействия с продуктом или услугой.

Примеры пользовательских историй:

Пример 1. Главный редактор: «Как главный редактор я хочу видеть все взятые в работу статьи, чтобы следить за сроками их выполнения».

Пример 2. Фронт-энд разработчик «Как фронт-энд разработчик я хочу видеть динамическое изменение проекта, чтобы вовремя обновлять его».

Пример 3. Менеджер по работе с клиентами «Как менеджер по работе с клиентами, я хочу фильтровать клиентов по категориям, чтобы быстро находить необходимого клиента».

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

Историю можно преобразовать в задачу. А вот наоборот уже не получится.

Как написать пользовательскую историю

1. Точно определите, как будет выглядеть выполненная история. Обычно пользовательские истории считаются готовыми в тот момент, когда пользователь получит необходимый результат — выполнит задачу или достигнет цели.
2. Отметьте этапы, необходимые для работы над историей, задокументируйте все необходимые детали и назначьте ответственного за каждый этап.
3. Определите, кем будет конечный пользователем в этой истории. Если пользователей несколько, стоит создать несколько пользовательских историй.
4. Создайте историю для каждого шага в проекте — Карту пользовательских историй. Это упростит саму работу, обеспечит наглядность всем этапам и сформулирует полноценный пользовательский опыт. О том, как составить карту, мы расскажем ниже.
5. Соберите обратную информацию от пользователей и клиентов. Зная, чего именно они хотят от вашего проекта, команде будет значительно проще создать действительно актуальный продукт. Также это поможет вовремя избежать проблем в пользовательском поведении.
6. Создайте истории, которые можно закончить за один спринт. Если пользовательская история слишком объемная, есть смысл разбить ее на более мелкие.

Как только пользовательская история будет определена, убедитесь, что она доступна всей команде.

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

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

Карта пользовательских историй — что это такое и как ее составить

Карта пользовательских историй (User story map, USM) — это видение всего проекта с точки зрения пользователей и его опыта. Карта поможет увидеть взаимосвязи внутри проекта, которые ориентированы непосредственно на пользователя. Она визуализирует весь цикл взаимодействия пользователя с продуктом от начала и до конца.

Помимо пользовательских историй, в создании USM применяются два важных инструмента: портрет пользователя (User persona) и путешествие пользователя (User journey).

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

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

Рассмотрим на примере.

Вот как выглядят шаги пользователя в истории, которая звучит так: «Как мама в декрете, я хочу подобрать хороший курс, чтобы получить возможность работать из дома»:

Все шаги необходимо сгруппировать по этапам, каждый из которых отображает действие пользователя, в этом примере на сайте (может быть также в приложении, программе etc.):

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

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

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

Как работать с пользовательскими историями в Kaiten

В Kaiten есть специальный модуль для составления Карты пользовательских историй — Story Maps. Модуль позволяет не только создавать карты историй, но и привязывать их к карточкам на досках. Использовать USM удобно для указания основных этапов работы над проектом. Также задачи с USM можно отправлять непосредственно на канбан-доску.

Шаблоны для карт пользовательских историй находятся в боковом меню слева в пункте Story Maps.

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

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

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

Подробнее о работе с инструментом для построения карты пользовательских историй читайте в инструкции Модуль User Story Mapping

Подытожим вышесказанное

Есть такой термин — «профессиональная деформация». Из-за долгой работы у человека может искажаться восприятие продукта своей деятельности. Также и в работе над проектом.

В какой-то момент участники команды могут начать воспринимать его только с технической стороны, игнорируя пользователей. В итоге выпущенный продукт не будет отвечать запросу пользователей. Из-за чего продукт будут игнорировать.

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

Модуль USM в Kaiten поможет вам и вашей команде составить подробную карту пользовательских историй. Задачи оттуда можно отправлять на канбан-доску и связывать с другими карточками. Работая с Kaiten, вы будете видеть динамичный и детальный прогресс по всем своим задачам.