Как передаются требования по проекту от аналитика: текстом или другим способом

Как передаются требования от аналитика к разработчику

Это хороший вопрос, который касается процессов в команде. Давайте разберём разные подходы.

Вариант 1: Agile (Scrum) — самый распространённый

Процесс:

1. Аналитик пишет ЗАДАЧУ (Ticket/Task)
   ├── Title: "Реализовать экспорт отчёта в PDF"
   ├── Description: "Пользователь должен иметь возможность..."
   ├── Acceptance Criteria:
   │   ├── Когда я нажму кнопку Export → загрузится PDF
   │   ├── PDF содержит все строки таблицы
   │   ├── Размер файла не более 10MB
   │   └── Экспорт работает за < 5 секунд
   ├── Priority: High
   ├── Story Points: 8
   └── Attachments: скриншоты, макеты

2. Инструменты: JIRA, Azure DevOps, Trello, GitHub Issues

3. Процесс:
   ├── Аналитик создаёт задачу
   ├── На встречу (Refinement) обсуждаем
   ├── Разработчик уточняет вопросы
   ├── Добавляется в спринт
   ├── Разработчик берёт и реализует
   ├── Тестировщик проверяет по Acceptance Criteria
   └── Задача в Done

Пример реальной задачи в JIRA:

SUMMARY: Implement email verification for new users

DESCRIPTION:

## User Story
As a user, I want to verify my email address, so that I can secure my account.

## Acceptance Criteria
- [ ] When user registers, they receive verification email
- [ ] Email contains unique verification link with 24h expiration
- [ ] Clicking link marks email as verified in database
- [ ] User can't access app until email is verified
- [ ] Resend verification email button available
- [ ] After 3 failed attempts, account is locked for 1 hour

## Technical Notes
- Use SendGrid API for emails
- Store verification token in Redis (24h TTL)
- Add migration for verified_at column
- Create unit and integration tests

## Definition of Done
- Code reviewed and approved
- Unit tests: 90% coverage
- Integration tests pass
- Manual testing by QA
- Documentation updated
- No warnings in SonarQube
- Database migrations tested

Priority: High
Story Points: 13
Epic: User Authentication
Assignee: @developer1
Reporter: @analyst1

Вариант 2: Waterfall (каскадный) — в крупных проектах

Процесс:

1. Аналитик пишет ТРЕБОВАНИЯ (Requirements Document)
   ├── 50+ страниц
   ├── PRD (Product Requirements Document)
   ├── Use Cases
   ├── Data Flow Diagrams
   ├── Wireframes
   ├── API specifications
   └── Detailed workflows

2. Встреча: Аналитик 2-3 часа объясняет разработчикам

3. Разработчик пишет ТЕХНИЧЕСКИЙ ДИЗАЙН (TDD) на 30-50 страниц
   ├── Архитектура
   ├── Database schema
   ├── API endpoints
   ├── Error handling
   └── Testing strategy

4. Начало разработки (по плану)

Для: gov.ru, финтеха, медицины (строгие требования)

Вариант 3: Kanban — непрерывный поток

          To Do       →    In Progress    →    Review    →    Done
┌──────────────────┬──────────────────┬──────────────────┐
│ Задачи аналитика │ Работает dev     │ Проверяет QA     │
│ (очередь)        │ (макс 3 шт)      │ (макс 2 шт)      │
└──────────────────┴──────────────────┴──────────────────┘

Процесс:
- Аналитик создаёт задачу
- Как только dev освободился → берёт задачу
- Реализует → на Review
- Тестер проверяет → Done

Для: стартапов, быстрых продуктов

Вариант 4: Direct Communication (в малых командах)

Процесс:
- Аналитик говорит разработчику в Slack/Teams
- "Нужна кнопка для экспорта в Excel"
- Dev: "Окей, какие колонки экспортируем?"
- Analyst: "Все кроме ID и timestamp"
- Dev пишет в блокнот (или JIRA на скорую руку)
- Реализует
- Показывает в Slack

