Разработка ПО на заказ — это создание программного продукта под конкретные бизнес-процессы заказчика, а не адаптация тиражного решения. В 2026 году такой подход сокращает затраты на кастомизацию до 30% по сравнению с доработкой коробочных систем, когда требования выходят за рамки типового функционала. Средняя стоимость проекта в сегменте B2B составляет от 3,5 до 12 млн рублей, сроки — от 4 до 14 месяцев в зависимости от сложности. При этом около 60% перерасходов бюджета связаны с неполным техническим заданием и слабой проработкой архитектуры на старте. Грамотное управление требованиями и вовлечение заказчика в этапы приёмки удерживают отклонение от бюджета в пределах 10–15%.
Материал ориентирован на ИТ-руководителей и владельцев бизнеса, которые оценивают целесообразность заказной разработки взамен тиражного продукта. Разберём, когда кастомный софт экономически оправдан, как составить техническое задание, которое не превратится в бесконечные правки, какими методиками пользоваться для оценки сроков и бюджета и почему игнорирование ГОСТ Р 56939 способно заблокировать ввод системы в промышленную эксплуатацию.
Вы получите рабочую структуру ТЗ, расчётные модели для бюджетирования, карту рисков и чек-лист приёмки — всё, что помогает пройти путь от идеи до стабильного релиза без типовых потерь.
Когда заказная разработка оправдана: критерии выбора
Решение о заказной разработке принимают, когда тиражные продукты не покрывают ключевые бизнес-процессы или требуют настолько глубокой кастомизации, что цена доработок приближается к стоимости создания системы с нуля. Ещё один явный сигнал — потребность в уникальной логике, которая составляет конкурентное преимущество и не должна тиражироваться на рынке.
Критерии, при которых заказная разработка становится рациональным выбором:
-
Процессы компании жёстко регламентированы отраслевыми нормами и не вписываются в конфигурации коробочных ERP/CRM.
-
Требуется интеграция с унаследованными системами, которые не поддерживают стандартные API и коннекторы тиражных решений.
-
Важна скорость вывода продукта на рынок: типовой софт не даёт нужной гибкости без длительного цикла согласования доработок.
-
Бизнес работает с высоконагруженными сервисами или специфичными протоколами обмена данными, не поддерживаемыми массовым ПО.
-
Компания планирует дальнейшее лицензирование или продажу созданного продукта и нуждается в полном контроле над исходным кодом.
Техническое задание: структура и типовые ошибки
Техническое задание на разработку в проектах с фиксированной ценой выполняет роль контракта: всё, что выходит за рамки ТЗ, оплачивается отдельно. При контрактах Time & Materials детальное ТЗ всё равно снижает неопределённость и служит отправной точкой для планирования спринтов.
Рабочая структура ТЗ для корпоративного проекта включает следующие блоки:
-
Назначение и цели системы (с измеримыми KPI — например, сокращение времени обработки заявки до 2 минут).
-
Функциональные требования: сценарии использования с ролями, экранные формы, бизнес-правила, описание алгоритмов расчётов.
-
Нефункциональные требования: время отклика, пиковая нагрузка, доступность 99,5% для критичных систем, требования к резервному копированию и катастрофоустойчивости.
-
Интеграционный ландшафт: перечень смежных систем, протоколы обмена (REST, gRPC, SOAP, очереди сообщений), форматы данных, регламенты синхронизации.
-
Требования к безопасности: модель угроз, разграничение доступа, журналирование, соответствие ГОСТ Р 56939, требования ФСТЭК при работе с персональными данными.
-
Критерии приёмки: тестовые сценарии, показатели качества, процедура передачи исходного кода и документации по ГОСТ 19 (ЕСПД)'eсли заказчик настаивает на формальной документации.
Наиболее частые ошибки ТЗ:
-
Смешение бизнес-требований и технической реализации (например, указание конкретного стека вместо описания ожидаемого поведения).
-
Отсутствие приоритетов и зависимостей — команда тратит ресурсы на второстепенный функционал.
-
Пропуск граничных сценариев: что происходит при ошибке валидации, таймауте, пиковой нагрузке.
-
Размытые формулировки («удобный интерфейс», «быстрая работа») без измеримых критериев.
Оценка стоимости и сроков: методики и реалии
Стоимость разработки ПО на заказ определяется не только человеко-часами. Заметную долю бюджета забирают инфраструктура (облака, лицензии на сторонние компоненты), автоматизированное тестирование, документирование и резерв на управление изменениями.
Рабочие методики оценки:
-
Экспертная оценка с разложением на функциональные блоки (WBS) — подходит для проектов с похожими аналогами.
-
Оценка по аналогам — сравнивают со схожими по масштабу системами с поправкой на сложность стека.
-
Параметрическая оценка (COCOMO II, функциональные точки) — даёт приемлемую точность при наличии формальных требований.
-
Оценка через пользовательские истории в сторипойнтах — работает в итеративных контрактах, но требует хорошей исторической статистики команды.
Типичные диапазоны бюджета и сроков для B2B-проектов в 2026 году:
| Класс системы | Примерные характеристики | Бюджет, млн руб. | Длительность, мес. |
|---|---|---|---|
| Небольшой портал или мобильное приложение с типовым backend | До 10 ролей, стандартная аутентификация, 3–5 интеграций | 1,5–4,0 | 3–6 |
| Среднее корпоративное решение | Сложная бизнес-логика, 10–30 интеграций, высокая доступность | 4,0–12,0 | 6–12 |
| Крупная высоконагруженная система | Распределённая архитектура, микросервисы, строгие SLA по отказоустойчивости | 12,0–60,0+ | 12–18+ |
Приведённые цифры отражают стоимость разработки ПО под ключ с учётом проектного управления и минимального запаса на изменения. Фактический бюджет корректируют после детализации ТЗ и уточнения нефункциональных требований. Основной источник расхождений — неучтённые интеграции, миграция данных и требования регуляторов, всплывающие на этапе приёмки.
Риски и управление ими: что чаще всего срывает проекты
По статистике отраслевых опросов 2025–2026 годов, три ключевых риска заказной разработки — разрастание требований (scope creep), текучесть ключевых разработчиков и затягивание приёмки со стороны заказчика. Каждый из них способен добавить 20–40% к бюджету и сдвинуть запуск на квартал.
Карта рисков и упреждающие меры:
| Риск | Вероятность | Влияние на бюджет | Предупреждение |
|---|---|---|---|
| Scope creep — неконтролируемое расширение функционала | Высокая | +20–50% | Жёсткое управление изменениями через Change Request Board; любое дополнение оценивается и утверждается |
| Уход архитектора или senior-разработчика | Средняя | +15–30% | Документирование ключевых решений, парное программирование, bus factor > 2 |
| Затянутая приёмка — заказчик не выделяет ресурс на тестирование | Высокая | +10–25% | Включение в ТЗ графика приёмки с фиксацией ответственных и штрафными санкциями за простой команды |
| Недооценка объёма миграции данных | Средняя | +10–20% | Раннее пилотное извлечение и очистка данных, выделение отдельного трека в плане |
| Изменение требований регуляторов (ФСТЭК, 152-ФЗ) на старте эксплуатации | Низкая | +5–15% | Мониторинг проектов нормативных актов, архитектурный запас на доработку критичных компонентов |
Управление рисками не должно ограничиваться таблицей на старте. В плане проекта выделяют контрольные точки для переоценки рисков — обычно после завершения каждого значимого этапа (дизайн архитектуры, готовность MVP, выход в опытно-промышленную эксплуатацию). Резерв на управление рисками закладывают отдельной строкой бюджета — как правило, 10–15% от сметы.
Безопасная разработка: ГОСТ Р 56939 и практические шаги
Безопасная разработка ГОСТ Р 56939 перестала быть рекомендацией для вендоров, которые претендуют на работу с госсектором и объектами критической информационной инфраструктуры (КИИ). В 2026 году заказчики всё чаще требуют соответствия этому стандарту независимо от отрасли — как доказательство зрелости процессов и защиты от инцидентов.
Стандарт описывает процессы, а не конкретные инструменты. Основные направления, которые должны быть отражены в плане разработки:
-
Моделирование угроз и оценка рисков безопасности до написания кода.
-
Статический и динамический анализ кода, анализ состава ПО (SCA) для выявления уязвимостей в сторонних библиотеках.
-
Безопасная сборка и развёртывание: подписание артефактов, неизменяемая инфраструктура, проверки в CI/CD-пайплайне.
-
Тестирование на проникновение и фаззинг-тестирование на этапе приёмки.
-
Реагирование на инциденты: регламент обработки уязвимостей, сроки выпуска исправлений (для критических — не более 72 часов).
Интеграция этих практик добавляет к бюджету проекта в среднем 8–12% на этапе разработки, но экономит кратно больше на этапе эксплуатации за счёт предотвращения инцидентов. При приёмке работ у подрядчика имеет смысл запрашивать отчёты инструментов SAST/DAST и протоколы нагрузочного тестирования безопасности.
Приёмка и начало эксплуатации: критерии готовности
Переход от разработки к поддержке — критически недооценённый этап. Без чётких критериев система может месяцами находиться в состоянии «почти готово», расходуя бюджет на доделки без формальной приёмки.
Чек-лист приёмки для заказчика:
-
Все функциональные требования, зафиксированные в ТЗ, подтверждены прогоном приёмочных тестов.
-
Нефункциональные показатели (время отклика, пропускная способность) измерены под нагрузкой, соответствующей пиковой, с запасом 30%.
-
Отчёты SAST/DAST без критических и высоких уязвимостей; пенетрационные тесты проведены и закрыты.
-
Передача исходного кода в репозиторий заказчика с историей коммитов, документацией по развёртыванию и инструкциями для администраторов.
-
Документация по ГОСТ 19 (описание программы, руководство системного программиста) сдана в согласованном объёме.
-
Проведено нагрузочное тестирование и тестирование отказоустойчивости: система восстанавливается после сбоя в заданное время.
Запуск в промышленную эксплуатацию рекомендуем проводить поэтапно: пилотная группа пользователей, ограниченный функционал, накопление статистики — и только после стабилизации полный ввод.