От кого получаешь требования?

Источники требований для Business Analyst

Один из главных вопросов в работе BA — "от кого получать требования?" Неправильный выбор источников приводит к пустой трате времени, конфликтам и неверным приоритетам. За 10+ лет я выделил четких категории стейкхолдеров и их роли в формировании требований.

Ключевые источники требований

1. Product Manager (PM) — PRIMARY SOURCE

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

Где получать требования:

• Roadmap (квартальный и годовой план)
• Weekly sync встречи
• Документ требований (FRD, Product Specification)
• JIRA tickets, отмеченные как "ready for development"

Как работать:

PM: "Нам нужна функция X"

Ты: "Понял. Какой бизнес результат добавит функция X?"
PM: "Увеличит retention на 5%"

Ты: "Сколько людей это коснётся? Как ты мерить успех?"
PM: "Тестируем на 10% пользователей, метрика — сколько вернулись через неделю"

Теперь у тебя есть контекст и метрика успеха.

2. Пользователи (Users) — SECOND PRIMARY

Помни: требования НЕ всегда приходят от PM. Часто они приходят от пользователей напрямую.

Где получать:

• Customer interviews (опросы)
• Support tickets и feedback
• Analytics (что делают пользователи, где они падают)
• User testing сессии
• NPS и survey responses

Как работать:

Пользователь просит: "Нужна функция фильтрации"

Ты не просто берёшь это требование. Ты спрашиваешь:
- Почему нужна фильтрация? (может быть проблема в поиске)
- Сколько пользователей это просит? (1 или 1000?)
- Готовы ли они за это платить дополнительно?

Потом отправляешь это PM с контекстом.
PM решит: "Это в roadmap" или "Это edge case".

3. Sales и Customer Success — IMPORTANT BUT BIASED

Sales несёт требования от клиентов. Важные требования, но нужно фильтровать.

Проблема с Sales:

• Требования часто для одного большого клиента (не применимо ко всем)
• "Клиент ушёл, потому что нет функции X" (часто ложь, реальная причина в цене)
• Требуют urgent реализации ("клиент ждёт к пятнице!")

Как работать:

Sales: "Клиент Яндекс просит интеграцию с их CRM"

Ты:
1. Спрашиваешь у PM: это в roadmap?
2. Если нет: какого размер клиент? Сколько он платит?
3. Если это 10% выручки: возможно стоит.
4. Если это 0.1% выручки: нет, отложим.

Правило: require каждого крупного клиента проходят через PM, не через Sales→Dev напрямую.

4. Engineering Lead / CTO — TECHNICAL CONSTRAINTS

Это не источник функциональных требований, но источник технических ограничений.

Что получать:

• Технические обязательства (например, "нужно оптимизировать БД до 100ms")
• Архитектурные решения
• Tech debt (что нужно рефакторить)
• Feasibility feedback ("это невозможно за 1 неделю")

Как работать:

Ты: "PM просит кешировать все видео в Cloudinary"
Engineering Lead: "Это даст нам +10GB в месяц, стоимость 500K/мес"

Новая информация → обсуждаешь с PM.
Maybe PM выберет другой способ.

5. Финансы / CFO — BUDGET & METRICS

Источник требований по мониторингу затрат и доходов.

Что получать:

• Аналитика затрат (сколько стоит каждый feature?)
• Требования по профитабильности
• Reporting requirements (какие отчёты нужны для инвесторов)

6. Support / Customer Service — FEEDBACK LOOP

Universe источник информации о реальных проблемах пользователей.

Что получать:

• Частые вопросы от support (может быть missing feature?)
• Жалобы (feature не работает как ожидалось)
• Пожелания (пользователи просят улучшение)

Как использовать: Раз в месяц спрашиваешь Support Lead: "Какие top 5 вопросов вы получали?" Это лучший индикатор того, что нужно улучшить.

Иерархия источников (приоритет)

1. Product Manager (PM) — главный источник
   └─ Roadmap, quarterly planning

2. Пользователи (Users, Customer interviews)
   └─ Аналитика, feedback, NPS

3. Business KPIs (Finance, CEO)
   └─ Какие метрики двигают стратегию

4. Engineering constraints
   └─ Технические ограничения и возможности

5. Sales (большие клиенты)
   └─ Но только после валидации PM

6. Support
   └─ Входящие сигналы о проблемах

Требования, которые НЕ нужно брать

❌ От CEO или директора напрямую

Да, они имеют право задавать требования. Но если они обходят PM, это признак проблемы.

Что делать:

CEO: "Нам нужна функция X"

Ты: "Спасибо за идею. Обсужду это с PM и вернусь с анализом"

Потом спрашиваешь PM:
"Как это вписывается в roadmap? Какой приоритет?"

Если CEO настаивает на срочной реализации, PM должен что-то отложить.
Не твоя задача реализовать всё — PM распределяет приоритеты.

❌ От random сотрудника (не стейкхолдера)

Твой коллега из бухгалтерии предложил идею. Спасибо, но это не требование. Это suggestion.

Твой коллега: "Было бы круто если бы система считала налоги автоматически"

Ты: "Спасибо за идею! Это интересно. Давай обсудим с PM и добавим в backlog"

По не берёшь это как requirement, пока PM не валидирует.

❌ От одного пользователя (outlier)

Пользователь X попросил функцию Y. Не берёшь это как requirement.

Пользователь: "Хочу фильтр по цвету товара"

Сначала:
- Это просит ещё кто-нибудь?
- Это 1% пользователей или 50%?
- Это критично или nice-to-have?

Если только один просит → edge case, не requirement.
Если много просит → requirement.

Как организовать сбор требований

Weekly Requirement Intake Meeting

Участники: PM, Engineering Lead, BA (ты)

Агенда (30 мин):
1. Новые требования от Sales/Support/Users
2. Проверка: валидны ли они?
3. Добавление в backlog (если валидны)
4. Приоритизация
5. Распределение на спринты

Monthly User Feedback Session

Участники: PM, Support Lead, BA (ты)
Цель: что пользователи просят?

Класс требования:
- Много просят (priority high)
- Несколько просят (priority medium)
- Один просил (priority low)

Красные флаги: неправильные источники требований

• ❌ PM не вовлечен, требования придут от CEO напрямую
• ❌ Нет User research, требования основаны на guess PM
• ❌ Sales может дать требование без PM валидации
• ❌ Требования меняются каждый день
• ❌ Нет одного документа, где живут требования

Практический совет

Организуй источники так:

1. Создай ОДИН backlog (Jira, Asana, Notion)
2. Все требования приходят туда (PM, Support, Users, Sales)
3. PM валидирует и приоритизирует
4. Engineering Lead даёт estimate
5. BA пишет детали
6. Разработчик берёт в спринт

Это гарантирует, что требования отфильтрованы и приоритизированы, а не случайно выбраны.