Лучше всегда создать задачу потом, для истории.

Вариант 5: Confluence + JIRA (документация + задачи)

Конфлюэнс (документация):
├── Product Roadmap
├── Features specification
├── API documentation
├── Architecture decisions
└── Runbooks

JIRA (задачи):
├── Ссылка на Confluence
├── Acceptance Criteria
├── Testing checklist
└── Related tasks

Это стандарт в enterprise компаниях.

Форматы требований:

Текстовый (самый частый):

Требование: Реализовать фильтр по датам
Описание: Пользователь должен выбрать Start date и End date
Ожидаемый результат: Таблица показывает только записи в диапазоне
Приоритет: Medium
Дедлайн: 15 марта

Диаграммы (для сложного функционала):

[Diagrams.net, Miro, Lucidchart]
- User flow diagrams
- Database ERD
- API sequence diagrams
- State machines

Макеты (для UI):

[Figma, Adobe XD, Sketch]
- Wireframes
- High-fidelity designs
- Component library
- Design system

Видео (для сложных UI):

Аналитик записывает видео (2-5 мин):
- Демонстрирует нужный функционал
- Показывает примеры
- Объясняет ожидания
Разработчик может пересмотреть много раз

Реальный пример процесса:

9:00 Аналитик создаёт JIRA задачу:
└─ "Add multi-language support for email notifications"

10:00 Планирование спринта:
├─ Аналитик объясняет за 5 минут
├─ Разработчик: "Сколько языков? Есть переводчик?"
├─ Аналитик: "10 языков, переводы уже готовы в Google Sheets"
├─ Dev: "Ок, 5 точек"
└─ Добавляем в спринт

10:30 Аналитик обновляет JIRA:
├─ Добавляет ссылку на Google Sheets
├─ Пишет примеры в разные локали
├─ Добавляет скриншот старого UI
└─ Ставит себя как Reporter

11:00 Разработчик берёт задачу:
├─ Читает Description
├─ Смотрит Google Sheets
├─ Пишет в Slack: "Спросил бы — где брать текущий язык пользователя?"
├─ Аналитик отвечает: "Из user.language field в базе"
└─ Dev начинает писать код

14:00 Dev заканчивает, создаёт PR:
├─ Ссылает на JIRA задачу
├─ Пишет технические детали реализации
└─ На review идёт Team Lead

15:00 CR прошёл, merge в develop
├─ Аналитик видит сообщение в Slack
├─ На stage окружение поднялось новое
└─ Тестирует в браузере

16:00 QA тестирует по Acceptance Criteria:
├─ Рассылка на русском? ✓
├─ На английском? ✓
├─ На китайском? ✓
├─ Срабатывает за < 100ms? ✓
└─ Задача → Done

Что НЕ делать:

❌ Передавать требования только устно (забывают)
❌ Писать всё в Word (не удобно для dev'а)
❌ Не давать Acceptance Criteria (непонятно, когда готово)
❌ Менять требования без новой задачи (хаос)
❌ Забывать про граничные случаи ("А что если...")
❌ Не давать доступ к исходным данным (макеты и прототипы)

Инструменты в компаниях:

Стартапы:
→ Slack + Google Docs + Figma + простой JIRA

Средние (50-500 человек):
→ JIRA + Confluence + Figma + GitHub

Large Enterprise:
→ JIRA + Confluence + Azure DevOps + Sharepoint + Teams

FinTech/Gov:
→ JIRA + собственная документация + Visio + Rational Rose

Главное:

Отличный разработчик не просто исполняет требование, он:

1. Уточняет — всегда спрашивает "А что если...?"
2. Документирует — пишет в JIRA, что именно сделал
3. Обсуждает — с аналитиком, если видит проблему
4. Тестирует — не только по критериям, но и граничные случаи
5. Проверяет — показывает результат перед финалом

Хорошее требование + хороший разработчик = хороший продукт.