Приведи пример User Story

Приведи пример User Story

User Story — это способ описания требования с точки зрения пользователя, а не системы. Вот полный пример с моего реального проекта.

Контекст проекта

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

User Story #1: Экспорт счёта в PDF

ID: FIN-047
Тип: Story
Приоритет: High (важно для клиентов)
Оценка: 8 story points
Ответственный: Ваня Петров (Backend)
Дизайнер: Маша Сидорова
Тестировщик: Петя Иванов

---

ЗАГОЛОВОК:
Как фрилансер, я хочу экспортировать счёт в PDF

ОПИСАНИЕ:
Мне нужно отправить счёт клиенту. Сейчас я вручную переписываю данные в Word, это занимает 15 минут. Хочу нажать одну кнопку и получить готовый PDF, который я сразу отправлю по email.

ДЕТАЛИ:
- Счёт должен содержать мои реквизиты (ИНН, банк), данные клиента, список услуг с ценами
- PDF должен выглядеть профессионально (красивый шаблон, логотип)
- Должен быть номер счёта и дата (автоматически)
- Клиент должен видеть ссылку "Download PDF" на странице счета

МОТИВАЦИЯ:
- Сейчас потребляю 30 мин на все счета в месяц
- Клиенты просят счета в нормальном виде, а не скриншот
- Это делает мой бизнес более профессиональным

---

ACCEPTANCE CRITERIA (Критерии приёма):

[ ] На странице счета есть кнопка "Download PDF"
[ ] При нажатии скачивается файл invoice-123.pdf
[ ] PDF содержит:
    - Мои реквизиты (берутся из профиля)
    - Реквизиты клиента
    - Список услуг (название, количество, цена за единицу, сумма)
    - Итого сумма
    - Номер счета и дату
    - Мой логотип (если загружен в профиле)
[ ] PDF красиво форматирован (по стандарту A4)
[ ] Если услуг больше чем 10, они переходят на вторую страницу
[ ] Валюта показывается правильно (RUB = ₽, USD = $)
[ ] Если счет в статусе "Paid", на PDF видна печать "ОПЛАЧЕНО"
[ ] Все спец символы (ё, ц, ш) отображаются корректно

---

ЛОГИЧЕСКИЕ ГРАНИЧНЫЕ СЛУЧАИ (Edge Cases):

1. Счет с одной услугой — проверить форматирование
2. Счет с 50 услугами — проверить нумерацию и переносы
3. Длинное название клиента (30+ символов) — не должно вылезть
4. Без логотипа в профиле — PDF все равно выглядит хорошо
5. Клиент удалил счет — кнопка Download должна быть неактивна
6. Счет в статусе Draft — кнопка должна быть неактивна (можно менять)

---

ТЕХНИЧЕСКИЕ ЗАМЕТКИ:

Бэкенд:
- Использовать библиотеку ReportLab (Python) или PDFKit
- Endpoint: POST /api/v1/invoices/{id}/generate-pdf
- Ответ: бинарные данные PDF
- Кешировать результат на 1 час (если счет не менялся)
- Логировать все экспорты (кто, когда, какой счет)

Фронтенд:
- Кнопка visible только когда счет в статусе Sent/Paid/Draft
- При клике показать loader (экспорт может занять 1-2 сек)
- Если ошибка, показать "Failed to export, try again"
- Скачанный файл назвать по паттерну: invoice-{id}-{date}.pdf

Дизайн:
- PDF шаблон в Figma (ссылка в комментариях)
- Цвета из бренда (не жестко зелёные/красные)
- Ориентация: портрет (A4)

Тестирование:
- Скачать PDF с разных браузеров
- Проверить размер файла (не должен быть > 2 MB)
- Открыть в 5 разных PDF readers (Adobe, Preview, чтение с мобилки)
- Распечатать на принтере (выглядит хорошо на бумаге)

Деплой:
- Новая система требует установки дополнительной библиотеки
- Нужна миграция БД? НЕТ
- Есть ли breaking changes? НЕТ
- Можно откатить? ДА, просто удалить кнопку

---

ДЕПЕНДЕНСИ (Зависимости):

- Зависит от: FIN-045 (страница счета)
- Нужна для: FIN-050 (автоматическая отправка по email)

---

CОПИЛГОТОВЛЕНОСТИ (Definition of Done):

Если все это готово, Story считается Done:

[ ] Код написан и reviewed (code review passed)
[ ] Unit тесты написаны (coverage > 80%)
[ ] E2E тест: скачан PDF, проверен формат
[ ] QA тестировщик проверил на Edge Cases
[ ] Release Notes написаны
[ ] Документация (для пользователя) готова
[ ] Никаких open bugs, все critical зафиксированы
[ ] Демонстрация продакт-менеджеру (одобрение)

Почему это хорошая User Story?

1. Имеет четкую структуру

• Заголовок по стандарту "Как [кто], я хочу [что], чтобы [зачем]"
• Это помогает всем понять цель

2. Содержит Acceptance Criteria (критерии приёма)

• Разработчик ТОЧНО знает, когда считать готово
• QA знает, что тестировать
• Нет неопределённости "готово или нет?"

3. Документирует граничные случаи

• Что если 50 услуг?
• Что если без логотипа?
• Это экономит часы переделок потом

4. Есть технические заметки

• Какую библиотеку использовать
• Какой endpoint
• Как кешировать
• Это помогает разработчикам ориентироваться

5. Содержит контекст

• "Мне сейчас нужно 30 минут" — это обосновывает ценность
• "Клиенты просят счета в нормальном виде" — это мотивирует

6. Указаны зависимости и Definition of Done

• От чего зависит эта Story?
• Для чего она нужна?
• Что такое готово?

---

Сравнение: Bad Story vs Good Story

BAD Story (как БЕ делают):

ID: FIN-047
Титл: "Экспорт PDF"
Описание: "Пользователи хотят экспортировать счет в PDF"

То всё. Больше ничего.

Проблемы:

• Разработчик не знает, в каком формате PDF
• QA не знает, что тестировать
• 3 дня разработки, потом "это же не то, что я хотел!"

---

GOOD Story (как ПРАВИЛЬНО делают):

Это то, что я показал выше. Все детали, все граничные случаи, все критерии приема.

---

Жизненный цикл этой Story

Спринт Planning (Понедельник)

• Я (BA) рассказываю Story разработчикам
• Разработчик: "А если счет без налогов?"
• Я: "Добавляю в Edge Cases"
• Оценка: 8 points
• Ваня (разработчик) берет Story

Среда

• Ваня спрашивает: "Какую PDF библиотеку использовать?"
• Я: "ReportLab, я указал в технических заметках. Или предложи свой вариант"
• Ваня начинает писать код

Пятница

• Ваня сделал, показал демо
• Я смотрю: "Отлично, но когда нет логотипа, место для логотипа пустое. Зафиксить?"
• Ваня берет новый bug

Понедельник (следующей недели)

• Petya (тестировщик) проверяет
• Петя скачал PDF на 5 разных браузерах
• Петя открыл в 3 читалках
• Петя: "All good, можно в production"
• Story в Done

---

Вывод

Хорошая User Story:

• Ясная — понятна даже нетехничному человеку
• Полная — не нужно гадать, что делать
• Проверяемая — есть четкие критерии приёма
• Реалистичная — можно сделать за спринт
• Ценная — понятна бизнес-ценность

Это не просто текст в Jira, это контракт между Product Owner и Development Team. Когда оба стороны четко понимают, что нужно делать, проекты выполняются на 90% быстрее.