Смета на заказную разработку: 5 скрытых статей расходов, которые подрядчики прячут на пресейле

На старте проекта подрядчик обещает корпоративный сайт или сервис за 1,5 миллиона рублей, а к релизу смета вырастает до трех. Разбираем 5 скрытых статей расходов, реальную стоимость владения (TCO) и как зафиксировать цену до подписания договора.

Коммерческое предложение в IT-разработке — это инструмент продаж, а не окончательный финансовый документ. На этапе пресейла главная задача подрядчика заключается в выигранном тендере. Чтобы не отпугнуть заказчика высокой итоговой цифрой, студии используют тактику занижения оценки (underestimation) и умалчивания о сопутствующих затратах.

Типовой сценарий выглядит следующим образом: заказчик передает подрядчику техническое задание или Верхнеуровневые требования (BRD). Студия оценивает исключительно «видимый» объем работ — верстку страниц, базовую логику и стандартный UI. При этом инфраструктура, тестирование под нагрузкой, юридическая чистота кода и интеграционные риски выносятся за рамки коммерческого предложения.

В результате бизнес получает смету, привлекательную на бумаге, но нереализуемую на практике. Как только договор подписан и внесен аванс, подрядчик начинает выставлять дополнительные соглашения (Change Requests) на работы, без которых система просто не запустится в промышленную эксплуатацию. В итоге реальный бюджет превышает плановый в 1,5–2,5 раза, а сроки сдвигаются на неопределенный срок.

Подрядчики часто молчат о том, что проектируемая архитектура опирается на сторонние платные компоненты. В смету закладывают стоимость их внедрения, но забывают упомянуть регулярные платежи.

Параметр — Скрытая проблема: Использование проприетарных CMS, готовых плагинов, CMS-модулей, конструкторов форм или платформ авторизации.
Параметр — Финансовый риск: Ежегодная или ежемесячная подписка, привязанная к курс валют или объему пользователей.
Параметр — Решение: Требование полного реестра лицензий (Software Bill of Materials) до заключения сделки.

В пресейл-смете интеграция с 1С или CRM оценивается как «подключение стандартного API» на 20–30 часов работы. В реальности стандартных интеграций в корпоративном сегменте не существует.

Параметр — Скрытая проблема: Несоответствие структур данных, отсутствие документации к API на стороне заказчика, необходимость доработки самой 1С или CRM.
Параметр — Финансовый риск: Оплата часов разработчиков 1С, привлечение сторонних консультантов, оплата шлюзов платежных систем.
Параметр — Решение: Закрепление в договоре разграничения зон ответственности за подготовку API.

Студия оценивает написание кода, но забывает о среде, в которой этот код будет жить. Заказчик рассчитывает получить готовый продукт, а получает папку с исходным кодом на Git-сервере.

Параметр — Скрытая проблема: Настройка тестовых и боевых контуров (Dev/Stage/Prod), CI/CD пайплайнов, SSL-сертификатов, защита от DDoS-атак.
Параметр — Финансовый риск: Дополнительные 100–300 тысяч рублей за работу DevOps-инженера и ежемесячные чеки от облачных провайдеров.
Параметр — Решение: Включение настройки инфраструктуры и первичного деплоя в базовый состав работ.

Факт оплаты сметы на разработку не означает автоматически, что компания стала полноправным владельцем созданного ПО.

Параметр — Скрытая проблема: Согласно ст. 1296 ГК РФ, если договором не предусмотрено иное, исключительные права принадлежат подрядчику, а заказчик получает лишь право использования.
Параметр — Финансовый риск: Требование отдельной платы за «отчуждение прав» при расторжении отношений или попытке передать проект другой команде.
Параметр — Решение: Явное указание в договоре на отчуждение исключительных прав в полном объеме с момента подписания акта приемки-передачи.

После релиза любой софт требует обслуживания. Подрядчики либо не включают гарантию в смету, либо прописывают условия, при которых гарантия аннулируется от любого вмешательства.

Параметр — Скрытая проблема: Исправление багов после сдачи проекта выносится в отдельный T&M-контракт с высокой почасовой ставкой.
Параметр — Финансовый риск: Плата за устранение собственных ошибок разработчиков под видом «технической поддержки».
Параметр — Решение: Фиксация гарантийного периода (минимум 3–6 месяцев) с четким SLA по времени реакции и устранения дефектов.

