Бизнес-требования: как описать, разбить на MVP и принять работу

Проект без требований: болото на год

Владислав Липатьев, руководитель e-commerce в hollyshop, рассказывал, как предыдущий подрядчик около года делал часть их мобильного приложения. На старте все были вдохновлены и обещали «здорово, быстро, красиво». Никто не разобрался, что эти слова значат. Было верхнеуровневое ТЗ, и по нему Влад не понимал, как принимать проект. Итог — болото, из которого часть продукта пришлось забрать.

Поэтому, когда hollyshop выбирал нового подрядчика, список требований бизнеса появился ещё на этапе продажи, до договора. Мы в Alto с этим списком работаем до сих пор.

Уровни требований: от «зачем» до «как»

В бизнес-анализе требования обычно делят на уровни. Требования бизнеса отвечают на вопрос «зачем»: какую цель компания хочет достичь и как измерить успех. Требования пользователей описывают, что человек должен суметь сделать. Функциональные требования — как система себя ведёт. Нефункциональные — скорость, безопасность, доступность.

Почему ТЗ не заменяет BRD

Техническое задание описывает, что сделать. BRD описывает, зачем и как понять, что получилось. Когда есть только ТЗ, спор при приёмке неизбежен: подрядчик сделал по тексту, заказчик ждал другого, и оба правы. Когда есть цель и критерии, спор сводится к простому вопросу — выполнено требование или нет.

Я вижу по клиентам, что отношение к этой работе меняется. Раньше в бюджете MVP на 7–8 млн рублей на аналитику закладывали полмиллиона; сейчас бывают проекты, где на аналитику уходит 5 млн, а на разработку 2 млн. Сначала подумать, что делать, потом делать — это дешевле, чем переделывать.

Пример бизнес-требований из hollyshop

Цель hollyshop звучит так: приложение — инструмент удержания и персонализации, туда нужно перевести 50% заказов из веба и растить LTV. Это требование бизнеса в чистом виде. Из него следует, что пуши, диплинки и программа лояльности в приложении не украшения, а критичная часть MVP.

Аналитик превращает «что» в «как»

На вопрос из зала Влад ответил метафорой. Требование бизнеса — «багажник должен открываться». Открыть его можно кувалдой, ключом или по сетчатке глаза. Выбор способа — работа аналитика: он расписывает, как именно это должно работать, а команда переносит описание в свои задачи. Заказчику важно чётко зафиксировать требования к MVP и согласовать результат аналитики.

BRD: что это и из чего состоит

BRD, business requirements document, — документ, где требования бизнеса собраны в одном месте. Жёсткого стандарта нет, но в хорошем BRD обычно есть такие части.

• Цель проекта и метрики успеха: что изменится в бизнесе и как это измерить.
• Границы: что входит в проект, что не входит, что откладывается.
• Участники: кто принимает решения и кто принимает работу.
• Требования по блокам продукта. У hollyshop это авторизация, клиенты, платежи, лояльность и другие части витрины.
• Ограничения: сроки, бюджет, внутренние процессы и согласования.
• Критерии приёмки по каждому блоку.

Не забудьте про ограничения клиента

Влад отдельно говорил о внутренних процессах. Если инфраструктура зависит от глобального офиса, который ставит задачу в очередь, поле на странице оформления заказа можно ждать месяц. Это ограничение должно быть в документе. У нас был проект на Битриксе для крупной компании: программирование мы оценили в 3 млн рублей и попали, но менеджмента и согласований вышло ещё на 6 млн.

MVP и всё остальное

Список требований hollyshop мы разделили на две части: MVP и то, что после MVP. Это главный инструмент управления объёмом. Проект шёл по фиксированной цене, и без такого деления любое новое пожелание било бы либо по бюджету, либо по сроку.

Перед стартом мы провели аналитику: искали рискованные места, тем более что проект достался нам от другого агентства. После аналитики фикс немного изменился, зато дальше в него попадали. План — диаграмма Ганта на 50–100 строк. Если что-то не влезало, вместе с клиентом решали, что срезать, а что перенести в пост-MVP.

Мелочи, без которых не выйти в сторы

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

Приёмка по требованиям небольшими частями

Весь объём делится на блоки, и каждый блок принимается по своим требованиям. Клиент платит за работающую часть продукта. Пример — каталог: API, интерфейс, фильтры. Его принимают целиком, даже если авторизации ещё нет, потому что каталог уже работает.

Влад как заказчик говорит, что так принимать работу очень комфортно. Нам как исполнителю это было удобно не всегда: приходится доводить блок до конца, а не держать десять полуготовых задач. Но заказчику важно видеть сделанное, и мы договорились. Результат: за шесть месяцев продукт готов примерно на 90%, приложение прошло премодерацию в App Store и выходит к высокому сезону в ноябре.

Что проверить в своём документе

• Можно ли по каждому требованию ответить «сделано» или «не сделано»? Если нет, переписать.
• Видна ли цель бизнеса, а не только список экранов?
• Разделён ли объём на MVP и всё остальное?
• Записаны ли ограничения клиента: согласования, безопасность, внешние системы?
• Понятно ли, кто со стороны заказчика принимает каждый блок?