Анализ данных • 20 ноября 2023 • 5 мин чтения

В переводе с клиентского: как аналитик пишет бизнес‑требования

Клиенты говорят: «Хотим, чтобы интернет-магазин увеличил прибыль». Бизнес-аналитик превращает этот запрос в документ с задачами для команды. Как это сделать — разобрали в статье.

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

Бизнес-требования простыми словами — это свойства и функции, которые должен выполнять продукт, чтобы быть ценным для пользователей и заказчика. Все эти свойства и функции описывают в документе. Вот зачем это делать:

● Дать команде разработки больше вводных о проекте. Так она вероятнее разработает то, что ожидает заказчик.
● Зафиксировать с заказчиком требования, с которыми будет работать команда.
● Рассказать всем заинтересованным, что изменится в продукте. В развитии продукта участвует не только продуктовая и техническая команда, но и маркетинг, юристы, отдел продаж и логистики. Изменения в продукте могут отразиться на их работе.

Бизнес-требования не сразу выглядят как документ с понятной структурой и формулировками. Сначала аналитик собирает информацию от заказчика и пользователей. Затем — переводит её на язык, понятный команде

Навык писать бизнес-требования приходит с опытом. Джун постепенно растит мастерство, получая обратную связь от старших коллег. На курсе «Бизнес-аналитик» студенты тренируются в похожих условиях. Только вместо других джунов — такие же студенты, а помогают осваивать профессию преподаватели и наставники. Когда-то они тоже были джунами, а теперь — опытные аналитики, которые знают, как всё устроено в реальных проектах.

Какие бывают бизнес‑требования

У разных компаний подход к созданию и ведению документации отличается. Вот несколько уровней требований, которые можно встретить в документе, — от концептуальных до детальных:

Верхнеуровневые. Согласно международным стандартам, бизнес-требования — это отдельный документ. В нём описаны цели компании, которых она хочет достичь за счёт изменений. Но многие компании включают эти требования в один документ с пользовательскими. Например, указывают, что цель бизнеса — повысить конверсию продукта на 1% за ближайшие полгода. Дальше описывают решение — за счёт чего это произойдёт.
Пользовательские. В российских компаниях большую часть документа с бизнес-требованиями занимают требования пользователей. Например, бизнес-аналитик выяснил: уведомление о том, что в корзине остался неоплаченный товар, повысило конверсию у конкурентов. Значит, эту функцию включают в бизнес-требования. Просьба заказчика добавить блок отчётности в информационную систему — тоже потребность, которую аналитик переформулирует в пользовательские требования.
Пользовательские требования — ответственность бизнес-аналитика. Он собирает их, анализирует и продумывает, какие изменения в продукте могут закрыть потребность пользователей и бизнеса.
Системные требования — это требования к решению, которые описаны техническим языком. Например, как система реагирует на действия пользователя, сколько должны храниться данные в конкретной таблице, с какой скоростью они должны выгружаться.
Обычно эти требования не включают в документ бизнес-требований, потому что за них отвечает системный аналитик. Но если в команде такого специалиста нет, то бизнес-аналитик берёт эту задачу на себя. Подключает ней технических специалистов и составляет требования вместе с ними.

Компоненты документа бизнес-требований

Эталонного шаблона бизнес-требований нет. Шаблон из книги Карла Вигерса о разработке бизнес-требований можно взять за основу на старте, но не все его разделы пригодятся бизнес-аналитику. Шаблон, с которым будет работать бизнес-аналитик, часто зависит от проекта, команды и бизнеса. Но есть «несгораемые» поля, без которых не обойдётся ни один документ:

Перечень функций, которые должен выполнять продукт, чтобы быть ценным для пользователя и заказчика. Например: у пользователя должна быть возможность оплатить товар российской или международной картой, через систему быстрых платежей или виртуальный кошелёк.
Ограничения. Например, бизнес-аналитик пообщался с заказчиками и пользователями и знает, что приложение будет работать только в определённых странах. В некоторых из них после 9 вечера алкоголь не продают, поэтому заказать его в 22:00 не получится. Если системный аналитик и разработчик не будут знать об этой детали, они могут спроектировать неверную логику. Покупатели будут заказывать алкоголь, а магазин не сможет его доставить.
Риски. Например, к приложению решили подключить несколько платёжных систем. Есть вероятность, что одна из них перестанет работать в регионе, в котором работает продукт. Бизнес-аналитик должен учесть этот риск и внести в документ. Вместе с технической и продуктовой командой они смогут придумать альтернативный способ оплаты.

Часто в документ добавляют глоссарий — небольшой словарь. Так все будут понимать, что в этом проекте значит система, покупка или другой термин. Обычно глоссарий пишут в начале документа.

Как составить документ бизнес-требований

Цикл разработки бизнес-требований обычно состоит из 7 шагов. Сначала аналитик общается с заказчиком и пользователями, затем анализирует ситуацию на проекте, разбирает информацию, которую собрал, и придумывает решение. После — составляет документацию, проверяет, согласовывает и вносит изменения. Разберём подробнее каждый шаг.

1. Выявить потребности

