Как подготовить бриф на разработку MVP
Бриф нужен, чтобы заказчик и команда одинаково понимали первый релиз. Для старта не обязательно описывать каждый экран. Важнее назвать пользователя, задачу, ограничения и результат, по которому вы решите, стоит ли развивать продукт.
1. Опишите один законченный сценарий
Начните с формулы: кто пользуется продуктом, какое действие выполняет и что получает в конце. «Личный кабинет» — название интерфейса, а не описание задачи. Для примера портала поставщика сценарий может звучать так: менеджер собирает заказ по персональным ценам, руководитель согласует сумму, поставщик получает подтверждённую заявку.
Рядом опишите, как эта задача решается сейчас. Если заказ проходит через таблицу, почту и звонок, перечислите эти шаги и точки потери информации. Так можно сравнить новый процесс с исходным, а не оценивать MVP по числу экранов.
- Основной пользователь и его задача
- Начало и успешное завершение сценария
- Нынешний процесс и его конкретная проблема
- Способ проверить результат после запуска
2. Разделите первый релиз и следующие этапы
Выделите функции, без которых основной сценарий не завершится. Отдельно запишите идеи для развития: дополнительные роли, отчёты, рекомендации и автоматизацию редких исключений. У каждой функции первого релиза должна быть связь с проверяемой задачей.
Например, для теста процесса заказа могут потребоваться каталог, персональная цена и согласование. Сложная программа лояльности может подождать. Это пример выбора, а не универсальный состав MVP: границы зависят от вашей гипотезы.
- Обязательные действия первого релиза
- Функции вне первого релиза
- Ограничения теста: аудитория, объём данных и период наблюдения
3. Покажите данные и интеграции
Назовите системы, из которых приходят данные и в которые уходят изменения. Для каждой интеграции полезны документация API, пример обезличенных данных, ограничения и контакт ответственного специалиста. Если доступ пока не получен, укажите это как допущение оценки.
Не передавайте пароли и рабочие токены вместе с брифом. Для исследования нужен согласованный тестовый контур и ограниченный доступ. Заранее обсудите поведение при недоступности внешней системы: пользователь ждёт, повторяет действие или получает статус обработки.
- Источники данных и ответственные за них
- Документация и доступность тестовой среды
- Правила доступа для каждой роли
- Ошибки, повторные запросы и ручные действия
4. Согласуйте проверяемую приёмку
Критерий приёмки описывает наблюдаемое поведение. Вместо «система быстро работает» задайте сценарий, объём данных, число одновременных пользователей и согласованное время ответа. Числа выбираются под ваш процесс, а не под красивую презентацию.
Для портала заказа можно записать: после согласования заявка передаётся в тестовую ERP, а повторное нажатие не создаёт второй заказ. Проверяйте также отказ и восстановление. Хороший интерфейс ещё не доказывает, что данные дошли до следующей системы.
- Проверка основного сценария от начала до конца
- Проверка прав и запрещённых действий
- Поведение при ошибках интеграций
- Условия запуска и ответственный за приёмку
5. Сравнивайте оценки на одинаковом объёме
Передайте всем рассматриваемым командам одинаковый бриф. Попросите отдельно указать этапы, допущения, зависимости, результаты и то, что не включено. Суммы без одинакового объёма сравнивать сложно: одна оценка может включать backend и выпуск, а другая — только интерфейс.
Обсудите, где будут храниться код и документация, кто отвечает за инфраструктуру и что происходит после запуска. Если неизвестных много, первым этапом может стать исследование с конкретным результатом: карта сценариев, прототип, модель данных и уточнённая оценка.
- Бюджетный ориентир и необходимые сроки
- Результаты и критерии завершения каждого этапа
- Допущения оценки и зависимость от доступов
- Передача кода, документации и порядок поддержки
Разобрать вашу задачу
Подготовим вопросы к первому этапу, обсудим ограничения и предложим критерии проверки результата.
Обсудить проект