Заказная разработка 2025: технологический суверенитет, Low-code и обострение конкуренции

#ФорсПрактика

Ключевые бизнес-тренды и сегменты ИТ-рынка

Основной тренд заказной разработки в России сегодня это импортозамещение и обеспечение технологического суверенитета страны. Этот тренд определяет рост во всех сегментах.

Сегмент корпоративных систем растет за счет того, что корпорации и госсектор активно заменяют иностранное ПО (SAP, Oracle, Microsoft) российскими аналогами, которые требуют значительной доработки, адаптации и интеграции, что определяет рост и в сегменте интеграционных решений.

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

Миграция на отечественное ПО, как правило, требует проектирования новой архитектуры, развёртывания и интеграции комплекса систем и разработки тех функциональных возможностей, которые отсутствуют в «коробке».

Госзаказ по-прежнему остаётся главным двигателем ИТ-рынка: здесь крупнейшие бюджеты и объемы проектов, которые реализуются для госпредприятий и госкомпаний, находящихся под давлением регуляторов.

Фокус на безопасность также определяет «повестку дня»: любые заказные решения, особенно для госсектора, должны соответствовать требованиям ФСТЭК и ФСБ.

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

Главные технологические тренды рынка заказной разработки

На рынке сегодня доминируют следующие технологические тренды:

• Low-code разработка
• Платформенные решения — заказчики в меньшей степени настроены собирать решения из кирпичиков open-source технологий, предпочитая полностью отечественные платформы, обеспеченные поддержкой вендора.
• Разработка с применением ИИ.

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

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

Среди факторов, пока ограничивающих возможности применения ИИ для разработки, необходимость обеспечения конфиденциальности передаваемой ИИ информации. В России ограничен прямой доступ к передовым зарубежным языковым моделям, а использование облачных моделей не всегда обеспечивает необходимый уровень конфиденциальности. В этом отношении стоит положительно отметить усилия Сбера по созданию нейросетевых моделей, который могут быть развернуты в закрытом контуре.

Факторы, сдерживающие развитие рынка заказной разработки

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

Крупные банки, ритейлеры и промышленные холдинги, государственные организации, создавшие мощные IT-департаменты для внутренних нужд, разрабатывают системы полностью для «себя», не привлекая профильные компании, и начинают предлагать свои наработки и платформы на внешнем рынке, обостряя конкуренцию.

Всё это сдерживает развитие заказной разработки по нескольким причинам:

• Неэффективность и субсидирование

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

• Война зарплат

ИТ-специалисты уходят во внутренние ИТ-департаменты крупных компаний (банков, сырьевого сектора), которые могут платить больше из средств основного бизнеса.

• Отсутствие отлаженных технологических процессов работы с внешним заказчиком

Внутренняя разработка «заточена» под специфические нужды родительской компании. При выходе на рынок они часто предлагают негибкий, сделанный под себя продукт, плохо адаптируемый под потребности других бизнесов, не обладая при этом опытом его внедрения где-то ещё, кроме родительской компании.

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

Следует отметить еще один фактор, сдерживающий развитие рынка заказной разработки:

• Все более широкое распространение low-code платформ

С одной стороны, low-code — это тренд, а с другой — он создает иллюзию, что сложную систему можно сделать быстро и без глубокой экспертизы.

На старте проекта при сравнении оценок на разработку на low-code vs high-code очень выигрышно выглядит первый вариант. Прототип системы собирается за недели. Но затем для сложных процессов и систем начинается бесконечный цикл уточнения требований, многие из которых выходят за рамки возможностей самой платформы. Скорость поставки функционала падает экспоненциально, а технический долг растет. В итоге проект выходит дороже и идёт дольше, чем если бы изначально выбрали классическую разработку с четким ТЗ. У нас был опыт участия в таком проекте, который затянулся на 2 года заказной разработки, требовавшейся для доработки самой платформы.

Процессы заказной разработки развивались длительное время, в то время как в low-code отсутствует:

• Версионность
• Документирование
• CI/CD
• Автотестирование
• Инструменты для безопасной разработки

При разработке на low-code ограничены возможности оптимизации производительности: при сложной логике и больших объемах данных low-code-приложения начинают работать медленно и оптимизировать их довольно трудно.

Все вышеперечисленное существенно повышает стоимость владения такой системой, ее развития, поддержки и эксплуатации.

Надо отметить, что проблема не в low-code как инструменте для быстрого прототипирования или решения внутренних задач. Проблема в его некорректном позиционировании и применении для создания сложных, высоконагруженных и критичных к безопасности систем.

Приоритеты и запросы заказчиков

Приоритеты и запросы заказчиков в 2025 году тоже изменились и сейчас это:

• Безопасность

Полное соответствие требованиям ФСТЭК, ФСБ, 152-ФЗ. Требования к безопасной разработке на стороне исполнителя. Дополнительные требования к контурам исполнителя, на которых выполняется разработка, требования на регулярные проверки уязвимости этих контуров внешними аудиторами.

• Встроенные ИИ-агенты

Цифровые помощники на основе LLM моделей для поиска, выдачи рекомендаций, подготовки проектов документов и т.д.

• Технологический суверенитет

Использование только доверенного/отечественного стека. Вендор должен доказать «чистоту» цепочки поставок ПО, обеспечивать его поддержку и осуществлять архитектурный консалтинг при внедрении этого ПО.

• Устойчивость к киберугрозам

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

Смена бизнес-модели сотрудничества

Меняется не только спрос на технологии, но и фундаментальные принципы взаимодействия заказчика и подрядчика.

Кажется, классический Agile, особенно Scrum-проявления — спринты, бесконечные изменения, нефиксированная цена, теряет популярность у крупных заказчиков. Причины этого — дефицит бюджетов, так как важна предсказуемость затрат, и регуляторные требования — полноценное проектирование с учетом ИБ, наличие проектной документации и четкое соответствие ТЗ.

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

На аутстаффинг (предоставление специалистов) спрос падает или трансформируется. На это есть две основные причины. Первая — риски ИБ. Допуск внешнего специалиста к системам становится огромным риском. Вторая — налоговая и регуляторная нагрузка. Усиление контроля над фактическими расходами в ходе выполнения проектов по государственному заказу делает схему аутстаффинга еще более сложной.

На аутсорсинг полного цикла (проектная модель) спрос по-прежнему большой. В этой модели заказчиков привлекает разделение рисков — подрядчик берет на себя полную ответственность за результат, сроки, качество и соответствие требованиям ИБ, что особенно критично. Кроме того, гарантируются высокие компетенции, экспертиза и опыт в конкретной области.

Можно выделить три ключевых драйвера смены бизнес-модели:

• Требование технологического суверенитета — заказчик должен владеть всеми правами на код и инфраструктуру. А для этого нужен интегратор, который передаст все артефакты.
• Безопасность — любая модель проходит проверку вопросом: «Как это обеспечит соответствие требованиям ИБ?». Модель полного цикла, где один подрядчик отвечает за все, упрощает решение этой задачи.
• Дефицит бюджетов, но не задач — заказчики готовы платить за результат, но не за процесс типа scrum.

Растет спрос не на ресурсы, а на гарантированные бизнес-результаты в рамках прозрачной и безопасной модели сотрудничества. Поэтому всё более востребованной становится роль стратегического ИТ-партнера, который разделяет с заказчиком риски и ответственность за итоговые бизнес-результаты и технологическую безопасность.