/13267255/i_800.jpg)
Внутренняя разработка до сих пор является важным стратегическим активом бизнеса, но реальные возможности технических отделов не совпадают с ожиданием руководства. Так предприятия попадают в «ИТ-ловушку»: список задач стремительно растет, а архитектурная инерция и глобальный дефицит квалифицированных специалистов тормозит инсорс-разработку и сопровождение цифровых систем.
В ряде организаций бэклог исчисляется тысячами задач в год, но собственных ресурсов и компетентных сотрудников не хватает на их своевременную реализацию. Бизнес готов отсрочить изменения на 3-7 дней, но реальность показывает иную картину: фактический time-to-market в legacy-ландшафтах – 6 месяцев и более. Таким образом, медленная собственная разработка не может догнать современный бизнес, из-за чего компании сдают позиции в конкурентной гонке.
80% респондентов также признались, что не имеют полноценно встроенных автотестов в CI/CD-пайплайн (конвейер непрерывной интеграции и доставки). Однако без тщательной проверки каждого коммита кода риск поставки приложения с ошибками повышается. Такой подход увеличивает время выпуска релизов и, как следствие, – тормозит внутренние процессы и развитие.
69% организаций уже используют или тестируют инструменты искусственного интеллекта в рамках своей инфраструктуры. Но их внедрение происходит «снизу вверх» и редко связано со стратегией. Нейросети стали частью инженерной среды – с их помощью проводится генерация и рефакторинг кода, обрабатываются документы и формируются корпоративные базы знаний (RAG). Некоторые респонденты сообщили, что ИИ повышает производительность на 10-30%, но он лишь усиливает зрелые процессы, а не компенсирует их отсутствие.
В ходе интервью выяснилось, что около 28% корпоративного ландшафта компаний-участников – это внутренняя разработка. Остальные 72% приходятся на приобретенные платформы. При этом граница между концепциями стирается, так как большинство готовых решений требует глубокой кастомизации, которая ложится на плечи внутренней команды. В итоге лишь треть функций из коробочной версии используются сотрудниками, остальные возможности дорабатываются самостоятельно на базе купленной системы. Также организации часто сталкиваются с архитектурной сложностью, техническим долгом и замедлением поставки изменений.
Отношение к low-code среди enterprise-сегмента сложилось спорное. С одной стороны – инструменты подходят для MVP (минимально жизнеспособного продукта) и оптимизации административных процессов. С другой – когда компания берется за масштабирование критических систем, возникают проблемы: рост трудозатрат, сложности с производительностью, зависимость от вендора и недостаток экспертизы. Участники исследования также отмечают, что low-code – местами удобная технология, но зачастую она дороже и сложнее, чем разработка на стандартных языках.