От кого поступают требования?

От кого поступают требования

Это важный вопрос о взаимодействии и иерархии информации. Требования поступают из разных источников, и задача BA — правильно их собрать, валидировать и приоритизировать. Давайте разберёмся в источниках и как с ними работать.

Основные источники требований

1. Бизнес / Стейкхолдеры (Business Stakeholders)

• CEO / Product Manager / VP Product — видят большую картину и бизнес-цели
• Финансовый отдел (CFO) — даёт бюджетные ограничения
• Marketing / Sales — говорят, что просят клиенты, конкуренты
• Board of Directors / Инвесторы — стратегические направления

Что они дают:

• "Нам нужна фича для привлечения 10% больше клиентов"
• "Бюджет на разработку — 100к в месяц"
• "Конкурент добавил X, мы отстаём"

2. Пользователи / Клиенты (End Users)

• Прямой feedback через опросы, интервью, чат поддержки
• Аналитика: какие фичи используют, где падают
• User Testing: наблюдение, как люди используют продукт
• NPS comments: что нравится, что нет

Что они дают:

• "Было бы удобно, если бы..."
• "Это раздражает, когда..."
• Поведенческие данные: где люди зависают, где уходят

3. Отдел поддержки / Customer Success

• Tickets и support requests
• Наиболее частые вопросы
• Баги, которые мучают пользователей
• Идеи клиентов, которые звучат разумно

Пример:

• "50 клиентов в месяц спрашивают, почему нельзя экспортировать данные в CSV"
• Это сигнал, что нужна фича экспорта

4. Техническая команда (Developers, QA, DevOps)

• Technical Debt: что нужно рефакторить, чтобы работало быстрее
• Scalability issues: что сломается при 1 млн пользователей
• Security concerns: уязвимости, которые нужно закрыть
• Performance improvements: что замедляет приложение

Пример:

• DevOps: "Каждый deploy занимает 30 минут, нужно автоматизировать"
• Security: "Храним пароли в plain text, нужно хешировать"

5. Регуляторы / Compliance

• Закон / регулирующие органы
• GDPR, PCI DSS, банковские требования
• Лицензирование
• Налоговые требования

Пример:

• GDPR: "Пользователи должны иметь право удалить свои данные в течение 30 дней"
• PCI DSS: "Нельзя хранить полные номера кредитных карт"

6. Аналитика и Data (Data Science, Product Analytics)

• Метрики показывают, где проблемы
• Когортный анализ: какие пользователи уходят?
• Funnel analysis: на каком шаге люди прерывают?
• Predictive models: какие фичи будут успешны?

Пример:

SELECT 
  DATE_TRUNC('month', signup_date) as month,
  COUNT(DISTINCT user_id) as new_users,
  COUNT(DISTINCT CASE WHEN retention_30d THEN user_id END) as retained,
  ROUND(100.0 * COUNT(DISTINCT CASE WHEN retention_30d THEN user_id END) 
    / COUNT(DISTINCT user_id), 2) as retention_rate
FROM users
GROUP BY DATE_TRUNC('month', signup_date)
ORDER BY month DESC;

Этот запрос показывает, что retention падает → нужно понять почему и что делать.

Структура иерархии требований

Стратегия (Business Goals)
    ↓
Roadmap (Чего достигаем в квартал)
    ↓
Features (Конкретные фичи)
    ↓
User Stories (Детальные требования)
    ↓
Acceptance Criteria (Как проверить, что готово)
    ↓
Tasks (Для разработчиков)

Пример цепи:

• Стратегия: "Стать #1 платформой для X за 2 года"
• Roadmap: "В Q2 добавляем интеграции с популярными сервисами"
• Feature: "Интеграция с Slack"
• User Story: "Как администратор, я хочу отправлять уведомления в Slack, чтобы команда была в курсе обновлений"
• Acceptance Criteria:
  • Администратор может связать аккаунт Slack
  • При событии X отправляется сообщение в Slack
  • Сообщение содержит необходимую информацию
• Task: "Implement OAuth 2.0 for Slack"

Как BA собирает требования

Процесс Discovery

1. Интервью — разговоры с ключевыми людьми

   • "Какую проблему мы решаем?"
   • "Кто пострадает, если это не сделаем?"
   • "Какой успех выглядит?"

2. Research — поиск данных

   -- Какие операции самые медленные?
   SELECT operation, AVG(duration_ms) as avg_duration
   FROM operations_log
   GROUP BY operation
   ORDER BY avg_duration DESC;
   

3. Analysis — анализ информации

   • Наложение данных из разных источников
   • Поиск противоречий: что хочет бизнес vs что нужно пользователям?

4. Synthesis — синтез в требования

   • Написание User Stories
   • Определение приоритетов

5. Validation — проверка

   • Показываем требования стейкхолдерам
   • Получаем согласие

Конфликты требований: как разрешить

Часто требования противоречат друг другу:

Сценарий 1: CEO vs пользователи

• CEO: "Добавим Premium подписку"
• Пользователи: "Основной продукт должен быть бесплатным"

Решение:

• Анализируем, что даёт больше value
• Может быть hybrid: базовый функционал бесплатный, премиум платный
• Проводим A/B test

Сценарий 2: Бизнес vs Technical Debt

• Бизнес: "Нужна новая фича, deadline неделя"
• Разработчики: "Код в ужасном состоянии, нужна рефакторка"

Решение:

• Коротко: 20% спринта на рефакторку, 80% на фичи
• Долго: показываем данные, сколько стоит технический долг
• Пример: "За счёт плохого кода разработчики делают на 30% медленнее"

Сценарий 3: Клиент просит, но мало кому нужно

• Крупный клиент: "Нужна фича X"
• Данные: только этот клиент просит, остальным не нужно

Решение:

• Уточняем: это custom разработка или feature?
• Если custom: клиент платит дополнительно
• Если feature: показываем данные, сколько это будет стоить в разработке vs сколько принесёт в revenue

Мой совет по приоритизации

Framework: Impact vs Effort

Высокий Impact,
Низкий Effort
    ↑
    │   ★ ★ ★ ДЕЛАЙ ПЕРВЫМ
    │
    │
Низкий Impact,
Низкий Effort
    │   ★ ★
────┼──────────→ Effort
    │
    │   ★
Высокий Impact,
Высокий Effort

Также смотрим на:

• Urgency — когда это нужно?
• Alignment with strategy — это помогает достичь goal?
• Dependencies — это зависит от других работ?
• Risk — что будет, если это не сделаем?

Итоговая таблица источников

Последний важный момент

BA не просто собирает требования — BA валидирует их.

Если стейкхолдер говорит "нужна фича X", я спрашиваю:

• Почему это нужно? (цель)
• Кто будет это использовать? (пользователи)
• Как это измерить успех? (метрики)
• Какой budget? (ресурсы)
• Когда это критично? (urgency)

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