User Stories: как писать, чтобы разработчики не переспрашивали

User Story — короткое описание функциональности с точки зрения пользователя. Формат простой, но написать историю так, чтобы разработчик не пришёл с десятью уточняющими вопросами — отдельный навык. Разберём, как писать User Stories, которые работают: от формулировки до критериев приёмки.

Формат User Story

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

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

Пример:

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

Почему три части, а не одна

Часть	Что даёт	Кому нужна
Роль	Контекст: кто использует	UX-дизайнеру, разработчику
Действие	Что именно реализовать	Разработчику
Ценность	Зачем это нужно	Product Owner, для приоритизации

Без «ценности» история превращается в техническое задание. Без «роли» — непонятно, чей это интерфейс.

Критерии приёмки (Acceptance Criteria)

User Story без критериев приёмки — это пожелание. Критерии превращают её в контракт.

Формат Given-When-Then

Дано: менеджер находится на странице «Сделки»
Когда: он выбирает фильтр «Переговоры»
Тогда: отображаются только сделки со стадией «Переговоры»
  И: количество отображённых сделок показано в заголовке
  И: фильтр сохраняется при переходе на другую страницу и обратно

Формат чек-листа

Для простых историй подходит список:

✅ Фильтр содержит все стадии воронки из настроек
✅ Можно выбрать несколько стадий одновременно
✅ Кнопка «Сбросить» очищает все фильтры
✅ При отсутствии сделок — сообщение «Нет сделок на выбранных стадиях»
✅ Фильтр работает без перезагрузки страницы

Сколько критериев — достаточно?

3–7 критериев — оптимально
1–2 — скорее всего, история недоопределена
10+ — скорее всего, историю нужно разбить

Принцип INVEST

Хорошая User Story соответствует шести критериям:

I — Independent (независимая)

Историю можно реализовать, протестировать и выпустить отдельно от других.

❌ «Как пользователь, я хочу оформить заказ» — зависит от корзины, каталога, оплаты.

✅ «Как пользователь, я хочу выбрать способ доставки при оформлении заказа» — конкретная, изолированная задача.

N — Negotiable (обсуждаемая)

История — не контракт, а начало разговора. Детали уточняются при планировании.

E — Estimable (оцениваемая)

Команда может оценить трудоёмкость. Если не может — история слишком большая или неопределённая.

S — Small (маленькая)

Реализуется за один спринт (обычно 1–5 дней работы разработчика).

T — Testable (тестируемая)

Можно написать тест, который проверит: история реализована или нет.

V — Valuable (ценная)

Приносит ценность пользователю или бизнесу. «Рефакторинг базы данных» — не User Story.

Эпики, истории и подзадачи

Эпик (Epic)
└── User Story
    └── Подзадача (Task)

Уровень	Размер	Пример
Эпик	Недели–месяцы	«Личный кабинет клиента»
User Story	Дни	«Как клиент, я хочу видеть историю заказов»
Подзадача	Часы	«Создать API-эндпоинт /orders»

Бизнес-аналитик пишет User Stories. Подзадачи — ответственность разработчиков. Эпики — совместная работа с Product Owner.

Разбиение больших историй

Большая история (Epic) бесполезна для планирования. Вот способы разбиения:

По шагам процесса

Эпик: «Оформление заказа»
→ Выбор товаров из каталога
→ Добавление в корзину
→ Выбор способа доставки
→ Выбор способа оплаты
→ Подтверждение заказа
→ Уведомление об успешном оформлении

По ролям

Эпик: «Управление заказами»
→ Как клиент, я хочу отменить заказ
→ Как менеджер, я хочу изменить статус заказа
→ Как логист, я хочу назначить курьера на заказ

По бизнес-правилам

Эпик: «Скидки»
→ Скидка по промокоду
→ Скидка за объём заказа
→ Персональная скидка по программе лояльности

По данным

Эпик: «Профиль клиента»
→ Просмотр основных данных (ФИО, email, телефон)
→ Редактирование контактных данных
→ Загрузка аватара
→ Удаление аккаунта

Типичные ошибки

Ошибка 1: технические истории

❌ «Как разработчик, я хочу настроить Docker-контейнер для микросервиса заказов»

Это задача, а не User Story. User Story описывает ценность для конечного пользователя.

✅ «Как покупатель, я хочу получать подтверждение заказа в течение 3 секунд» — и уже разработчик решает, нужен ли Docker.

Ошибка 2: слишком общие истории

❌ «Как пользователь, я хочу удобный интерфейс»

«Удобный» — не измеримо, не тестируемо. Нарушает T в INVEST.

✅ «Как пользователь, я хочу завершить оформление заказа не более чем за 3 шага»

Ошибка 3: решение вместо проблемы

❌ «Как менеджер, я хочу кнопку "Экспорт в Excel" на странице отчётов»

Кнопка — это решение. Какую проблему она решает?

✅ «Как менеджер, я хочу получить данные по продажам за месяц в формате, пригодном для анализа в Excel, чтобы подготовить отчёт для директора»

Может оказаться, что лучше автоматический отчёт на email, а не кнопка.

Ошибка 4: пропущенные негативные сценарии

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

Критерии приёмки:
✅ Оплата проходит, заказ подтверждён

А что если:

Карта отклонена?
Таймаут при обращении к платёжной системе?
Двойное списание?
Сумма изменилась между добавлением в корзину и оплатой?

Негативные сценарии — то, что отличает проработанную историю от наброска.

Ошибка 5: нет связи с бизнес-процессом

User Stories не живут в вакууме. Каждая история — часть процесса. Если вы не знаете, в каком процессе живёт история — начните с описания бизнес-процесса, а не с User Stories.

User Stories vs другие форматы

Сравнение с форматами из статьи BRD vs SRS vs User Stories:

Параметр	User Story	Use Case	Требование в SRS
Объём	1–3 предложения + AC	1–3 страницы	1 предложение
Детализация	Средняя	Высокая	Высокая
Формализм	Низкий	Средний	Высокий
Где применять	Agile-проекты	Сложные сценарии	Waterfall, госзаказ
Кто читает	Вся команда	Аналитик, разработчик	Разработчик

User Stories хороши в Agile-проектах. Для Waterfall или проектов с жёсткими требованиями к документации используйте Use Cases или SRS.

Шаблон карточки User Story

ID: US-042
Эпик: Управление заказами
Приоритет: High

Как менеджер по продажам,
я хочу видеть уведомление при поступлении нового заказа,
чтобы обработать его в течение 15 минут (SLA).

Критерии приёмки:
✅ Уведомление появляется в течение 10 секунд после создания заказа
✅ Уведомление содержит: номер заказа, сумму, имя клиента
✅ Клик по уведомлению открывает карточку заказа
✅ Уведомление исчезает через 30 секунд или по клику
✅ Если менеджер оффлайн — уведомление ждёт его при входе
✅ Звуковой сигнал можно отключить в настройках

Примечания:
- Проверить: одно уведомление всем менеджерам или только ответственному?
- Интеграция с Telegram-ботом — отдельная история (US-043)

Итог

User Story — не формальность, а инструмент коммуникации. Хорошая история — та, по которой разработчик может начать работу, тестировщик — написать тесты, а Product Owner — принять результат. Используйте INVEST как чек-лист, критерии приёмки как контракт, и не забывайте про негативные сценарии.

Нужна помощь с декомпозицией требований? Напишите — помогу превратить бизнес-задачу в набор User Stories, готовых к разработке.