Как применять user story в проектах

Даже при хорошем ТЗ проекту часто не хватает контекста — одной четкой фразы, которая направляет к нужному результату. Пользовательская история (user story) помогает сформулировать, кто наш пользователь, что он хочет сделать прямо сейчас и зачем ему это. С ней проще утвердить план действий и не утонуть в бесконечных правках. Такой подход одинаково хорошо работает в сервисах, сайтах и приложениях, в обучающих платформах и корпоративных системах — везде, где важен понятный путь пользователя. В статье разберем, как писать user story, задавать понятные условия результата и проверять, дала ли история нужный результат.

Что такое user story и когда она действительно нужна

User story (пользовательская история) — короткая фраза, которая описывает цель человека в продукте. Формула простая: «Как [кто], хочу [что], чтобы [зачем]»

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

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

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

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

При этом пользовательская история полезна и в других рабочих материалах — в брифах, редакционных ТЗ, сценариях обучения. Например, в ТЗ для автора можно указать: «Как студент курса по профессии продакт-менеджера, благодаря этой статье хочу усвоить понятие user story, чтобы применять его при подготовке ТЗ к проектам». Такая фраза сразу задает фокус: для кого мы пишем, какой вопрос статья должна закрыть и как оценивать ее пользу.

Из чего состоит хорошая пользовательская история

Формула user story всегда одинаковая: роль → действие → ценность. Главное здесь — лаконичность. Не стоит расписывать целый абзац в попытках лучше погрузить команду в контекст. 

Хорошую пользовательскую историю всегда сопровождает список условий результата (acceptance criteria). По-простому: как мы поймем, что все работает как надо и задача выполнена. Условия пишут понятными фразами. Можно использовать форму «Если/Когда/То».

Допустим, user story звучит так: «Как пользователь, хочу менять пароль по коду из письма, чтобы быстро восстановить доступ».

Тогда условия результата могут быть такие:

1. Если код введен верно, новый пароль сохраняется, пользователь видит подтверждение.
2. Если код неверный — показываем ошибку, повторная отправка кода доступна через 60 секунд.
3. Ссылка из письма действует 15 минут.
4. Все действия записываются в журнал событий.

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

Для проверки эффективности пользовательской истории, можно использовать чек-лист INVEST. Акроним предложил Билл Уэйк: каждая буква — это критерий, по которому понятно, достаточно ли история ясна, компактна и готова к работе.

• I (Independent — Независимая): историю можно делать и выпускать отдельно, без обязательной связи с другими задачами. 
• N (Negotiable — Обсуждаемая): формулировка короткая и оставляет место для обсуждения решения. История не превращается в мини-ТЗ с «как именно».
• V (Valuable — Ценная): понятна польза для человека или бизнеса. Можно одним предложением объяснить, какую проблему снимаем.
• E (Estimable — Оцениваемая): команда понимает объем работ и риски. Если оценить не получается, не хватает данных или ясности — добавьте их.
• S (Small — Небольшая): работа умещается в короткий цикл. Если нет — разделите на несколько историй по шагам.
• T (Testable — Проверяемая): можно проверить результат по понятным условиям: что должно произойти, что увидит пользователь, какие ошибки учитывать.

Место user story в процессе разработки

В продуктовой работе есть ряд понятий, который описывает опыт пользователя. Они дополняют друг друга, но работают с разным уровнем детализации:

• CJM (Customer Journey Map) — карта пути пользователя. Показывает этапы взаимодействия с продуктом, ожидания и проблемы на каждом этапе. Отвечает на вопрос: где у человека возникает задача/боль.
• User flow — схема действий внутри одного сценария в продукте (экраны/шаги/переходы). Отвечает на вопрос: как человек проходит путь в продукте.
• User story — одна короткая цель пользователя. Отвечает на вопрос: что именно хочет сделать пользователь в ближайшем шаге и зачем ему это.

CJM и user flow — документы про весь маршрут пользователя: они охватывают все этапы и сценарии, а не одну точечную доработку. Техническое задание дробится на небольшие задачи, и поэтому в нем обязательно есть user story: одна история — одна небольшая задача с понятным результатом. 

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

Выбор точки улучшения и формулировка истории. Смотрим на сценарий оформления заказа в приложении: пользователь выбирает блюдо, добавляет его в корзину, оплачивает и ждет доставку. На этапе выбора блюда возникает неудобство: нельзя убрать ненужный ингредиент (например, лук в бургере). Формулируем историю: «Как пользователь приложения по доставке еды, хочу иметь возможность убирать ненужные ингредиенты из блюда при оформлении заказа, чтобы не связываться с рестораном отдельно». 

Определение, каким должен быть результат (AC). Пишем 4–8 условий результата: что должно произойти, что видит пользователь, какие ошибки учитываем, какие ограничения действуют (время, количество попыток и т. п.). В случае с сервисом доставки еды:

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

Сборка ТЗ для разработки. История остается первой строкой карточки — все остальное раскрывает, как именно это должно быть сделано. К ней и условиям результата прикладываем:

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

Оценка и план действий. Команда оценивает объем и риски. Нужно доработать интерфейс, бизнес-логику и интеграцию с ресторанами. Владелец истории (продакт-менеджер) выбирает, что даст больший эффект для улучшения опыта:

• вариант 1: добавить возможность убрать только один ингредиент (например, лук) — этот способ проще, можно сделать только один чек-бокс «без лука», но это сработает только на часть целевую аудитории;
• вариант 2: дать пользователю управлять всем списком ингредиентов — этот вариант сложнее, но закрывает большее количество запросов (например, у кого-то аллергия на майонез или кто-то не ест помидоры), поэтому он приоритетнее.

Тестирование и релиз. Работа принимается, если все условия AC выполнены — это проверяется на тестовых запусках. На тестах проверяют: удаляется ли ингредиент из карточки, правильно ли формируется заказ для ресторана, корректно ли пересчитывается цена. Если какой-то пункт не выполнен — история не готова к релизу. После релиза команда смотрит на метрику: снизилось ли количество отмен и обращений в поддержку по поводу «замены ингредиентов в блюде». Если да — история закрыта успешно.

Коротко о главном

• User story пишется для одной маленькой задачи. Ее можно (и нужно) описать одной строчкой.
• Держите связь с контекстом. Опирайтесь на CJM и user flow, но в историю переносите только ближайший шаг, который дает пользу сейчас.
• К пользовательской истории всегда прописывайте несколько условий результата (4–8 пунктов), в том числе и негативных (если у пользователя не сработала функция).
• Не пишите истории в одиночку. Формулируйте и уточняйте историю вместе с разработкой, дизайном и тестированием — это снижает разночтения.
• В дополнение к user story можно писать о том, с какой проблемой ранее столкнулись пользователи, что и почему оказалось неудобно.