Какие ИТ-процессы устарели в 2026 году и что приходит им на смену
Автор: Юлия Мицкевич, операционный директор KODE
Компании активно подключают AI, облака и новые инструменты разработки, но сами процессы меняют гораздо медленнее. В итоге разработчики генерируют код быстрее, а релиз всё равно проходит через длинную цепочку согласований. Тестирование автоматизируется частично, но перед выпуском команда снова неделями проверяет всё вручную. Инфраструктура живёт в облаке, но настраивается через набор скриптов, о которых знает один инженер. В 2026 году именно такие противоречия всё чаще становятся настоящим ограничением для ИТ.
Исследование DORA 2025, основанное на опросе почти 5 тыс. технологических специалистов, хорошо показывает этот эффект: AI работает прежде всего как усилитель. В зрелой команде он ускоряет работу, а в плохо организованной — быстрее производит код, задачи и изменения, которые потом упираются в те же старые узкие места.
Разберём процессы, которые стоит пересмотреть в первую очередь.
1. Разработка большими релизами
Сценарий знакомый: несколько месяцев команда разрабатывает большой набор функций, затем несколько недель тестирует, после этого выпускает всё одним релизом.
Главная проблема здесь не в самом сроке. Бизнес слишком долго ждёт обратную связь.
Если гипотеза оказалась неправильной, компания узнаёт об этом после нескольких месяцев работы. За это время требования успевают измениться, пользователи — поменять поведение, а сама команда — разработать ещё несколько функций поверх неверного решения.
Современный подход — выпускать изменения небольшими частями и быстрее доводить их до пользователей.
DORA уже много лет связывает эффективность разработки со скоростью и стабильностью поставки изменений, а в исследовании 2025 года подчёркивает ещё одну вещь: AI не исправляет плохой процесс поставки, а усиливает его.
То есть разработчик действительно может написать код быстрее. Но если дальше изменение две недели ждёт проверки, согласования и общего релиза, бизнес почти ничего не выиграл.
Что приходит на смену: короткие циклы разработки, небольшие релизы, feature flags, автоматизированная поставка и постоянная обратная связь от пользователей.
2. QA как отдел, который проверяет продукт в конце
Старая модель выглядит так: разработчики закончили работу и «передали её тестировщикам».
При частых релизах эта схема быстро превращает QA в очередь. Чем быстрее разработчики выпускают изменения, тем больше ручной работы скапливается у тестировщиков. Особенно заметно это становится с AI-инструментами, которые позволяют писать код быстрее, чем раньше.
По данным Perforce State of DevOps 2026, роли уже начинают меняться: 53% респондентов говорят, что разработчики сами участвуют в написании тестов, а QA-команды всё сильнее смещаются от исполнения тест-кейсов к Quality Engineering.
В отдельном исследовании Perforce об AI в тестировании 41% респондентов отмечают фокус QA на аналитике качества и governance, ещё 39% — на оркестрации тестирования между пайплайнами, окружениями и данными.
Это не значит, что ручное тестирование исчезает. Человек по-прежнему лучше исследует нестандартные сценарии, оценивает пользовательский опыт и находит проблемы, которые сложно предусмотреть заранее. Меняется другое: качество перестаёт быть задачей одного отдела в конце разработки. Что приходит на смену: автоматические тесты в CI/CD, участие разработчиков в качестве, Quality Engineering и ручное exploratory-тестирование там, где оно действительно полезно.
3. Команды, которые работают каждая в своей части процесса
Бизнес пишет требования. Разработка реализует. QA проверяет. DevOps выкатывает. Если что-то сломалось — начинается выяснение, кто допустил ошибку. Такая схема работает, пока изменений немного. Чем быстрее развивается продукт, тем дороже становятся границы между командами. Информация теряется при передаче, решения ждут согласований, а у каждого подразделения появляются собственные KPI. AI только усиливает этот эффект.
В State of DevOps 2026 Perforce 70% опрошенных компаний говорят, что зрелость DevOps существенно влияет на успех внедрения AI. В организациях с высоким уровнем зрелости AI встроен в процессы у 72% респондентов, с низким — только у 18%.
То есть компании может не хватать вовсе не ещё одного AI-инструмента, а нормального взаимодействия между командами.
Что приходит на смену: кросс-функциональные продуктовые команды, общие цели, единые метрики и ответственность не только за «свою часть», но и за результат продукта после релиза.
4. Инфраструктура, которую настраивают вручную
Есть ещё одна модель, которая хорошо работает до первого серьёзного масштабирования. Инженер заходит на сервер, меняет настройки, запускает скрипт, что-то фиксирует вручную. Все знают, к кому обратиться, если возникла проблема. Потом инфраструктуры становится больше. Появляются тестовые и продуктовые окружения, несколько сервисов, облака, новые команды. И внезапно никто не может точно сказать, почему два одинаковых окружения настроены по-разному.
Поэтому современный DevOps всё сильнее строится вокруг Infrastructure as Code: конфигурация описывается в коде, хранится вместе с историей изменений и может быть воспроизведена автоматически. Это особенно важно с ростом AI-нагрузок. Вычислительных ресурсов становится больше, конфигурации сложнее, а ручная настройка хуже масштабируется.
Что приходит на смену: Infrastructure as Code, автоматическое развёртывание, наблюдаемость, централизованное управление конфигурациями и платформенные команды.
Последний тренд хорошо заметен и в свежем исследовании Perforce по platform engineering: среди организаций со зрелой платформенной инженерией 73% называют её существенным или критическим фактором успеха AI-проектов.
5. ТЗ, которое нельзя менять
Большое техническое задание когда-то давало бизнесу ощущение контроля: подробно описали будущий продукт, согласовали сроки и стоимость — теперь осталось только сделать. Проблема в том, что продукт меняется быстрее документа. Представим проект на год. Через три месяца появляются первые прототипы. Через пять пользователи показывают, что часть сценария им неудобна. Через семь конкурент выпускает новую функцию. Если команда всё равно продолжает реализовывать ТЗ, утверждённое год назад, формально проект идёт по плану. Продуктово — уже нет. Это не значит, что нужно отказаться от требований, бюджета и планирования. Меняется сама точка контроля. Вместо «сделали ли мы ровно то, что записали шесть месяцев назад?» лучше спрашивать: «решает ли то, что мы сейчас делаем, исходную бизнес-задачу?»
Что приходит на смену: продуктовые гипотезы, короткий горизонт детального планирования, регулярная переприоритизация и возможность менять решение после обратной связи.
6. Управление разработкой по количеству задач и строк кода
«Закрыли 120 задач».
«Сделали 80 story points».
«Разработчик написал больше всех кода».
Выглядит измеримо, но почти ничего не говорит о пользе для бизнеса.
Более того, с распространением AI такие показатели становятся ещё менее показательными. Код теперь можно генерировать быстрее. Его количество растёт — но вместе с ним могут расти сложность ревью, количество изменений и риск нестабильности.
DORA прямо описывает AI как усилитель существующей системы: локальный рост производительности разработчика ещё не означает улучшение всего процесса. В материалах DORA 2026 года отмечается, что AI ускоряет создание кода, но часть сэкономленного времени затем уходит на его проверку и аудит.
Поэтому считать нужно не активность разработчиков, а движение продукта.
Например:
- сколько занимает путь от идеи до продакшна;
- как часто изменения вызывают проблемы;
- сколько времени занимает восстановление;
- сколько задач возвращается на доработку;
- как изменение повлияло на продуктовую метрику.
Что приходит на смену: инженерная аналитика, DORA-метрики, продуктовые показатели и анализ полного value stream вместо контроля количества выполненных задач.
7. Десятки инструментов, которые никак не связаны друг с другом
Отдельная проблема современной разработки — инструментов стало слишком много.
Задачи находятся в одной системе. Код — в другой. CI/CD — в третьей. Инциденты — в четвёртой. Аналитика продукта — в пятой. Информация о клиентах — ещё где-то. Само по себе наличие разных решений нормально. Проблема начинается, когда один и тот же процесс приходится собирать вручную из пяти источников.
Руководитель хочет понять, почему релизы замедлились, и для ответа кто-то несколько дней выгружает данные из Jira, GitLab и системы мониторинга. AI добавляет ещё один слой инструментов.
В Perforce State of DevOps 2026 только 32% организаций описывают свои процессы поставки как хорошо стандартизированные и поддержанные автоматизацией и governance. Ещё 34% работают с частично стандартизированными или ad hoc-процессами.
В такой среде новый AI-инструмент не создаёт единый процесс. Он просто становится ещё одним элементом разрозненной системы.
Что приходит на смену: интеграция инженерных инструментов, единые платформы для типовых сценариев и сквозная аналитика вместо очередного самостоятельного сервиса.
Что из этого действительно стоит менять в первую очередь
Не нужно одновременно перестраивать разработку, тестирование, инфраструктуру и оргструктуру. Лучше начать с того места, где бизнес уже видит последствия. Если релиз занимает три месяца, то разбираться с циклом поставки. Если после каждого релиза десятки багов, то с качеством и автоматизацией. Если DevOps-команда стала очередью на несколько недель, то с платформой и self-service. Если никто не может объяснить, почему разработка стала медленнее, — с метриками. Если AI-инструменты уже купили, но общей производительности это почти не изменило, стоит посмотреть не на модель, а на весь процесс вокруг неё.
Именно этот вывод объединяет свежие исследования DORA и Perforce: технология сама по себе редко исправляет плохую организацию работы.
В итоге
Главный устаревший подход в ИТ в 2026 году — не Waterfall, ручное тестирование или конкретный инструмент. Это попытка ускорить отдельный участок, не меняя систему вокруг него. Можно в два раза быстрее писать код и столько же ждать релиза. Автоматизировать создание тестов и продолжать проверять качество только в конце. Купить AI-помощника каждому разработчику, но оставить команды в бесконечной очереди согласований. Поэтому зрелость ИТ сегодня определяется не количеством новых технологий. Она определяется тем, насколько быстро компания может превратить изменение в работающий результат, проверить его на реальных данных и скорректировать направление без многомесячного цикла. И если новый AI-инструмент не дал ожидаемого ускорения, прежде чем менять модель, стоит посмотреть на процессы, в которые эту модель встроили.