Цена программы складывается не из желания подрядчика и не из красивой презентации. Её собирают из функций, ролей пользователей, интеграций, часов специалистов, тестирования, запуска и запаса на переделки. Если разложить проект на эти части, смета перестаёт быть гаданием.
Из чего складывается стоимость разработки
Смета на создание программного продукта держится на четырёх вещах: объём задач, сложность архитектуры, состав команды и уровень неопределённости. Чем меньше тумана в требованиях, тем ближе расчёт к реальным расходам.
В практике чаще всего ломается не математика, а описание будущей системы. Заказчик говорит: «Нужен личный кабинет». Подрядчик слышит одно, владелец продукта — другое, бухгалтерия — третье. Личный кабинет может быть страницей с профилем, а может включать роли, документы, платежи, уведомления, историю действий и права доступа. Разница в цене тут не косметическая, а кратная.
На стоимость влияет и тип продукта. Внутренний сервис для отдела продаж дешевле сложной платформы с платежами, картами, аналитикой и высокой нагрузкой. Отдельно считают дизайн интерфейса, серверную часть, мобильные приложения, админ-панель, интеграции с банками, складом, телефонией или системой управления взаимоотношениями с клиентами (CRM). Одно короткое слово «интеграция» иногда прячет неделю работы, а иногда месяц.
| Блок работ | Что туда входит | Как влияет на цену |
|---|---|---|
| Аналитика | Сценарии, роли, ограничения, прототипы | Снижает риск переделок |
| Дизайн | Экраны, состояния, адаптация под устройства | Растёт вместе с числом экранов |
| Разработка | Код, база данных, серверная логика | Основная доля сметы |
| Тестирование | Проверка сценариев, ошибок, нагрузок | Экономит деньги после запуска |
| Запуск | Настройка серверов, перенос данных, публикация | Зависит от инфраструктуры |
Как посчитать смету до договора
Расчёт начинается с карты функций: что пользователь делает в системе, какие данные вводит, что получает на выходе и какие ограничения мешают ошибкам. Потом каждую функцию оценивают в часах и умножают на ставку специалистов.
А ведь именно на этом месте многие пытаются перескочить через скучную часть. Хочется сразу узнать сумму. Но сумма без списка функций похожа на ценник за ремонт квартиры без плана комнат: звучит бодро, пока не появляется электрика, плитка, двери и кривой угол у окна. В цифровом продукте таким «кривым углом» часто становятся права доступа, отчёты, импорт старых данных и странные исключения из бизнес-процесса.
Рабочая схема оценки выглядит приземлённо:
- Описать пользователей: клиент, менеджер, администратор, партнёр.
- Записать действия каждой роли без технического жаргона.
- Разделить функции на обязательные и отложенные.
- Отметить внешние сервисы, с которыми нужен обмен данными.
- Оценить часы аналитика, дизайнера, разработчиков, тестировщика и менеджера.
- Добавить резерв на изменения требований и неизвестные ограничения.
Для первой версии продукта часто хватает оценки по диапазонам. Не «проект будет стоить 3 182 400 рублей», а «от 2,8 до 3,5 млн при таком составе функций». Диапазон честнее, потому что до детальной аналитики часть решений ещё не видна. После прототипов и описания сценариев разброс сужается, и разговор о деньгах становится предметным.
Какие ошибки раздувают расходы
Бюджет растёт из-за расплывчатых требований, поздних изменений, недооценённых интеграций и слабого тестирования. Самая дорогая ошибка — начинать кодить до того, как команда поняла границы продукта.
Пример из жизни до боли знакомый: в середине проекта всплывает требование «а ещё нужен обмен с бухгалтерией». Звучит как маленькая добавка. Потом выясняется, что данные хранятся в разных форматах, часть полей заполнена вручную, статусы документов не совпадают, а ответственный сотрудник уходит в отпуск. Несколько слов в переписке превращаются в отдельный пласт работ.
Есть и другая ловушка — желание включить в первую версию всё, что когда-либо пригодится. В итоге продукт пухнет, сроки едут, пользователи ждут месяцами, а часть функций после запуска никто не открывает. Для бюджета полезнее собрать минимальный рабочий контур: регистрация, основные операции, оплата или заявка, администрирование, отчётность без излишеств. Всё спорное уходит в следующую очередь.
| Ошибка | Что происходит | Как снизить потери |
|---|---|---|
| Нет единого списка функций | Команда спорит о составе работ | Зафиксировать сценарии и роли |
| Интеграции описаны одной строкой | Сроки растут после доступа к данным | Проверить форматы, права и ограничения |
| Тестирование урезано | Ошибки находят пользователи | Закладывать проверку в каждый этап |
| Нет резерва | Любое изменение бьёт по срокам | Держать запас 10–20 процентов |
Что запросить у подрядчика перед стартом
До подписания договора у подрядчика нужно получить состав работ, оценку по ролям, календарный план, допущения, перечень рисков и порядок согласования изменений. Без этих документов цена выглядит красивой, но плохо защищает проект.
Хорошая смета читается не как загадка для технического директора. В ней видно, сколько часов уходит на аналитику, дизайн, разработку, проверку и запуск. Видно, какие функции попали в первую очередь, а какие вынесены за рамки. Между прочим, фраза «админ-панель входит» ничего не объясняет: админ-панель для просмотра заявок и админ-панель с ролями, журналом действий, фильтрами и выгрузками — разные объёмы.
Перед стартом запросите у команды несколько вещей:
- описание границ первой версии продукта;
- перечень экранов и пользовательских сценариев;
- разбивку сметы по специалистам и этапам;
- список внешних сервисов и условий доступа к ним;
- правила приёмки результата;
- порядок оценки новых требований после начала работ.
Отдельный разговор — форма оплаты. Фиксированная цена удобна, когда требования уже разобраны до деталей. Почасовая модель подходит проектам с исследованием, гипотезами и частыми изменениями. Смешанный вариант тоже работает: фиксируют понятный первый этап, а спорные блоки считают после прототипа или технического обследования.
Итог
Реальная смета рождается не из средней цены по рынку, а из описанного продукта. Чем яснее роли, сценарии, данные и ограничения, тем меньше сюрпризов в середине разработки. Деньги уходят не только на код: аналитика, дизайн, тестирование, запуск и управление изменениями съедают заметную часть бюджета.
Перед стартом проекта полезно требовать не одну итоговую сумму, а расшифровку. Какие функции входят, кто их делает, сколько времени заложено, где спрятан риск, что случится при изменении требований. Такой разговор быстро отделяет рабочую оценку от красивой цифры в коммерческом предложении.