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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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