Для объективной оценки бюджета необходимо считать не стоимость разработки (CAPEX), а совокупную стоимость владения (Total Cost of Ownership, TCO) на горизонте 3 лет.

Формула расчета TCO:
TCO = Затраты на разработку (CAPEX) + Инфраструктура и лицензии (36 мес.) + Техническая поддержка и развитие (OPEX) + Косвенные расходы (обучение, администрирование)

Параметр — Затраты на разработку (CAPEX): Первоначальная смета, проектирование, дизайн, верстка, бэкенд, фронтенд, базовое тестирование.
Параметр — Лицензии и ПО (36 мес.): Подписки на SaaS-сервисы, плагины, лицензии CMS, антибот-системы, SMS-шлюзы.
Параметр — Инфраструктура (36 мес.): Аренда dedicated-серверов, облачных ресурсов (Yandex Cloud, Selectel), S3-хранилищ, CDN.
Параметр — Поддержка и развитие (OPEX): Гарантийный SLA, плановое обновление стека технологий, доработка функционала под меняющиеся бизнес-требования.
Параметр — Администрирование и кадры: Затраты на штатного продакт-менеджера, системного администратора, обучение сотрудников работе с системой.

При расчете TCO оказывается, что первоначальная смета на разработку составляет лишь 40–50% от реальных затрат компании на IT-продукт в течение трех лет.

Не подписывайте размытые сметы. Дезогрегируйте проект на этапы (вехи) продолжительностью не более 3–4 недель. Каждый этап должен иметь измеримый результат (deliverable), который можно протестировать.

В договоре необходимо четко разграничить понятия «дефект/баг» и «Change Request (доработка)». Устранение дефектов, выявленных в течение гарантийного срока, осуществляется исключительно за счет подрядчика.

Убедитесь, что в смете зафиксирован пункт о передаче исключительных прав. Запросите подтверждение, что при разработке не используются Open-Source библиотеки с лицензиями типа GPL, обязывающими раскрывать исходный код всего коммерческого продукта.

Требуйте включения в смету работ по составлению инструкций для пользователей и администраторов системы, а также проведения обучающих сессий для сотрудников компании.

Точная фиксация стоимости (Fixed Price) возможна только при наличии исчерпывающего технического задания и прототипов. Однако для крупных проектов эта модель несет скрытые риски: подрядчик закладывает в стоимость до 50% рисков или начинает экономно относиться к качеству кода при возникновении трудностей. Оптимальный подход — зафиксировать стоимость первого этапа (проектирование и аналитика), а затем двигаться по итерационной модели с ограничениями бюджета (Caped T&M).

Модель Time and Materials (оплата по факту потраченных часов) перекладывает все риски неэффективности на заказчика. Без штатного CTO или квалифицированного технического аудитора заказчик не сможет проверить, действительно ли разработка авторизации заняла 80 часов вместо 10, или эти часы были списаны для компенсации простоев других специалистов подрядчика.

Согласно ст. 1296 ГК РФ, если договор на создание программы для ЭВМ не содержит прямого условия об отчуждении исключительных прав заказчику, эти права остаются у подрядчика (исполнителя). Заказчик в таком случае получает лишь неисключительное право использовать созданный софт для собственных нужд. Продать, передать или сдать в аренду такой софт компания не сможет.

Для принятия разработанного ПО к бухгалтерскому учету в качестве нематериального актива (НМА) согласно ФСБУ 14/2022 «Нематериальные активы» необходимо выполнить ряд условий. Главные из них — наличие документов, подтверждающих исключительные права компании на объект (акт приема-передачи с приложением полного реестра прав), способность приносить экономическую выгоду и отсутствие намерений продать объект в течение 12 месяцев. В первоначальную стоимость НМА включаются все фактические затраты на разработку, включая консультационные услуги и адаптацию ПО.

Рыночным стандартом в корпоративной IT-разработке считается гарантийный срок от 3 до 6 месяцев с момента подписания итогового акта сдачи-приемки работ. В течение этого периода подрядчик обязан бесплатно устранять критические и критически важные дефекты, если они препятствуют нормальной эксплуатации системы в соответствии с согласованным ТЗ.