Пользовательские истории: как их использовать, чтобы повысить ценность продукта

Существуют такие программные решения и сервисы, которые прочно удерживают внимание пользователя. И дело здесь не только в удобном интерфейсе, легкой навигации и понятной структуре. Огромную роль играет грамотно проработанная user story, которая помогает понять, что именно пользователь ждет от продукта. Разбираемся, что собой представляет пользовательская история и как ее применять.

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

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

Типичная пользовательская история будет иметь следующий формат: 

«Как [персона] я хочу [цель программного обеспечения], чтобы [результат]». 

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

Например, так может выглядеть пользовательская история для пользователя социальной сети:

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

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

Пользовательские истории – ключевой компонент Agile-подхода. Наиболее эффективно создавать и отслеживать создание user stories помогут специализированные сервисы для управления проектами. Такие решения позволят редактировать и отслеживать пользовательские истории в режиме реального времени, фокусируя внимание на интересах конечного пользователя.

Кто пишет пользовательские истории

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

После того как списки пользовательских историй готовы, команда разработчиков расставляет их в порядке приоритетов. Далее user stories обсуждаются в рамках методик Scrum и Kanban:

• Scrum обычно проводят в виде так называемого спринта – двухнедельной рабочей сессии, по итогам которой необходимо достигнуть заданных результатов. Первая часть – ежедневные совещания по 15–20 минут. Вторая часть – ретроспектива спринта по его окончании и подведение итогов. 
• В Kanban команда реализует визуальное управление проектов через специальную доску со столбцами. Каждый столбец представляет собой некий этап работы: например, «Предстоит», «Выполняется» и «Выполнено». Отдельные задачи перемещаются из одного столбца в другой по мере их выполнения. 

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

Пользовательская история пишется в три этапа и представляет точку зрения конечного пользователя: 

1. Роль – персона конечного пользователя.
2. Потребность – назначение функции для конечного пользователя.
3. Цель – результат взаимодействия конечного пользователя с функцией продукта.

Разберем конкретно каждый этап составления пользовательской истории.

Шаг 1. Определить роль

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

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

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

Шаг 2. Описать потребность

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

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

Шаг 3. Определить цель

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

• В чем преимущество функции программного обеспечения?
• Какая проблема решается?
• Как это вписывается в более масштабные цели?

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

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

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

Как повысить эффективность пользовательской истории

В дополнение к трем шагам, описанным выше, эффективная история пользователя должна следовать правилам 3C и INVEST. 

3C – это:

• Карточка (Card) – письменное описание пользовательской истории, используемой для планирования спринта. 
• Обсуждение (Conversation) – дискуссия между клиентами, пользователями и разработчиками приоритетных и потенциальных решений пользовательской истории.
• Подтверждение (Confirmation) – соглашение между заинтересованными сторонами о том, что цели и решения пользовательской истории достигнуты. 

Система 3C помогает разбить пользовательскую историю на простые задачи. Это дает четкое направление для всех вовлеченных в разработку продукта сторон.

Правило INVEST включает в себя следующие аспекты:

• Независимость (Independent) – пользовательская история должна быть автономной по отношению к другим задачам.
• Договоренность (Negotiable) – при создании пользовательской истории всегда должно оставаться место для обсуждения. 
• Ценность (Valuable) – пользовательская история должна представлять ценность для конечного пользователя, приближая разработчика к более крупным долгосрочным целям.
• Оценка (Estimable) – пользовательская история должна быть оценена и правильно расставлена ​​по приоритетам.
• Краткость (Small) – пользовательская история должна быть небольшой частью работы, которую можно выполнить за короткий промежуток времени.
• Тестируемость (Testable) – история должна пройти тестирование, чтобы соответствовать заранее определенным критериям качества. 

Заключение: 3 совета по созданию пользовательской истории

1. Ставьте интересы и потребности клиентов на первое место. Затем ваша команда может расставить приоритеты и сосредоточиться на том, как внести свой вклад в положительный пользовательский опыт. 
2. Внедряйте инновационные решения. Чем глубже вы погружаетесь в образ конечного пользователя, тем более инновационными будут ваши программные решения. 
3. Поощряйте совместную работу команды. Когда несколько членов команды обсуждают пользовательские истории и расставляют приоритеты, совместная работа дает ощутимые плоды. Так появляется несколько точек зрения, из которых можно выбрать наиболее эффективное решение для достижения результатов.