Оверинжиниринг обходится ИТ-отрасли дороже, чем устаревший стек

Глобальные расходы на ИТ утроились за 20 лет и достигли $5,6 трлн, но доля успешных проектов не выросла – она застыла на отметке приблизительно 30%. СНовый аналитика IEEE Spectrum указывает: корень проблемы не в технологиях, а в управленческих решениях. Российские практики подтверждают этот вывод конкретными кейсами – от внедрения Kubernetes, которое заканчивается увольнением DevOps-инженера, до Scrum «по учебнику», парализующего работу компании.

Материал IEEE Spectrum стал одной из самых обсуждаемых публикаций прошлого года в профессиональном сообществе. Автор – Роберт Шаретт, один из ведущих мировых экспертов по рискам ИТ-проектов, – проанализировал два десятилетия провалов и пришел к выводу: несмотря на утроение расходов (с $1,7 трлн до $5,6 трлн в ценах 2025 года), процент успешных проектов практически не изменился. Причем даже ИИ-инструменты и копайлоты, по его мнению, не смогут это исправить – потому что корень проблемы лежит не в коде, а в управлении.

Данные Standish Group подтверждают масштаб: лишь 31% ИТ-проектов завершаются успешно, 50% выходят за рамки бюджета или сроков, а 19% проваливаются целиком. В крупных компаниях ситуация еще хуже – там успешны менее 10% проектов.

Эти цифры перекликаются с опытом российских IT-компаний. На экспертной дискуссии об эффективности разработки ПО, организованной на канале «Департамент Разработки» при участии «Диасофт», практики из нескольких компаний описали, как попытки внедрить «правильные» инструменты и методологии оборачиваются потерями.

«Мест, где требуется автоматизация, сегодня огромное количество – от проектирования до деплоя. Но задача в том, что многие команды пытаются собрать весь конвейер с нуля, вместо того чтобы применять готовые платформенные решения. Это как собирать трактор самостоятельно, когда можно взять готовый с набором насадок», – отмечает Александр Сахаров, директор по работе с партнерами компании «Диасофт».

Kubernetes на полгода – потом откат

Типичный скрипт оверинжиниринга описал Алексей Каньков, Senior Backend Developer в Revizto: «ММножество раз видел, как DevOps пытаются принести Kubernetes в компанию, им не хватает квалификации, процедура растягивается на полгода-год, и в конце концов они просто увольняются. А мы возвращаемся к тому, что было. Бизнесу нужны деньги и скорость, а не архитектура уровня Яндекса для продукта на ранней стадии».

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

Другой кейс привел Антон Новожилов, руководитель виртуальный интеграции и автоматизации процессов в mrnet. Его команда пригласила профессиональных скрам-мастеров для постановки процессов: «Они пришли, сказали: нам все понятно, сейчас сделаем классный скрам — строго по книжке. Компания на две недели остановилась. Люди настолько не понимали эти новые процессы, что работа просто встала».

Компания отказалась от Scrum, выстроила собственную методологию на основе Waterfall и за полтора десятка лет вышла на выручку в миллиард рублей. «Это хороший метод оценить производительность – если результат работы приносит достаточно денег», – резюмировал Новожилов.

Показательно, что этот опыт совпадает с данными исследования Engprax: 65 процентов проектов, использующих Agile-практики, не укладываются в сроки и бюджет. Одновременно проекты с четко задокументированными требованиями до начала разработки оказались на 97% успешнее.

Не стек, а хаос вокруг него

Участники дискуссии сошлись в том, что провальные проекты объединяет не ошибка в выборе технологии. CTO компании АЭРО Андрей Почтов отметил, что за годы практики видел одну и ту же картину: слабый менеджмент, размытые требования, плохая коммуникация между командами. Технологический стек в списке причин провала стабильно оказывается на последнем месте.

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

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

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

Текстовая версия дискуссии доступна по ссылке: