Коммерческое предложение на разработку MVP: что писать и как считать
MVP заказывают не ради продукта, а ради ответа на вопрос: пользуются ли этим люди и готовы ли платить. Отсюда главное отличие предложения от обычного КП на разработку — в нём должна быть названа проверяемая гипотеза и то, по каким признакам заказчик поймёт, подтвердилась она или нет. Без этого разговор быстро сворачивает к списку функций, каждая из которых кажется обязательной, и первая версия разрастается до размеров, при которых проверять уже нечего: деньги и время потрачены до первой встречи с пользователем.
Второе отличие — работа ведётся от ограничения, а не от желаемого объёма. Заказчик обычно готов назвать срок и бюджет, в которые нужно уложиться, и задача команды — предложить, что в них помещается. Это значит, что часть функций осознанно не делается на первом этапе, а какие-то вещи заменяются ручными операциями со стороны заказчика. Такие решения нельзя оставлять в устной договорённости: в предложении нужен отдельный раздел о том, что в первую версию не входит и почему, иначе на приёмке возникнет ощущение недоделанного продукта.
Из каких блоков собрать предложение
Сформулируйте, что именно проверяется первой версией: что пользователи регулярно возвращаются, что они доходят до оплаты, что процесс закрывает реальную боль. Опишите, какие действия пользователей будут считаться подтверждением, и какие события для этого нужно фиксировать в продукте. Это задаёт границу объёма: всё, что не помогает получить ответ, откладывается.
Опишите один сквозной путь от входа до получения ценности и перечислите экраны, которые в него попадают. Отделите роли пользователей и укажите, какие из них реализуются в первой версии. Здесь же назовите, что заказчик первое время делает вручную вместо автоматизации: проверку заявок, рассылку, подбор, модерацию.
Перечислите функции, которые обсуждались и осознанно отложены: сложные роли и права, аналитические отчёты, мобильные приложения, интеграции с внутренними системами, тонкая настройка оформления. По каждому пункту коротко объясните причину — она почти всегда в том, что решение не влияет на проверку гипотезы.
Назовите платформу, способ размещения и готовые сервисы, которые берутся вместо собственной разработки: авторизация, приём платежей, отправка писем, хранение файлов. Укажите, где сознательно выбрана скорость в ущерб запасу прочности, и на какой нагрузке такое решение придётся пересматривать. Заказчик должен понимать это до старта, а не после роста.
Разложите работу по неделям или спринтам и покажите, что заказчик видит в конце каждого. Назовите состав команды и её занятость на проекте. Опишите правило работы с новыми идеями: они не втискиваются в текущий объём, а попадают в список следующего этапа либо заменяют собой равный по трудоёмкости пункт.
Опишите, что происходит после выкладки: сбор событий, наблюдение за поведением первых пользователей, срок наблюдения и точка принятия решения. Дайте эскиз следующего этапа в трёх вариантах — развивать, переделать под другой сценарий или остановиться. Сопровождение на период проверки вынесите отдельной строкой.
Что обычно входит в смету
- Проработка гипотезы и границ первой версиигипотеза
- Описание основного пути пользователя и схемы экрановэтап
- Интерфейс экрана с вёрсткой и состояниямиэкран
- Реализация серверной логики основного сценариясценарий
- Регистрация и вход через готовый сервис авторизацииинтеграция
- Подключение приёма оплаты и обработка статусовинтеграция
- Служебный раздел для ручных операций заказчикаэкран
- Сбор продуктовых событий для проверки гипотезыэтап
Блоки, смета с расчётом и условия уже готовы — останется вписать свои цены. Клиент открывает ссылку в браузере, а вы видите, кто её открыл и докуда дочитал.