User stories: как заказчику описывать функции продукта

Что такое user story и зачем она заказчику

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

Классический шаблон:

Как [роль], я хочу [действие], чтобы [цель или выгода].

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

Три части хорошей истории

• Роль. Конкретный тип пользователя: «покупатель», «менеджер склада», «администратор». Не «пользователь» вообще, если ролей несколько.
• Действие. Что человек делает в продукте. Одно действие — одна история.
• Цель. Зачем ему это. Именно цель помогает команде предложить решение проще или лучше, чем вы задумали.

Критерии приёмки: без них история не закончена

Критерии приёмки (acceptance criteria) — это проверяемые условия, при которых функция считается готовой. Без них «готово» у вас и у разработчика будет означать разное.

Удобный формат — Given / When / Then (Дано / Когда / Тогда):

• Дано: исходная ситуация.
• Когда: действие пользователя.
• Тогда: ожидаемый результат.

Каждый критерий должен быть таким, чтобы его можно было проверить «да/нет».

Плохой и хороший пример

Плохо:

Нужна нормальная корзина, как у крупных магазинов, чтобы было удобно.

Непонятно, кто пользователь, что значит «нормальная» и как проверить результат.

Хорошо:

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

Критерии приёмки:

1. Дано: в корзине есть товар. Когда покупатель нажимает «+», тогда количество увеличивается на 1 и итоговая сумма пересчитывается.
2. Когда количество становится 0, тогда товар удаляется из корзины.
3. Когда покупатель пытается добавить больше, чем есть на складе, тогда показывается сообщение об остатке.

Такую историю можно оценить, реализовать и проверить без дополнительных созвонов.

Как писать истории: пошаговый подход

1. Перечислите роли в продукте: кто им пользуется и кто им управляет.
2. Для каждой роли выпишите задачи, которые человек решает. Не экраны, а именно задачи.
3. Сформулируйте истории по шаблону — по одной на действие.
4. Добавьте критерии приёмки: обычный сценарий, ошибки, граничные случаи.
5. Расставьте приоритеты: что нужно для первой версии, а что можно позже.
6. Обсудите с командой. История — повод для разговора, а не договор, который нельзя менять.

Частые ошибки заказчиков

• Слишком крупная история. «Как владелец, я хочу CRM» — это не история, а целый продукт. Делите до задач, которые реализуются за несколько дней.
• Готовое решение вместо цели. «Хочу выпадающий список» вместо «хочу быстро выбрать город». Укажите цель — команда может предложить вариант удобнее.
• Нет цели вообще. Без «чтобы» сложно понять приоритет и проверить, решает ли функция проблему.
• Размытые критерии. «Быстро», «удобно», «красиво» нельзя проверить. Пишите измеримо или описывайте конкретное поведение.
• Забытые ошибки. Что будет, если интернет пропал, поле пустое или оплата не прошла?

Чек-лист перед отправкой команде

• Роль конкретная?
• Одно действие в истории?
• Есть «чтобы» с понятной выгодой?
• Критерии приёмки проверяются «да/нет»?
• Описаны ошибки и граничные случаи?
• Указан приоритет?