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

Что такое пользовательские истории, как составить карту пользовательских историй, как работать в модуле User Stories в Kaiten

User story, user story map, пользовательские истории, карта пользовательских историй, Кайтен, Kaiten, scrum

Один из важнейших принципов 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 дизайну.

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

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

User story, user story map, пользовательские истории, карта пользовательских историй, Кайтен, Kaiten, scrum, пользовательский опыт

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

User story, user story map, пользовательские истории, карта пользовательских историй, Кайтен, Kaiten, scrum, пользовательский опыт

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

User story, user story map, пользовательские истории, карта пользовательских историй, Кайтен, Kaiten, scrum, пользовательский опыт

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

User story, user story map, пользовательские истории, карта пользовательских историй, Кайтен, Kaiten, scrum, пользовательский опыт

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

User story, user story map, пользовательские истории, карта пользовательских историй, Кайтен, Kaiten, scrum, пользовательский опыт

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

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

User story, user story map, пользовательские истории, карта пользовательских историй, Кайтен, Kaiten, scrum, пользовательский опыт
Инструмент для составления карты пользовательских историй в Кайтен

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

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

User story, user story map, пользовательские истории, карта пользовательских историй, Кайтен, Kaiten, scrum, пользовательский опыт
Сверху — направления работы, ниже — перечень релизов. Пользовательские истории распределены по релизам, а на шкале с названием релиза показан прогресс выполненных историй.

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

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

User story, user story map, пользовательские истории, карта пользовательских историй, Кайтен, Kaiten, scrum, пользовательский опыт
Можно создать карточки на досках для всех историй релиза или точечно привязать отдельные истории к отдельным карточкам на досках. На картинке показана связь истории с задачей.

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

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

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

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

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

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

Зарегистрируйтесь в Kaiten и попробуйте модуль User Story Mapping бесплатно

Попробовать