Короткий ответ: бюджет цифрового продукта считают не по числу экранов, а по объёму сценариев, ролям, данным, интеграциям, требованиям к качеству и поддержке. Хорошая оценка показывает диапазон, допущения и риски, а не выдаёт одну точную цифру без объяснения. Для первой версии обычно полезно отдельно посчитать обязательный контур и список отложенных функций.
Если подрядчик называет цену до обсуждения пользователей, сценариев и интеграций, это не обязательно обман — скорее, очень грубая гипотеза. Её нельзя сравнивать с детальной оценкой другой команды, пока обе стороны не привели предложения к одной структуре.
Из чего складывается бюджет
| Блок | Что входит | Почему влияет на цену |
|---|---|---|
| Discovery | Сценарии, роли, ограничения, архитектурные решения | Снижает неопределённость и выявляет сложные места |
| UX/UI | Прототип, состояния, адаптив, дизайн-система | Количество состояний важнее числа красивых экранов |
| Разработка | Frontend, backend, админка, база, инфраструктура | Зависит от логики, ролей и требований к эксплуатации |
| Интеграции | Платежи, CRM, API, уведомления, импорт | Внешние системы добавляют зависимости и сценарии ошибок |
| QA и запуск | Тесты, исправления, релиз, мониторинг | Без этого оценка описывает код, но не готовый продукт |
Для сравнения предложений используйте одинаковую структуру: что входит в работу, что считается отдельной задачей, какие данные предоставляет заказчик и кто отвечает за внешние сервисы. Ссылку на веб-разработку лучше давать рядом с конкретным составом результата, а не вместо него.
Практический шаг: попросите три числа: базовый объём, вероятный диапазон и резерв на неизвестные. Затем спросите, какие факторы переведут проект из одного диапазона в другой.
Как оценивать MVP без самообмана
MVP — это не самая дешёвая версия всех функций. Это минимальный законченный путь, на котором можно проверить ценность продукта. В расчёт должны попасть авторизация, роли, данные, ошибки, аналитика или ручной контроль, если без них нельзя понять результат.
- сформулируйте один бизнес-результат первой версии;
- разделите обязательные сценарии и backlog «после проверки спроса»;
- зафиксируйте интеграции, без которых сценарий не работает;
- не прячьте админку, поддержку и миграцию данных за словом «техническое»;
- опишите критерий, по которому MVP можно принять.
Диапазон лучше одной цифры
Оценка — это модель принятия решения, а не обещание будущего с точностью до рубля. Команда может использовать часы, story points или аналогичные методы, но должна показать, на каких сравнениях и допущениях построен расчёт. По мере discovery диапазон сужается, а изменения фиксируются вместе с причиной.
| Уровень оценки | Когда уместен | Что сообщать заказчику |
|---|---|---|
| Грубая гипотеза | Есть идея и ограниченный контекст | Порядок бюджета и главные неизвестные |
| Предварительная | Описаны сценарии и состав MVP | Диапазон, допущения, риски, зависимости |
| Рабочая | Есть прототип и технический план | Разбивка по этапам, критерии, резерв, исключения |
Какие риски часто забывают
- неполные или грязные исходные данные;
- ограничения внешнего API и изменение его условий;
- несколько ролей с разными правами;
- миграция и импорт исторических данных;
- тестирование на реальных сценариях и устройствах;
- поддержка, мониторинг, резервирование и исправления после запуска;
Для технических и security-рисков полезно назначать отдельную проверку, а не прятать их в общий процент. NIST SSDF описывает безопасную разработку как набор практик, которые встраиваются в жизненный цикл; для бизнеса это означает, что контроль доступа, зависимости и обработка ошибок должны появляться в плане заранее.
Как сравнить два коммерческих предложения
- Сведите оба предложения к одинаковым этапам и результатам.
- Проверьте, одинаково ли трактуются MVP, интеграция и готовность к запуску.
- Отдельно выпишите часы discovery, QA, релиза и поддержки.
- Спросите, что произойдёт при изменении сценария или внешнего API.
- Сравните не только цену, но и объём ответственности, прозрачность оценки и путь к рабочему результату.
Как Paladin Engineering может помочь
Paladin Engineering может подключиться к оценке идеи, discovery, проектированию и разработке цифрового продукта. На практике первый полезный результат — не «точная цена навсегда», а понятная карта MVP: сценарии, этапы, зависимости, диапазон бюджета и вопросы, которые нужно проверить до старта. Для обсуждения задачи используйте контакты Paladin Engineering.
Что должно остаться в рабочем комплекте
К завершению этапа заказчику нужен не только демонстрационный экран. В рабочем комплекте должны быть зафиксированы сценарии, решения по спорным местам, список известных ограничений, тестовые данные, критерии приёмки и инструкция для следующего участника проекта. Такой набор сокращает зависимость от устных договорённостей и помогает продолжить работу после паузы или смены исполнителя.
Если проект передаётся между командами, отдельно проверьте доступы, структуру репозитория, настройки окружений, миграции и порядок отката. Не включайте в документацию секреты: используйте безопасную передачу и хранение конфигурации, а в отчётах оставляйте только факт наличия настройки и её назначение.
CTA: если нужно понять, на каком этапе находится ваш проект и чего не хватает до запуска, начните с короткого аудита одного сквозного сценария.
CTA: для предварительной оценки бюджета подготовьте список пользователей, обязательных действий, внешних систем и ограничений по запуску; обсудите эти допущения с командой до старта.
Можно ли рассчитать бюджет без ТЗ?
Можно получить предварительный диапазон, если описать пользователей, сценарии, интеграции и ограничения. Точная рабочая оценка потребует уточнения контекста.
Что дороже всего в цифровом продукте?
Не существует универсального ответа: стоимость часто растёт из-за сложной бизнес-логики, ролей, интеграций, данных и требований к эксплуатации.
Нужно ли закладывать резерв?
Да, если в проекте есть неизвестные. Резерв должен быть объяснён рисками, а не взят случайным процентом.
Как сравнить предложения разных команд?
Привести их к одинаковому составу результата, этапам, критериям готовности и исключениям.
Когда бюджет нужно пересматривать?
После discovery, прототипа, изменения сценариев, появления новой интеграции или выявления ограничений данных.
Комментарии