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