В 70% компаний собственная разработка не успевает за бизнесом

Привет! Мы команда LDM ^[1] (входит в ИТ-холдинг LANSOFT ^[2]) при поддержке Ассоциации ^[3] «РОСЭУ» (сообщество разработчиков и операторов систем электронных услуг) провели серию глубинных интервью руководителей. И узнали, как их команды справляются с ключевыми вызовами при создании собственных ИТ-решений и адаптации существующих. Результат: более 70% организаций не успевают за запросами бизнес-заказчиков при самостоятельной реализации бэклога. Но это еще не все. 

С кем мы общались в процессе

В исследовании приняли участие директора по разработке, CIO и CTO крупнейших компаний в области финсектора (33%), ритейла (32%), промышленности (28%), а также нефтегазовые и ИТ-предприятия, где предъявляются высокие требования к нагрузке и безопасности систем.

Глобальная проблема

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

Бэклог исчисляется тысячами задач в год, но собственных ресурсов и компетентных сотрудников не хватает на их своевременную реализацию. Бизнес готов отсрочить изменения на 3-7 дней. Но реальность показывает иную картину: фактический time-to-market в legacy-ландшафтах – 6 месяцев и более. В итоге: медленная собственная разработка не может догнать современный бизнес, из-за чего компании сдают позиции в конкурентной гонке.

Автотесты тормозят релизы

80% респондентов также признались, что не имеют полноценно встроенных автотестов в CI/CD-пайплайн (конвейер непрерывной интеграции и доставки). Однако без тщательной проверки каждого коммита кода риск поставки приложения с ошибками повышается. Такой подход увеличивает время выпуска релизов и, как следствие, – тормозит внутренние процессы и развитие.

ИИ внедряется снизу

69% организаций уже используют или тестируют инструменты искусственного интеллекта ^[4] в рамках своей инфраструктуры. Но их внедрение происходит снизу вверх и редко связано со стратегией. Нейросети стали частью инженерной среды. С их помощью проводится генерация и рефакторинг кода, обрабатываются документы и формируются корпоративные базы знаний (RAG). Некоторые респонденты сообщили, что ИИ повышает производительность на 10-30%, но он лишь усиливает зрелые процессы, а не компенсирует их отсутствие.

Кастомизация своими силами

28% корпоративного ландшафта компаний-участников – это внутренняя разработка, остальные 72% – приобретенные платформы. При этом граница между концепциями стирается, так как большинство готовых решений требует глубокой кастомизации, которая ложится на плечи внутренней команды. В итоге лишь треть функций из коробочной версии используются сотрудниками, остальные возможности дорабатываются самостоятельно на базе купленной системы. Кроме этого компании сталкиваются с архитектурной сложностью, техническим долгом и замедлением поставки изменений.

Low-code – удобная технология… местами

Отношение к low-code среди enterprise-сегмента спорное. С одной стороны — инструменты подходят для MVP (минимально жизнеспособного продукта) и оптимизации административных процессов. С другой — когда компания берется за масштабирование критических систем, возникают проблемы: рост трудозатрат, сложности с производительностью, зависимость от вендора и недостаток экспертизы. Участники исследования отмечают, что low-code – местами удобная технология, но зачастую она дороже и сложнее, чем разработка на стандартных языках.

Количество vs зрелости

Архитектурная сложность – главный системный барьер для бизнеса в 2026 году. Компаниям важен предсказуемый time-to-market без роста технического долга. Сейчас организации переходят от хаотичной кастомизации к платформенному подходу, где микросервисы, CI/CD, автотесты и ИИ становятся частью единой системы. В дальнейшем конкурен��оспособность ИТ-команд будет определяться не количеством разработчиков, а зрелостью архитектуры и процессов.

С полной версией исследования можно ознакомиться по ссылке ^[5].