Формирование бизнес-требований для IT-продукта

Почему бизнес-требования – это сердце любого IT-продукта

Что бизнес хочет получить и зачем?

• в переработки;
• бесконечные споры;
• лишний функционал;
• а иногда – в провал.

• стратегию компании;
• реальные потребности пользователей;
• возможности команды;
• и будущий функционал.

Что такое бизнес-требования – простое определение

• Зачем создаём продукт?
• Какие бизнес-цели хотим достичь?
• Какие проблемы компании решаем?
• Какие ограничения существуют?
• Что считается успехом?

Уровни требований: чтобы не путали

1) Бизнес-требования

Пример: «Увеличить конверсию оформления заказа на 20%».

2) Пользовательские требования (User Requirements)

Пример: «Пользователь должен иметь возможность оформить заказ за 3 шага».

3) Функциональные требования (Functional Requirements)

Пример: «Система должна позволять выбирать оплату в один клик».

Из чего состоят бизнес-требования: структура

1. Контекст и проблема.
2. Бизнес-цель (Business Goal).
3. Обоснование (Rationale).
4. Метрики успеха (Success Criteria).
5. Ограничения (Constraints).
6. Заинтересованные стороны (Stakeholders).
7. Границы проекта (Scope).

Шаг 1. Формулировка проблемы бизнеса

• Низкая конверсия в покупку из-за сложной формы.
• Высокая нагрузка на колл-центр – 60% вопросов однотипные.
• У пользователей нет возможности оплатить услугу онлайн.
• Процесс обработки заявок занимает 3 дня вместо 1 часа.

• «Хотим сделать мобильное приложение».
• «Надо добавить чат-бота».
• «Хотим внедрить AI».

Шаг 2. Формулировка бизнес-цели

• S – конкретно;
• M – измеримо;
• A – достижимо;
• R – релевантно;
• T – ограничено во времени.

Примеры:
Уменьшить количество отказов при оплате с 14% до 7% за 6 месяцев.
Сократить время обработки заявки с 48 часов до 3 часов.
Снизить нагрузку на поддержку на 40% за счёт автоматизации FAQ.

Шаг 3. Обоснование (Rationale)

Примеры:
Высокие отказы в оплате приводят к потере 3 млн сом в месяц.
Долгое время обработки заявок снижает NPS и вызывает отток клиентов.
Служба поддержки не справляется, пользователи ждут по 10 минут.

Шаг 4. Успешные метрики (Success Criteria)

Примеры:
Конверсия увеличилась на 15%.
NPS вырос минимум до 45.
Среднее время обработки заявки ≤ 3 часов.
Доля автоматизированных запросов ≥ 60%.

Шаг 5. Ограничения (Constraints)

• бюджет;
• cроки;
• ресурсы;
• юридические требования;
• интеграции;
• доступные технологии.

Пример:
Система должна поддерживать 1С без изменения его API.
Время ответа сервиса ≤ 2 секунд.
Реализация – максимум 3 разработчика и 2 месяца.

Шаг 6. Stakeholders – кто влияет на требования

• пользователи;
• руководство;
• маркетинг;
• продажи;
• поддержка;
• финансы;
• IT-команда;
• юристы;
• партнёры.

• выявить;
• приоритезировать;
• согласовать.

Шаг 7. Scope – границы проекта

• что входит в проект;
• что не входит;
• какие бизнес-результаты будут достигнуты;
• на каком этапе.

• создание нового процесса оформления заказа;
• оптимизация UX;
• добавление оплаты в 1 клик.

• • редизайн главной страницы;
• • личный кабинет.

Шаблон бизнес-требования (готов к использованию)

1.  Название требования: ...
2. Описание бизнес-проблемы: ...
3. Бизнес-цель: ...
4. Обоснование: ...
5. Метрики успеха: ...
6. Ограничения: ...
7. Stakeholders: ...
8. Scope (границы проекта):  ...
9. Риски: ...
10. Допущения: ...

Пример оформленного бизнес-требования

Название:

Проблема:

Бизнес-цель:

Обоснование:

Метрики успеха:

• Конверсия ≥ 70%.
• Время оформления ≤ 1 мин.
• Количество шагов ≤ 3.

Ограничения:

• В проекте участвуют 2 фронт-разработчика.
• Поддержка только текущей CMS.
• Интеграция с банком неизменна.

Stakeholders:

Scope:

Частые ошибки новичков

❌ 1. Путают бизнес-требования с функциональными

❌ 2. Пишут «хотим приложение»

❌ 3. Формулируют абстрактно

❌ 4. Нет метрик успеха

❌ 5. Нет связи с бизнес-стратегией

Заключение

• проблемой и решением;
• стратегией и продуктом;
• бизнесом и IT;
• ожиданиями и результатами.