Автор статьи: Юлия Мицкевич, операционный директор KODE
Компании внедряют AI, переходят в облака, покупают новые инструменты для разработки — и всё равно выпускают релизы месяцами, вручную проверяют каждое изменение и теряют время на согласования между командами.
Проблема часто не в технологиях. Новые инструменты просто накладываются на старые процессы и начинают работать с теми же ограничениями.
1. Разработка большими релизами
Сценарий знакомый: несколько месяцев команда собирает большой объём изменений, потом долго тестирует их и выпускает всё одним релизом.
Главный минус такого подхода — слишком поздняя обратная связь.
Если продуктовая гипотеза оказалась ошибочной, бизнес узнаёт об этом уже после месяцев разработки. К этому моменту поверх исходного решения могут быть сделаны новые функции, а требования пользователей — измениться.
В исследовании DORA 2025 эффективность инженерных команд связывают в том числе со способностью быстро поставлять изменения и адаптироваться к обратной связи.
И AI сам по себе проблему длинных циклов не решает. В том же отчёте DORA отмечается, что искусственный интеллект скорее усиливает существующую систему работы. Если процесс поставки уже выстроен хорошо, команда получает ускорение. Если изменения по-прежнему неделями проходят согласования и проверки, более быстрое написание кода просто создаёт ещё большую очередь дальше по цепочке.
Поэтому устаревает не само долгосрочное планирование, а модель, в которой пользователь видит результат только через несколько месяцев.
Что приходит на смену: небольшие релизы, короткие циклы обратной связи, автоматизированная поставка и возможность менять приоритеты по мере получения данных.
2. Ручное тестирование как основной способ контролировать качество
Ручное тестирование никуда не исчезает. Но если каждая новая версия продукта должна целиком пройти через ручную проверку, QA быстро превращается в узкое место. Разработчики начинают выпускать изменения быстрее, особенно с AI-инструментами, а объём тестирования растёт вместе с ними.
По данным Perforce State of DevOps 2026, около половины компаний отмечают движение QA в сторону quality engineering. Речь уже не только о выполнении тест-кейсов, а о построении системы качества: автоматических проверках, работе с пайплайнами и предотвращении ошибок ещё до релиза.
Это не означает, что тестировщик становится не нужен. Ручная работа остаётся важной там, где нужно исследовать нестандартное поведение пользователя, проверить новый сценарий или оценить продукт глазами человека. Меняется момент, в который появляется контроль качества: он перестаёт быть последним этапом после разработки.
Что приходит на смену: автоматические тесты в CI/CD, Quality Engineering и ручное исследовательское тестирование там, где оно действительно даёт пользу.
3. Бизнес, разработка и эксплуатация как отдельные миры
В старой модели бизнес формулирует требования, разработчики пишут код, QA его проверяет, а эксплуатация получает готовый продукт. Пока изменений немного, такая цепочка работает. При высокой скорости разработки каждая передача между командами начинает стоить времени. Требования теряются или трактуются по-разному, задачи ждут согласования, а подразделения оптимизируют собственные показатели вместо общего результата.
Исследования DevOps показывают, что культура взаимодействия и общая ответственность команд заметно влияют на производительность.
DORA отдельно обращает внимание на этот эффект в контексте AI: искусственный интеллект сильнее помогает организациям, где процессы уже согласованы. В менее зрелой среде ускорение одного этапа может только сильнее проявить проблемы на остальных.
Например, разработчики начали быстрее писать код, но DevOps-команда по-прежнему выкатывает релизы вручную раз в две недели. Скорость бизнеса почти не меняется.
Что приходит на смену: кросс-функциональные команды, общие продуктовые цели и ответственность за весь путь изменения — от идеи до работы в продакшне.
4. Инфраструктура, которую настраивают вручную
Пока серверов и окружений мало, ручное управление может выглядеть вполне рабочим. Инженер запускает скрипт, меняет настройки, что-то докручивает руками. Если возникает проблема, все знают, кому написать. Но по мере роста системы таких ручных операций становится слишком много. Тестовая и продуктовая среды начинают отличаться друг от друга, часть изменений нигде не зафиксирована, а важные настройки существуют только в голове конкретного специалиста.
В современном DevOps-подходе инфраструктуру всё чаще описывают как код. Такая практика позволяет воспроизводить окружения и видеть историю изменений. Подход подробно описывает, например, Yandex Cloud.
Особенно критично это становится с ростом AI-нагрузки: ресурсов и конфигураций становится больше, а ошибка в инфраструктуре уже может привести не только к неудобству разработчиков, но и к простоям или потерям данных.
Что приходит на смену: Infrastructure as Code, автоматическое развёртывание, мониторинг и воспроизводимые окружения.
5. Техническое задание, которое нельзя менять
Большое подробное ТЗ долго воспринималось как способ снизить риски. Все договорились, что именно нужно сделать, зафиксировали объём работ и начинают разработку. Но для цифрового продукта есть проблема: пока команда реализует документ, реальность продолжает меняться. Пользователи иначе ведут себя в продукте. Появляются новые ограничения. Конкурент выпускает другой сценарий. Первая версия показывает, что часть первоначальных предположений была неверной. Если команда всё равно продолжает идти по документу, проект может быть отлично выполнен технически и бесполезен с точки зрения бизнеса.
В DORA 2025 акцент также смещается с формального выполнения плана на способность поставлять изменения и адаптироваться.
Это не значит, что ТЗ, сроки и бюджет больше не нужны. Устаревает идея, что требования после старта проекта нельзя пересматривать.
Что приходит на смену: продуктовые гипотезы, регулярная переприоритизация и короткий горизонт детального планирования.
6. Управление разработкой по количеству выполненных задач
Количество закрытых задач, коммитов или строк кода легко посчитать. Поэтому долгое время такие показатели использовали как удобный способ оценить загрузку команды. Но они почти ничего не говорят о результате для бизнеса. Разработчик может написать в два раза больше кода и одновременно создать в два раза больше сложности для поддержки. Команда может закрыть сто задач, но главная функция продукта всё равно выйдет позже запланированного срока.
С распространением AI проблема становится ещё заметнее: генерировать код теперь проще, поэтому само его количество всё хуже отражает производительность.
Современные инженерные организации всё чаще смотрят на сквозные показатели разработки. Исследования DevOps показывают рост интереса к системам метрик, которые позволяют видеть не активность отдельных специалистов, а узкие места процесса.
Например:
- сколько времени проходит от задачи до продакшна;
- как часто релизы вызывают проблемы;
- сколько занимает восстановление после инцидента;
- сколько изменений приходится переделывать;
- изменился ли после релиза продуктовый показатель.
Появляются и отдельные аналитические платформы, которые собирают данные из разных инженерных систем. В исследовательских работах отмечается, что такие инструменты помогают сокращать ручной сбор информации и быстрее находить проблемы в процессах.
Что приходит на смену: инженерная аналитика, DORA-метрики и оценка результата всего процесса вместо количества выполненных действий.
7. Набор отдельных инструментов без единого процесса
У современной ИТ-команды может быть десяток хороших инструментов. Задачи живут в одной системе, код — в другой, CI/CD — в третьей, мониторинг — в четвёртой, документация — в пятой. Проблема появляется, когда человеку приходится вручную соединять всё это в один процесс.
Например, руководитель хочет понять, почему релизы стали занимать больше времени. Чтобы ответить, команда отдельно выгружает данные по задачам, пул-реквестам, деплоям и инцидентам, а потом пытается сопоставить их вручную. Фрагментированная среда создаёт дублирование, потерю контекста и лишние согласования. Даже хорошая автоматизация отдельного инструмента не решает проблему, если между системами остаются ручные разрывы.
И AI может только увеличить количество таких сервисов: к существующему набору добавляется ещё несколько ассистентов, агентов и инструментов генерации.
Что приходит на смену: связанные между собой инженерные системы, сквозные процессы и единая аналитика вместо автоматизации каждого участка по отдельности.
С чего начинать изменения
Не нужно одновременно перестраивать всю разработку. Лучше найти место, где проблема уже заметна бизнесу. Если релиз занимает несколько месяцев — смотреть на путь изменения от идеи до продакшна. Если перед выпуском постоянно возникает очередь из задач на QA — автоматизировать проверки и пересматривать роль качества в команде. Если любое изменение инфраструктуры зависит от одного DevOps-инженера — уходить от ручных настроек. Если команда постоянно занята, но никто не понимает, почему продукт развивается медленно, — начинать с инженерной аналитики. Если компания купила AI-инструменты, а скорость почти не изменилась, прежде чем менять модель или покупать новую, полезно посмотреть на весь процесс вокруг неё.
Главный устаревший процесс — ускорять отдельные части системы
Можно в два раза быстрее писать код и столько же ждать согласования релиза. Можно автоматически генерировать тесты, но запускать их вручную в конце спринта. Можно выдать каждому разработчику AI-ассистента, но оставить пять уровней согласования любого изменения.
Поэтому в 2026 году устаревают не конкретные технологии вроде ручного тестирования или больших ТЗ сами по себе. Устаревает подход, при котором компания оптимизирует отдельные этапы, но не смотрит на весь путь изменения целиком. Именно это объясняет, почему новые технологии иногда не дают ожидаемого ускорения.
Конкурентное преимущество сегодня создаёт не само наличие AI, DevOps или облака, а способность бизнеса быстро превратить идею в работающий результат, получить обратную связь и изменить решение, если исходная гипотеза оказалась неверной.