Бизнес требует прорывов, а технические команды уходят в глухую оборону, избегая любых рисков. Почему так происходит? Ответ кроется не в нехватке талантов, а в глубоких системных сбоях на стыке управления, финансов и корпоративной культуры. Рассмотрим, почему безынициативные ИТ-отделы годами создают одни и те же функции.
Иллюзия контроля и налог на микроменеджмент
Все начинается на уровне стратегии. Классическая ошибка топ-менеджмента — нанять дорогих специалистов и директивно спустить им готовые решения. В итоге высокооплачиваемые эксперты превращаются в «кодеров по вызову». Интеллектуальный капитал стремительно выгорает, ведь линейный менеджмент никогда не возьмет на себя ответственность за стратегию, в формировании которой ему не позволили участвовать.
Избыточные круги согласований и раздутые матрицы RACI создают лишь видимость управления рисками. На деле они порождают коллективную безответственность: если релиз срывается, каждый участник процесса надежно защищен «согласованной бумагой». Убытки же несет исключительно бизнес.
Ситуация усугубляется еще и тем, что сотрудники мыслят предельно прагматично: если инновационное архитектурное решение экономит компании миллионы, команда в лучшем случае получит премию в размере оклада. Но если эксперимент приведет к сбою — последует публичная порка или увольнение. Инициатива становится финансово невыгодной.
Особенно ярко это проявляется в компаниях, переживших серьезные сбои или кассовые разрывы. И если этот режим гиперкомпенсации вовремя не отключить, фокус бизнеса навсегда смещается с развития на банальное выживание, где команда тратит 80% времени на перестраховку и лишь 20% — на сам продукт.
Финансовая и юнит-экономика
Вторая причина кроется в юнит-экономике. Внедрение передовых технологий, будь то оркестрация мультиагентных ИИ-систем в Vertical SaaS, часто дает непредсказуемую финансовую модель. Страх технического руководства перед экспоненциальным ростом затрат на API и сжиганием бюджета приводит к тому, что перспективные проекты годами пылятся в статусе «архитектура пока не готова» (так называемая «ловушка OpEx»).
Бизнес, со своей стороны, требует гарантий ROI до старта проекта. Но в технологиях невозможно гарантировать возврат инвестиций на этапе гипотезы. Заставляя просчитывать точные цифры для MVP, CEO вынуждает команду приносить лишь скучные, небольшие улучшения, на корню отсекая прорывные продукты.
Технические команды изолированы от бизнес-контекста. Инженеры оптимизируют инфраструктуру ради инфраструктуры, не понимая, как их решения влияют на CAC (стоимость привлечения), LTV или операционную маржу. Без связи кода с деньгами продуктовый Ownership не возникает.
Инфраструктурные заложники
Бизнес годами требует новых фич, игнорируя рефакторинг фундамента, пока не образуется хрупкий legacy-монолит. Команда избегает ответственности за ключевые сервисы, понимая: любое вмешательство может обрушить ядро бизнеса.
Из этого вытекает критическая зависимость от исполнителей. Экспертиза по критическим узлам концентрируется в руках пары разработчиков, диктующих условия. Остальные просто обходят эти зоны стороной.
Сюда же добавляется ловушка вендор-лока. Продукт намертво врастает в облачного провайдера. Даже понимая необходимость переезда для оптимизации костов, топ-менеджмент годами оплачивает невыгодные тарифы из-за страха потерять данные. Никто не хочет войти в историю как руководитель, при котором компания «легла» на неделю.
А в секторах с высокой ценой ошибки (MedTech, FinTech) к этому добавляется комплаенс-ступор. Юристы и служба безопасности, опасаясь регуляторных штрафов за работу с данными или ИИ, превращаются в непроходимое «бутылочное горлышко», полностью парализуя гибкость разработки.
Процессные искажения
Как итог, ИТ-отдел деградирует до синдрома «фабрики фич». Инженеры механически перерабатывают тикеты в код, отвечая лишь за соблюдение дедлайна конкретной задачи. Ответственность за рыночный успех продукта размывается до нуля.
Внедрение модных фреймворков не спасает, оборачиваясь карго-культом Agile. Компании тратят миллионы на коучей, но сохраняют директивную культуру. Синхронизации превращаются в ритуальные статус-репорты, реальные полномочия командам не отдаются, что рождает в коллективе лишь массовый цинизм.
Вишенкой на торте становится культура «тушения пожаров». Системы поощрений часто выстроены так, что инженер, героически поднявший упавший сервер в ночь на воскресенье, получает премию и славу. При этом рутинная, системная работа по предотвращению таких инцидентов остается незамеченной. Команде становится репутационно невыгодно строить надежные системы — гораздо ярче выглядит эффектное спасение бизнеса от кризиса, который можно было не допускать.
Боясь взять на себя осознанный технический долг, архитекторы закладывают решения для проверки простейшей гипотезы. Выжигаются бюджеты и время на запас прочности, который продукту пока объективно не нужен.
Чтобы вернуть командам смелость брать на себя риски, бизнесу необходимо отказаться от иллюзии тотального контроля. Настоящая ответственность не прописывается в должностных инструкциях — она рождается там, где есть право на ошибку, прозрачная связь кода с деньгами и общая заинтересованность в конечном продукте. И пока корпорации не перестроят эту математику, их дорогие ИТ-отделы так и останутся блестящими исполнителями, избегающими любых смелых решений.
