Приведи примеры бизнес требований

Приведи примеры бизнес требований

Бизнес-требования — это описание ТОГО, что нужно достичь (бизнес-цели), а не ЧТО именно разрабатывать. Это отличается от функциональных требований. Приведу конкретные примеры.

Пример 1: E-commerce платформа

Контекст: Компания продаёт товары через интернет, но продажи падают. Нужно их увеличить.

ПЛОХОЕ требование (функциональное, не бизнес-требование):

"Реализовать рекомендации на главной странице.
Показывать 3 товара, которые пользователь часто смотрит.
"

Это ЧТО делать, а не ЗАЧЕМ.

ХОРОШОЕ требование (бизнес-требование):

БИЗНЕС-ТРЕБОВАНИЕ:

Цель: Увеличить средний заказ (Average Order Value, AOV) на 25% за Q2

Контекст:
- Сейчас средний заказ: $45
- Целевой средний заказ: $56
- Разница в выручке: +$150K/месяц

Причина:
- Пользователи часто видят один товар и уходят
- Не знают о других товарах, которые им подойдут
- Конкуренты показывают рекомендации (Яндекс.Маркет, Amazon)

Предполагаемое решение:
- Добавить блок "Рекомендации для вас" на главную
- Система должна анализировать историю просмотров
- Показывать релевантные товары (same category, similar price)

Критерии успеха (KPI):
1. AOV увеличился на 25% (с $45 на $56)
2. CTR на рекомендации > 8%
3. Conversion from recommended items > 3%
4. User feedback: 4+ rating на новую фичу

Цена разработки:
- Estimation: 3 спринта
- Бюджет: $50K

ROI (Return on Investment):
- Доп выручка за год: $1.8M
- Инвестиция: $50K
- ROI: 3600% в первый год

Почему это лучше

1. Ясна БИЗ-цель (увеличить AOV)
2. Есть цифры (25%, $150K)
3. Есть контекст (почему это нужно)
4. Есть критерии успеха (как измерить)
5. CEO одобрит, потому что видит ROI

---

Пример 2: SaaS для управления проектами

ПЛОХОЕ требование:

"Добавить интеграцию с Slack.
Позволить пользователям получать уведомления о новых задачах в Slack.
"

ХОРОШОЕ требование:

БИЗНЕС-ТРЕБОВАНИЕ:

Цель: Снизить время реакции на изменения в проектах с 2 часов на 30 минут

Контекст:
- Пользователи сейчас проверяют приложение каждые 2 часа
- 30% задач теряются, потому что пользователь их не видел вовремя
- В slack пользователи уже смотрят (читают каждые 5 минут)
- Slack — синглпойнт коммуникации для нашей аудитории

Бизнес-эффект:
- Меньше просроченных задач → больше продуктивности
- Больше notifications → выше engagement пользователей с продуктом
- Меньше поддержки ("почему я не видел задачу?") → снижение costs

Предполагаемое решение:
- Интеграция с Slack API
- Отправлять уведомления о:
  - Новые задачи (assigned to me)
  - Deadline за 1 час
  - @mentions в комментариях

Критерии успеха:
1. Slack notifications latency < 1 минуты
2. Slack CTR (click on notification) > 15%
3. Time to react на критичные tasks снизился до 30 минут
4. NPS от пользователей Slack integration > 8
5. Support tickets по missing tasks сняли на 20%

Цена разработки: 1 спринт ($20K)

ROI: Экономия на support $10K/месяц + produktivnost gains $30K/месяц = $480K/год

---

Пример 3: Мобильное приложение для доставки

Ситуация: Компания видит, что пользователи приложения часто ошибочно нажимают кнопку "Cancel Order" после оплаты. Это создаёт проблемы для логистики.

ПЛОХОЕ требование:

"Добавить подтверждение перед отменой заказа (confirmation dialog).
"

ХОРОШОЕ требование:

БИЗНЕС-ТРЕБОВАНИЕ:

Цель: Снизить количество отменённых заказов на 40% (с 15% до 9%)

Контекст:
- Сейчас 15% заказов отменяются пользователями после оплаты
- Из них 70% — это случайные клики (ошибки юзера)
- Каждый отменённый заказ:
  - Курьер потратил время впустую
  - Ресторан потратил ингредиенты
  - Логистика переоформляет документы
  - Потеря репутации

Количественный результат:
- Сейчас 100 заказов/день × 15% отмен = 15 отмен/день
- Целевой: 9 отмен/день
- Выигрыш: 6 дополнительных успешных доставок/день
- За месяц: 6 × 30 = 180 доставок
- При среднем заказе $50 и маржине 15% = $1,350/месяц extra revenue

Предполагаемое решение:
- Добавить confirmation screen перед отменой
- Показать: "Курьер уже выехал! Вы точно хотите отменить?"
- Двухтактовое подтверждение (first touch + second touch)

Критерии успеха:
1. Cancel rate снизился до 9%
2. User feedback: понял, что нужно подтверждение > 90%
3. Accidental cancellations < 5%
4. A/B test: группа с confirmation vs без > difference 40%

Цена разработки: 2 дня (очень дешево)

ROI: $1,350/месяц × 12 = $16,200/год, затраты < $10K = отличное вложение

---

Пример 4: SaaS аналитики

ПЛОХОЕ требование:

"Ускорить загрузку отчётов.
Оптимизировать SQL queries.
"

ХОРОШОЕ требование:

БИЗНЕС-ТРЕБОВАНИЕ:

Цель: Уменьшить churn (отток) пользователей на 5% (с 8% на 3% в месяц)

Контекст:
- Сейчас отчёты загружаются 20-30 секунд
- Наши конкуренты: 2-3 секунды
- При опросе пользователей: 60% говорят "слишком медленно"
- Это одна из топ 3 причин, почему пользователи уходят

Бизнес-эффект:
- Если снизим churn на 5%, сохраним 5 клиентов/месяц
- Средний LTV клиента: $20K
- Выигрыш: 5 × $20K × 12 месяцев = $1.2M/год

Предполагаемое решение:
- Переиндексировать БД
- Добавить кеширование (Redis)
- Оптимизировать N+1 queries

Цели скорости:
- Simple report: < 2 sec (було 20s)
- Complex report: < 5 sec (було 30s)

Критерии успеха:
1. 95-th percentile load time < 5 sec
2. Churn rate упала на 5%
3. User satisfaction (from survey) > 80% happy
4. No performance regressions in next releases

Цена разработки: 2 спринта ($40K)

ROI: $1.2M / $40K = 30x за первый год

---

Пример 5: HR система

ПЛОХОЕ требование:

"Создать отчёт по зарплатам сотрудников.
Показывать ФИО, должность, зарплату, бонус.
"

ХОРОШОЕ требование:

БИЗНЕС-ТРЕБОВАНИЕ:

Цель: Снизить время на расчёт зарплат с 8 часов на 1 час

Контекст:
- HR-специалист каждый месяц:
  - Вручную собирает данные о зарплатах (2 часа)
  - Считает налоги и отчисления (3 часа)
  - Готовит отчёты для бухгалтерии (2 часа)
  - Отправляет in spreadsheets (1 час)
- Человеческие ошибки: 3-4 ошибки в месяц → переделка (0.5 часа)
- Бухгалтер потом перевводит данные в 1С (1 час) → double work

Бизнес-эффект:
- Экономия времени: 8 часов/месяц = 96 часов/год
- 1 HR специалист освобождается для стратегической работы
- Меньше ошибок → экономия на исправлении
- 1С интеграция → бухгалтер не переводит данные

Предполагаемое решение:
- Автоматический расчёт зарплат
- Интеграция с 1С (экспорт данных)
- Email отправка отчётов
- Архив зарплат за всю историю

Критерии успеха:
1. Процесс расчёта занимает < 1 часа
2. Zero ошибок в расчётах (по сравнению с сейчас 3-4/месяц)
3. Нет необходимости в ручном переводе в 1С
4. HR satisfaction > 4.5/5
5. Бухгалтер также одобрил (0 проблем с данными)

Цена разработки: 2 спринта ($30K)

ROI: экономия 96 часов × $50/час = $4,800/год + экономия на ошибках + время бухгалтера = $15K+ экономии в год

---

Структура хорошего бизнес-требования

Шаблон, который я всегда использую:

1. ЦЕЛЬ (Goal)
   - Что мы хотим достичь?
   - Метрика (увеличить на 25%, снизить с X до Y)

2. КОНТЕКСТ (Why)
   - Почему это нужно?
   - Какая сейчас проблема?
   - Почему это важно для бизнеса?

3. ТЕКУЩЕЕ СОСТОЯНИЕ (Current State)
   - Как сейчас работает?
   - Какие цифры?
   - Кто это делает сейчас?

4. ЖЕЛАЕМОЕ СОСТОЯНИЕ (Future State)
   - Как будет после?
   - Улучшение в цифрах

5. РЕШЕНИЕ (Solution)
   - Какое решение предлагаем?
   - Это не детали, а высокоуровневое описание

6. КРИТЕРИИ УСПЕХА (Success Criteria)
   - Как мы измеримо проверим, что достигли цели?
   - Минимум 3-5 критериев
   - Должны быть: измеримые, достижимые, релевантные

7. ROI / БИЗНЕС-ЭФФЕКТ
   - Сколько денег мы выиграем?
   - Сколько потратим?
   - ROI = (Выигрыш - Затраты) / Затраты × 100%

8. РИСКИ
   - Что может пойти не так?
   - Как мы их снизим?

Когда я пишу такие требования

На встречу с CEO/Board:

• Обязательно есть ROI
• Есть цифры и метрики
• Ясен бизнес-эффект

Для разработчиков:

• Сначала бизнес-требование (зачем?)
• Потом функциональные требования (что?)
• Потом технические требования (как?)

В документацию (PRD, Wiki):

• Вся информация из шаблона
• История принятия решения
• Ссылки на метрики

Вывод

Хороший BA:

• Пишет требования языком БИЗНЕСА (не техники)
• Объясняет ЗАЧЕМ (не просто ЧТО)
• Показывает ROI и цифры
• Согласовывает с бизнесом ДО разработки

Это экономит месяцы работы, потому что разработчики вместо 10 идей берут 1 правильную, которую одобрил CEO.