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

Самый важный вопрос – “Зачем?”

Представьте ситуацию. К вам приходит заказчик и говорит: “Нам нужно мобильное приложение. У всех конкурентов есть, и нам надо”. Что вы будете делать?

В первую очередь, нужно остановиться и задать самый главный вопрос: “ЗАЧЕМ?”.

Зачем вам приложение? Какую бизнес-проблему вы хотите решить? Какую цель достичь? Без ответа на этот вопрос вы можете потратить миллионы и полгода жизни на создание приложения, которое никому не нужно и ничего компании не даст.

Бизнес-требования – это ответ на вопрос “ЗАЧЕМ мы это делаем?”.

Что такое бизнес-требования

Бизнес-требования – это самый верхний уровень требований. Они описывают:

• Цели компании (чего хотим достичь)
• Проблемы (что хотим решить)
• Возможности (что хотим получить)
• Критерии успеха (как поймем, что получилось)

Важно понимать: в бизнес-требованиях нет ни слова про кнопки, экраны, базы данных или технологии. Это чистый бизнес-язык. Язык денег, показателей, стратегии.

Бизнес-требования – это ответ для топ-менеджмента. Когда директор спрашивает “А зачем мы вообще этот проект запустили?”, бизнес-требования - это тот документ, который вы ему покажете, если будете выполнять роль БА/Фулл-стек аналитика.

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

Обычно бизнес-требования фиксируются в документе, который называют Vision (видение) или Business Requirements Document (BRD). Давайте разберем основные блоки.

Цели и задачи проекта (Business Goals)

Это самое главное. Что компания хочет получить в результате?

Плохой пример: “Сделать крутой сайт”. (Непонятно, что такое “крутой”, и как это измерить)

Хорошие примеры:

• “Увеличить долю рынка компании в сегменте онлайн-продаж на 5% в течение года”.
• “Снизить операционные расходы колл-центра на 30% за счет автоматизации типовых запросов”.
• “Повысить лояльность существующих клиентов, увеличив повторные покупки на 15%”.
• “Выйти на рынок онлайн-образования и привлечь 10 000 платящих пользователей к концу 2026 года”.
• “Сократить время обработки входящего заказа с 2 часов до 30 минут”.

Обратите внимание: в хороших примерах всегда есть цифры. Цифры позволяют потом измерить, достигли мы цели или нет.

Текущая ситуация и проблемы (Current State & Pain Points)

Здесь описывается, что сейчас не так. С какими проблемами сталкивается бизнес сегодня.

Примеры:

• “В настоящее время 40% звонков в колл-центр – это типовые вопросы, на которые операторы тратят время. В часы пик до 20% звонков теряются из-за нехватки операторов”.
• “Конкуренты уже имеют мобильные приложения с программами лояльности, мы теряем молодую аудиторию”.
• “Обработка заявки на кредит занимает 3 дня из-за того, что данные собираются из разных систем вручную. Клиенты уходят к конкурентам, где это происходит за час”.
• “Отчетность для руководства формируется в Excel вручную, на это уходит 2 дня в конце каждого месяца”.

Решение и возможности (Proposed Solution & Opportunities)

Как видится решение проблемы. Что нам даст реализация проекта.

Примеры:

• “Внедрение чат-бота позволит автоматически отвечать на 30% типовых вопросов и разгрузить операторов”.
• “Мобильное приложение с программой лояльности привлечет молодежь и увеличит частоту покупок”.
• “Автоматизация сбора данных из разных систем позволит выдавать решение по кредиту за 1 час”.
• “Внедрение системы отчетности сократит время подготовки отчетов до 15 минут”.

Границы проекта (Project Scope)

Это очень важный раздел. Здесь обозначается, ЧТО МЫ ДЕЛАЕМ, а ЧТО МЫ НЕ ДЕЛАЕМ.

Зачем это нужно? Чтобы потом не случилось истории: “А почему вы не сделали еще и интеграцию с бухгалтерией? Мы же хотели!” А вы не хотели, это было за границами.