Сначала нужно узнать пожелания заказчика. Интервью пройдёт эффективнее, если заранее составить список вопросов и продумать сценарии, которые помогут спикеру дать более полные ответы.
Следующие на очереди — пользователи и все, кто заинтересован в развитии продукта. Кроме интервью бизнес-аналитик может использовать и другие методы: наблюдение, анкетирование, опросы. Например, чтобы разобраться, почему функция неудобная, достаточно понаблюдать, как пользователь с ней взаимодействует.

Важно помнить о цели продукта. Чаще всего заказчик хочет изменить что-то, чтобы увеличить прибыль. Пользователи, у которых бизнес-аналитик берёт интервью, тоже хотят решить свои проблемы, но они не всегда пересекаются с потребностями заказчика. Поэтому сначала пишут подробный протокол встреч, чтобы собрать все потребности и сопоставить пожелания с целью продукта.

2. Проанализировать ситуацию на проекте

Задача этого шага — понять, как изменится продукт, если воплотить в жизнь запросы заказчика и пользователей. Для этого аналитик общается с технической командой, чтобы изучить, как работает продукт. Анализирует проектную документацию инструкции, регламенты, опыт конкурентов. Так он поймёт, какие функции уже реализованы и какие технические ограничения могут повлиять на требования.
Конкурентный анализ помогает узнать, что у других компаний получилось, что не принесло результата и какие идеи ещё никто не реализовал.

3. Проанализировать потребности и предложить решение

Теперь всю информацию из предыдущих двух шагов нужно разобрать, соотнести с запросами бизнеса и предложить несколько вариантов решения задачи. Каждый из вариантов анализируют с помощью вопросов:

● Какие у него риски?
● Как будет выглядеть схема работы с этим решением?
● Как изменение повлияет на другие части продукта?

Попробуем выбрать решение для платформы онлайн-курсов, на которую нужно привлечь больше новых пользователей за месяц.

Вариант решения
Оценка
Улучшить интерфейс: навигацию по каталогу курсов, поиск

Затраты: бюджет на дизайн и разработку.

Ожидаемые результаты: более привлекательный интерфейс увеличит вовлечённость пользователей. Риски: технические ограничения и задержки в разработке. Ресурсы: дизайнеры и разработчики

Запуск маркетинговой кампании

Затраты: реклама и SEO-продвижение, адаптация сайта под поисковые запросы.

Ожидаемые результаты: привлечь новых пользователей и увеличить их число в краткосрочной перспективе.

Риски: маркетинговые стратегии не будут отвечать потребностям ЦА

Ресурсы: маркетологи, SMM, SEO-специалисты, разработчики для SEO-оптимизации сайта

Внедрение программы лояльности

Затраты: разработка механики скидок для новых пользователей.

Ожидаемые результаты: программа лояльности привлечёт новых пользователей и замотивирует сделать первый заказ.

Риски: если курсы не понравятся, то новые пользователи всё равно уйдут к конкурентам.

Ресурсы: разработчики для создания программы и маркетологи для управления ей

Оценка и выбор решения: наиболее эффективным решением будет запуск маркетинговой кампании. Она не требует критичных изменений в продукте. Риск неуспешной кампании можно уменьшить, если запустить несколько рекламных кампаний и в процессе отслеживать их результаты

Чтобы защитить решение перед заказчиком, его нужно подробно обосновать. Например, составить смету, показать, как это работает у конкурентов, показать модель процесса, которая есть сейчас (as is), и целевого процесса, который получится в конце проекта (to be). После защиты бизнес-аналитик документирует требования.

4. Составить документацию

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

5. Проверить бизнес‑требования

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

Критерий
Что значит
атомарный
Требование невозможно разделить на несколько подтребований. Так разработке не придётся искать несколько задач в одном предложении
полный
Существенные требования заказчика включены в требования к документации
краткий
Формулировки должны быть ёмкими. Если текста много ― делить его на абзацы, использовать нумерацию
выполнимый в рамках бюджета и технологий
Бизнес-аналитик должен заранее узнать об ограничениях у продакт-менеджера, менеджера проекта и разработки
однозначный
Все читатели требований воспринимают их одинаково
непротиворечивый
Разделы документа не конфликтуют друг с другом по смыслу
тестируемый
Бизнес-требование можно проверить тест-кейсом на этапе тестирования
понятный и последовательный
Не должно быть повторов по тексту документации, структуру можно понять из подзаголовков

После самопроверки можно попросить ревью у коллег. Они будут читать документ впервые и наверняка заметят что-то новое.

6. Согласовать со стейкхолдерами

После проверки документ снова нужно будет согласовать с заказчиком, пользователями и другими командами, которые работают с продуктом. Так бизнес-аналитик убедится: все поняли требования и то, как будет меняться процесс. Под каждого стейкхолдера лучше подбирать формат, который ему понятнее. Кто-то лучше понимает схемы и прототипы, другим удобнее прочитать текст.

Если аналитик работает с объёмной задачей вроде переработки интернет-магазина, визуализация обязательна. Диаграммы, модели процессов, таблицы помогут упростить восприятие сложной информации.

7. Актуализировать требования

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