Пример границ проекта:

• Входит в проект: “Разработка мобильного приложения для iOS и Android, интеграция с существующей CRM, возможность просмотра каталога и оформления заказа”.
• НЕ входит в проект: “Разработка новой CRM (используем существующую), интеграция с бухгалтерской системой (будет отдельным проектом), доставка и логистика (реализовано в другой системе)”.

Критерии успеха и метрики (Success Criteria & KPIs)

Как мы поймем, что проект удался? По каким показателям?

Примеры:

• “Количество обращений в поддержку снизилось на 20%”.
• “Средний чек вырос на 10%”.
• “Время оформления заказа сократилось до 3 минут”.
• “Количество активных пользователей в день достигло 5000”.
• “ROI (возврат инвестиций) составил не менее 15% за первый год”.

Откуда брать бизнес-требования

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

Заказчик и спонсор проекта

Это люди, которые дают деньги. Они лучше всех знают, зачем это нужно.

Топ-менеджмент

Директора, владельцы продуктов (РО) – они видят стратегию компании целиком.

Стратегия компании

Если в компании есть стратегия развития, бизнес-требования должны из нее вытекать.

Аналитика и исследования

Данные о рынке, поведении клиентов, конкурентах. Иногда бизнес-проблему выявляет не заказчик, а аналитик (аналитик данных), который посмотрел на цифры и сказал: “У нас тут падение конверсии, надо что-то делать”.

Пример: От бизнес-требований к деталям

Давайте проследим, как бизнес-требования превращаются в остальные виды требований.

Бизнес-требование (уровень компании)

“Снизить операционные расходы колл-центра на 30% за счет автоматизации ответов на типовые вопросы клиентов”.

Пользовательское требование (уровень пользователя)

“Как клиент, я хочу быстро узнать статус своего заказа, не звоня оператору”. “Как оператор, я хочу, чтобы меня не отвлекали на вопросы, на которые может ответить робот”.

Функциональное требование (уровень системы)

“При вводе номера заказа на сайте система должна показывать его текущий статус”. “Чат-бот должен распознавать вопросы о статусе заказа и давать ответ из базы данных”.

Нефункциональное требование (уровень качества)

“Чат-бот должен отвечать не дольше чем за 2 секунды”. “Система должна обрабатывать одновременно 100 запросов к чат-боту”.

Видите цепочку? Всё началось с бизнес-цели “снизить расходы”, а закончилось конкретными техническими требованиями.

Типичные ошибки

Ошибка 1: Путать бизнес-требования с функциональными

“На главном экране должна быть кнопка входа”. Это не бизнес-требование, это уже деталь реализации. Бизнес-требование - это “повысить удобство для пользователей”.

Ошибка 2: Не указывать цифры

“Повысить продажи” - плохо. “Повысить продажи на 10% за полгода” - хорошо. Без цифр вы не сможете проверить, достигнута ли цель.

Ошибка 3: Не фиксировать границы

Не написано, что НЕ входит в проект – получили бесконечные споры с заказчиком и разрастание проекта (scope creep).

Ошибка 4: Забывать про критерии успеха

Сделали проект, потратили деньги, а как понять – успех или нет? Критерии успеха нужно определять до старта, а не после.

Резюме для системного аналитика

1. Бизнес-требования отвечают на вопрос “ЗАЧЕМ?”. Это самый важный вопрос. Если вы не знаете, зачем делается проект, остановитесь и выясните.

2. Говорите на языке бизнеса. В бизнес-требованиях нет места техническим деталям. Только цели, проблемы, цифры, показатели.

3. Цифры - ваши друзья. Любая цель должна быть измерима. Если нельзя измерить, нельзя понять, достигли мы ее или нет.

4. Границы проекта спасают жизнь. Четко фиксируйте, что мы делаем, а что не делаем. Это убережет от бесконечных “а давайте еще добавим”.

5. Бизнес-требования - это фундамент. Если фундамент кривой, весь дом (проект) будет кривым. Уделите этому этапу достаточно времени.