Чтобы информация не потерялась, аналитик создаёт новую версию документа бизнес-требований. Так получится сохранить предыдущие вводные и на контрасте видеть, что изменилось.

Мария Логвинова, эксперт курса «Бизнес-аналитик», главный аналитик розничной сети «Магнит»

Новички в бизнес-анализе сталкиваются с большинством этих шагов, но чаще начинают с небольших задач. Одной из таких задач может быть создание проверки в продукте, который уже работает. Например, в системе электронного документооборота. Когда пользователи создают и регистрируют документы, они вносят в систему данные. Если допустить ошибки, система не сможет обработать информацию. Нужно создать проверку, которая выявит такие отклонения и выдаст пользователю сообщение об ошибке.

Система уже работает, другие аналитики составили для неё документацию. Задача джуна — написать требования для небольшой её части. Аналитик изучает, как провести эту проверку, общается с пользователями, выясняет, как лучше вывести ошибку, чтобы они её заметили и исправили. Анализирует комментарии пользователей, составляет документ с требованиями и отдаёт на ревью старшим коллегам.

5 замечательных примеров документов бизнес‑требований

Разбираем ошибки в формулировках и примеры бизнес-требований к проекту, где эти ошибки исправили.

Ошибка
Как исправить
❌ У пользователя должна быть возможность частично оплатить заказ.

Что не так: Что значит частично? А насколько частично? За счёт чего допустима частичная оплата?

✅ У пользователя должна быть возможность частично оплатить заказ купоном на скидку.

Оплата купоном не должна превышать 50% стоимости заказа. Купон должен иметь срок окончания действия > сегодня, то есть быть активным. Если купон просрочен, нужно вывести ошибку пользователю.

Что хорошо: понятны условия и ограничения для оплаты

❌ На входе в систему пользователю должна выводиться форма ввода логина и пароля, которая должна содержать 2 прямоугольника для ввода значений. Прямоугольники должны иметь ширину 5 мм и длину 10 мм, быть черного цвета, с прозрачностью 20%. Если пользователь нажимает на область вне прямоугольника, ввод не должен быть доступен. Если пользователь нажимает на область внутри прямоугольника, то ввод должен быть доступен. Логин должен допускать ввод текста, опираясь на справочник существующих логинов в системе.

Что не так: это не выглядит как бизнес-требования — много лишней информации. Аналитику не нужно писать такие детали, это не его зона ответственности

✅ У пользователя должна быть возможность войти в систему, используя свой логин и пароль.

Что хорошо: кратко, понятно, по факту

❌ Поставщик, выполняя корректировку даты начала поставки, не должен нарушать установленные границы доступности редактирования данных для избежания проблем.

Что не так: написано сложно и мало похоже на требование. Он сам должен не нарушать или ему нужно запретить корректировку? А какие это границы?

✅ У поставщика должна быть возможность откорректировать дату начала поставки товара в магазин.

Корректировка должна быть возможна не позднее чем за 10 дней до текущей даты начала поставки.

Что хорошо: понятно, что нужно отобрать возможность корректировки с нарушением тайминга, понятно, какие это тайминги

❌Система должна рассчитать сумму налога к уплате для пользователя по потребности.

Что не так: Как? Когда? Кому?

✅ У пользователя должна быть возможность запросить расчёт суммы налога к уплате на главной странице приложения. После инициации расчёта система должна вывести сумму значений из поля «Налог» таблицы «Сумма налогов» за последние 3 месяца.

Что хорошо: понятно, когда запустить расчёт, как произвести его, на основании каких данных, за какой период

❌ Если пользователь указал сумму списания >100 млн, то вывести ошибку, если < 99 млн, то произвести списание.

Что не так: а если сумма с 99 до 100, что должна сделать система?

✅ Если пользователь указал сумму списания >100 млн, вывести ошибку, если < 99 млн, списать деньги. В остальных случаях вывести уведомление о превышении лимита и списать деньги.

Что хорошо: понятно, что делать

Совет эксперта

Мария Логвинова

С первого раза идеальный документ бизнес-требований не получится. Но и тройное сальто начинающий гимнаст не осилит. Вспоминаем о силе маленьких шагов. Много полезной теории о требованиях можно найти у Вигерса. Это поможет избежать типичных ошибок в документе в начале карьеры. Дальше — только постоянная практика с обратной связью. Обычно много вопросов приходит от системных аналитиков, и это здорово. В первый раз окажется, что не хватает многих деталей, описаний, табличек, визуализации. В следующий раз новичок учтёт прошлые вопросы и с каждым разом будет писать бизнес-требования всё лучше.
Статью подготовили:
Мария Логвинова
Яндекс Практикум
Эксперт курса «Бизнес-аналитик», главный аналитик розничной сети «Магнит»
Яндекс Практикум
Редактор
Анастасия Павлова
Яндекс Практикум
Иллюстратор

Дайджест блога: ежемесячная подборка лучших статей от редакции

Поделиться
Сочините нейробалладу или смешной гороскоп: идеи необычных подарков своими руками + бонусы от партнёров
Wed Oct 02 2024 11:14:09 GMT+0300 (Moscow Standard Time)