Управление ИИ, когда пул-реквестов больше, чем релизов

Рост числа пул-реквестов при прежней частоте релизов говорит о заторе, а не о продуктивности. Инструменты программирования ускорили подготовку изменений, но продуктовые решения, ревью, тестовые среды, миграции, согласования и релизы не стали такими же быстрыми. Малый или средний бизнес может считать сгенерированный код и открытые пул-реквесты, радоваться результатам и при этом не доставлять клиентам ничего быстрее.

Такой разрыв еще не означает, что компании обязательно нужен внешний руководитель. Он означает, что нужно рассмотреть поставку продукта как единую систему, найти места ожидания и решить, способны ли нынешние руководители устранить ограничение. Внешнее управление ИИ оправдано, если данные показывают проблему на стыке команд, внутри нет владельца всего процесса или локальные исправления лишь перемещают очередь и не ускоряют релизы.

Рост числа пул-реквестов может скрывать падение поставки

Пул-реквест создает запас работы, который поступает в систему ревью и релизов. Релиз приносит результат клиенту или внутреннему пользователю. Смешивать эти события так же ошибочно, как считать готовой продукцией детали, которые поступили на сборочный участок, но еще не покинули завод.

Инструменты ИИ в первую очередь повышают скорость поступления работы. Инженер быстрее разбирается в незнакомом репозитории, пишет тесты, рефакторит повторяющийся код или готовит первую реализацию. Это полезно. Но на ревью приходит больше изменений, порой с более широкими диффами и слабым пониманием автора. Следующий человек все равно должен решить, нужно ли это изменение, охватывает ли оно неудобные случаи и сможет ли команда поддерживать его в продакшене.

В отчете DORA за 2025 год о генеративном ИИ в разработке ПО виден тот же разрыв. Более активное внедрение ИИ было связано с более высокой субъективной продуктивностью, состоянием потока, качеством кода и документации, а также со скоростью ревью и согласования. При этом авторы оценили влияние на пропускную способность поставки как небольшое отрицательное, а на стабильность поставки как более заметное отрицательное. DORA объясняет это нарушением базовой дисциплины, которую легко забыть при быстрой генерации кода: размер порций изменений должен оставаться небольшим. Эта оговорка полезнее очередного заявления о том, что помощник экономит время на наборе кода.

В малом бизнесе операционный симптом обычно очевиден. Число открытых пул-реквестов растет. Медианное время до первого ревью увеличивается. Инженеры тратят все больше дня на чтение чужих изменений. Код сливается рывками перед запланированным релизом, а сам релиз по-прежнему ждет человека, который понимает развертывание, миграцию клиента или рискованный модуль. Инструмент программирования не создал все узкие места. Он усилил нагрузку и сделал старые ограничения заметными.

Не вводите целевой показатель по числу пул-реквестов. Такой показатель поощряет авторов загружать очередь и наказывает людей, которые выполняют дефицитную работу по ревью и релизам. Если число влияет на оценку сотрудника, инженеры начнут дробить задачи ради видимой активности, не сокращая срок поставки клиенту, или станут открывать черновики до того, как изменение станет связным. Измеряйте выход работы из системы.

Одно изменение нужно проследить от решения до продакшена

Найти ограничение можно, если проследить небольшую выборку выпущенных и невыпущенных изменений по всему маршруту, сохранив время событий и конкретные причины ожидания. Данные репозитория начинаются слишком поздно, потому что задача может долго ждать уточнения продукта или дизайна до начала программирования. Они также заканчиваются слишком рано, если после слияния требуется отдельное решение о релизе.

Для каждого изменения фиксируйте такие события:

1. Продуктовое решение готово: условия приемки и владелец понятны.
2. Разработка началась: инженер приступил к реализации.
3. Пул-реквест открыт: появилась первая версия, готовая к ревью.
4. Ревью началось и завершилось одобрением: ревьюер внимательно изучил изменение, а затем принял его.
5. Изменение слито: обязательные проверки и правила ветки выполнены.

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

Небольшое сообщение о событии дает команде единый формат без покупки новой аналитической системы:

{"change_id":"BILL-184","event":"review_started","at":"2026-07-22T14:10:00Z","owner":"platform","wait_reason":"security_reviewer_unavailable"}

Собирайте события из трекера задач, репозитория, процесса развертывания или на коротком еженедельном разборе. Неточные ручные данные по 20 изменениям полезнее красивой панели, которая считает только коммиты. На выходе нужна строка для каждого изменения с активным временем, временем ожидания, текущей стадией и самой долгой причиной задержки. Простая таблица может показать, что реализация заняла шесть часов, ревью ждало три дня, а включение в продакшене заняло еще четыре.

Отслеживайте неудачи вместе с успешными релизами. Изменение, которое дошло до продакшена и было откачено, показывает участок, где поток был быстрым, но небезопасным. Закрытая без слияния задача может обнаружить неясное продуктовое решение, дублирование работы или сгенерированный код, за который никто из ревьюеров не захотел отвечать. Если исключить брошенные изменения, система поставки будет выглядеть здоровее, чем она есть.

Собирайте такие данные от двух до четырех недель, прежде чем делать организационный вывод. Один трудный релиз может оказаться исключением, а повторяющаяся очередь на одной и той же стадии уже дает основание для решения. Вам не нужна постоянная бюрократия измерений. Нужно достаточно наблюдений, чтобы понять, куда направить внимание руководства.

Каждая очередь указывает на свой сбой управления

Место ожидания показывает, какого решения не хватает. Фраза «нужно ускорить ревью» слишком расплывчата: задержку могут вызывать перегруженные эксперты, слишком крупные изменения, неясная ответственность, слабые автоматические проверки или работа, которая вообще не должна была дойти до реализации.

Если изменения ждут до начала программирования, продуктовый руководитель не подготовил задачу к работе. ИИ быстро генерирует варианты, поэтому неясный запрос порождает больше убедительных реализаций ошибочной идеи. Ищите переписанные условия приемки, повторно открытые задачи, конкурирующие пул-реквесты и вопросы, которые возникают только после того, как ревьюер увидел поведение продукта. Назначьте владельца продуктового решения и делите работу на меньшие части с наблюдаемым результатом.

Если изменения ждут первого ревью, команде не хватает мощности или владельцев областей. Считайте ревьюеров, а не только авторов. Если шесть инженеров могут открывать изменения, но один старший инженер должен одобрять решения по базе данных, безопасности и архитектуре, команда создала единственный сервер с неограниченной очередью. Явно назначьте владельцев областей, зарезервируйте время на ревью и перенесите типовые правила в автоматические проверки. Еще один автор или дополнительные лицензии на инструменты программирования только увеличат очередь.

Если циклы ревью повторяются, проверьте размер изменений и понимание автора. Сгенерированный ИИ код часто выглядит законченным до того, как автор проверил заложенные в него допущения. Тогда комментарии на ревью обнаруживают ошибки в поведении продукта, а не мелкие дефекты реализации. Требуйте от автора описать риск, подтверждение тестами, способ отката и измененные им сгенерированные части. Если объяснение расплывчато, пул-реквест не готов.

Если слитая работа ждет релиза, настройки репозитория не являются главной причиной. Компания может собирать изменения в еженедельный релизный поезд, не иметь безопасных шаблонов миграции, требовать согласования основателя для каждого выхода в продакшен или зависеть от ручной проверки, объем которой растет с каждым изменением. Измеряйте время от слияния до продакшена отдельно. Идеальная панель ревью может соседствовать с семидневной задержкой релиза.

Если релизы ломаются или откатываются, скорость выявила пробел в проверке и эксплуатации. Проверьте, тестируют ли проверки поведение, а не строки кода, похож ли стенд на продакшен в существенных деталях, можно ли безопасно остановить развертывание и видят ли инженеры эффект после релиза. Замедлять все программирование слишком грубо. Уменьшайте размер изменений и стройте процесс, который быстро отклоняет или отменяет плохой релиз.

Представьте изменение биллинга, которое добавляет кредиты для годового тарифа. За вторую половину дня агент готовит колонку базы данных, поле API, экран учетной записи и тесты. Автор открывает четыре пул-реквеста в трех репозиториях, потому что компания измеряет небольшие изменения и хочет проводить ревью параллельно. Каждое изменение по отдельности выглядит скромным.

Ревьюер базы данных одобряет схему, но не знает, что для существующих клиентов нужно заполнить старые записи. Ревьюер API видит новое поле, но считает, что интерфейс обработает пустое значение. Ревьюер интерфейса использует сгенерированные тестовые данные, где значение всегда заполнено. Все проверки проходят, потому что каждый репозиторий тестирует собственное допущение. Два изменения сливаются во вторник, остальные ждут единственного владельца биллинга, а операционная команда задерживает релиз в четверг, потому что никто не может сказать, безопасно ли частичное развертывание.

В пятницу команда сливает все изменения и вручную запускает заполнение данных. Задача блокирует строки настолько долго, что создание счетов замедляется, поэтому операционная команда останавливает ее и откатывает приложение. Панель показывает четыре открытых пул-реквеста, четыре слияния, быстрое ревью трех изменений и одно развертывание. Она не показывает, что в продуктовом решении не было правила миграции, изменения нельзя было выпускать независимо, а релиз отнял у двух старших инженеров почти весь день.

Правильный диагноз не звучит как «ревью работает медленно» или «код ИИ опасен». Команда разделила работу по репозиториям, а не по независимо выпускаемому поведению, и никто не отвечал за границу между состоянием продукта, миграцией данных и проверкой продакшена. Нужно назначить одного владельца релиза, отрепетировать заполнение на похожих данных, добавить явный тест отсутствующего кредита на границе API и выпускать поведение с управляемым включением. Следующее измерение должно показать, сократилось ли ожидание похожих изменений и стало ли меньше исправлений, а не сможет ли агент снова написать код за меньшее число минут.

Метрикам поставки нужны границы стадий и контекст бизнеса

Используйте небольшой набор метрик, который описывает движение, ожидание и отказы. Частота развертываний, срок прохождения изменения, время восстановления после неудачного развертывания, доля неудачных изменений и доля повторной работы после развертывания из DORA дают более подходящую основу, чем строки кода или число пул-реквестов. Они связывают инженерную активность с продакшеном. Малому бизнесу все равно нужны показатели отдельных стадий, чтобы найти ограничение внутри общего срока.

Еженедельно отслеживайте следующие показатели:

• Срок от готового продуктового решения до продакшена, с медианой и процентилем для старых задач в хвосте.
• Время ожидания на стадиях продукта, ревью, CI, согласования релиза и развертывания.
• Объем незавершенной работы на каждой стадии, включая черновики и слитые, но не выпущенные изменения.
• Частоту релизов и долю релизов, после которых потребовался откат, срочное исправление или немедленный ремонт.
• Распределение размеров пул-реквестов и число циклов ревью как диагностические показатели, а не цели.

Не объединяйте их в одну оценку разработчика. Человек может улучшить одну цифру, испортив другую, а поставка команды зависит от общей инфраструктуры и совместных решений. Ревьюер, который остановил небезопасный релиз, будет казаться медленным на наивной панели. Разработчик, открывающий много сгенерированных изменений, будет казаться продуктивным, хотя он увеличивает время ожидания для остальных.

Разделяйте данные достаточно подробно, чтобы не обвинить не ту систему. Не смешивайте обычные изменения приложения с миграциями базы данных, регулируемыми процессами, срочными исправлениями и большими продуктовыми ставками. Сначала сравнивайте один и тот же сервис во времени, а не инженеров между собой. Отмечайте запланированные заморозки и инциденты. Контекст не даст нормальному согласованию рискованной миграции исказить картину обычных изменений.

Измерение должно доходить до идентификатора релиза. Документация GitHub описывает проверки статуса как подтверждение того, что коммит соответствует условиям репозитория, а обязательные проверки могут блокировать слияние. Это полезно, но зеленый статус доказывает только то, что фактически выполнила проверка. GitHub также отмечает, что пропущенная задача может получить успешный статус. Зеленый блок слияния не доказывает, что существовали нужные тесты, развертывание в продакшен состоялось или клиенты получили функцию.

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

Сначала исправьте ответственность, потом добавляйте инструменты ИИ

Первое вмешательство должно уменьшить нагрузку на ограниченную стадию, а не ускорить генерацию кода. Многие команды поступают наоборот, потому что лицензии легко купить, а организационное решение вызывает неудобные разговоры. В результате растет запас работы, которая лишь кажется законченной.

На две недели задайте явные рабочие ограничения. Ограничьте число активных изменений на инженера, назначайте ревьюера до начала реализации для рискованных областей и держите пул-реквесты достаточно небольшими, чтобы ревьюер мог понять их за один подход. Ограничение не обязано стать постоянным законом. Оно останавливает подачу новой работы, пока команда проверяет, улучшился ли поток.

Назначьте по одному владельцу для каждой границы, где его сейчас нет: готово для продукта, готово для ревью, готово для релиза и проверено в продакшене. Владелец принимает решение или добивается его, но не обязан лично выполнять каждую задачу. Это различие устраняет привычную ситуацию, когда все смотрят на ожидающее релиза изменение, потому что за следующий переход никто не отвечает.

Автоматизируйте повторяющиеся решения только после согласования правила командой. Обязательные тесты, проверка форматирования, правила зависимостей, проверка миграций и контроль состояния развертывания могут снять с ревьюеров типовую работу. В документации очереди слияния GitHub сказано, что очередь проверяет изменения на последней версии целевой ветки с учетом изменений перед ними. В активном репозитории это может сократить лишнее обновление веток, но не решит, покрывает ли набор тестов риск для бизнеса. Настройка инструмента должна закреплять правило, а не подменять его.

Измените способ, которым инженеры используют агентов для программирования. До написания кода просите план и перечень затронутых границ, ограничивайте задачу одним наблюдаемым поведением и требуйте, чтобы автор прочитал весь дифф до открытия пул-реквеста. Сгенерированные тесты требуют такой же проверки, как сгенерированная реализация. Тест, который повторяет ошибочное допущение кода, создает уверенность без защиты.

Я сократил операционную команду с 25 человек до двух инженеров с поддержкой ИИ, сохранив объем выпуска и доступность системы. Инструменты программирования помогли, но больший эффект дали устранение передач работы, явная ответственность за продакшен и процесс поставки, который может поддерживать небольшая команда. Если скопировать список инструментов без изменения обязанностей, компания скопирует затраты, но не результат.

Сначала дайте шанс сильному внутреннему руководителю

Малому бизнесу не нужно внешнее управление ИИ, если нынешний инженерный или продуктовый руководитель отвечает за весь путь до релиза, может менять правила команды и располагает временем для целевого исправления. Поставьте перед ним понятный результат и дайте короткий срок, затем оценивайте систему релизов, а не презентацию.

Внутренняя работа должна дать четыре результата. Во-первых, базовые данные от готового продуктового решения до продакшена, включая неудачную и брошенную работу. Во-вторых, ранжированное ограничение, подтвержденное примерами со временем событий. В-третьих, одно или два изменения, направленных на это ограничение. В-четвертых, данные через две-четыре недели о том, изменились ли срок поставки, возраст очереди, частота релизов или объем исправлений.

Оставляйте работу внутри компании, если руководитель может выбирать компромиссы между продуктом, разработкой и эксплуатацией, не обращаясь к основателю за решением каждого спора. Внешний руководитель также не нужен, когда ограничение узкое и очевидное: сломанная задача CI, отсутствие владельца кода во время отпуска или забытый календарь релизов. Такие проблемы требуют ответственности и исполнения, а не новой руководящей роли.

Не нанимайте внешнего специалиста только потому, что команда спорит о выборе помощника для программирования. Инструмент можно заменить, а выбирать его следует по ограничениям системы поставки. Двухнедельная проверка на реальных задачах покажет, подходит ли он репозиторию, правилам безопасности и привычкам ревью. Управление становится проблемой, когда никто не может определить рабочую модель вокруг инструмента.

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

Повторяющиеся данные оправдывают внешнее управление ИИ

Привлекайте внешнего руководителя, когда ограничение пересекает функции, сохраняется после серьезной внутренней попытки и стоит дороже вмешательства. Данные должны объяснять решение основателю, который никогда не открывает репозиторий.

Убедительными будут такие данные:

• Пул-реквесты или слитые изменения несколько недель стареют на одной стадии с повторяющейся причиной ожидания.
• Расходы на инструменты ИИ и число предлагаемых изменений растут, а частота релизов в продакшен не меняется или падает.
• Один человек контролирует несколько путей согласования, а делегирование не сработало, потому что ответственность за области не описана.
• Неудачные релизы поглощают время на срочные исправления, откаты и работу поддержки, но команды по-прежнему оптимизируют выпуск кода.
• Продуктовая, инженерная и операционная команды по-разному понимают слово «готово», а за весь путь не отвечает ни один руководитель.

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

Переведите затраты в годовой диапазон с явными допущениями. Например, если повторяющаяся передача релиза дважды в месяц занимает восемь часов у двух инженеров, отдельно покажите часы и полную стоимость часа. Если в ремонте участвуют поддержка и продажи, добавьте их фактически затраченное время вместо общего коэффициента. При неполных данных используйте нижнюю и верхнюю оценку. Основатель сможет оспорить одно допущение, не отвергая весь диагноз.

Данным нужен и альтернативный вариант. Опишите, что компания поручит изменить внутреннему владельцу, когда команда проверит результат и при каком результате внешняя помощь не понадобится. Если команда за две недели уберет очередь согласования и релизы начнут двигаться, никого не нанимайте. Если очередь просто появится на проверке продакшена, трассировка обнаружила более широкую операционную проблему, а не опровергла потребность во внешней помощи.

Внешняя помощь уместна и тогда, когда нынешний руководитель способен решить проблему, но зажат внутри системы. Дробный CTO может изучить стимулы, права принятия решений, границы архитектуры, контроль релизов и состав команды, не защищая процесс, который создал эти проблемы. Независимость полезна лишь в том случае, если внешний руководитель может вместе с командой изменить рабочую модель. Отчет со списком инструментов, после которого все согласования остаются на месте, добавит в очередь еще один документ.

Есть и признаки, при которых нанимать не стоит. Избегайте кандидатов, которые начинают разговор с поставщика ИИ до измерения поставки, обещают сократить штат без разбора обязанностей или называют объем пул-реквестов доказательством результата. Спросите, при каких данных они не порекомендуют продолжать работу. Серьезный внешний руководитель способен определить условие выхода.

Team & AI Audit на oleg.is проводится за пять рабочих дней и стоит $5,000. Если аудит не находит экономию не менее $50,000 в год, плата не взимается. Такое предложение подходит основателю, которому нужен ограниченный по сроку диагноз до решения о дробном руководстве, но стандарт данных остается прежним: работа должна назвать конкретные ограничения, владельцев, экономику и план изменений.

Внешняя работа должна оставить действующую систему

Результатом должен стать измененный способ выпуска продукта с метриками, которые внутренняя команда продолжит использовать после ухода внешнего руководителя. Совет без внедрения дает временную ясность и постоянную зависимость.

Сформулируйте работу вокруг небольшого набора результатов:

1. Карта поставки с границами стадий, источниками данных, возрастом очередей и объемом исправлений после ошибок.
2. Карта прав принятия решений с именами тех, кто объявляет работу готовой, принимает риск, выпускает и проверяет продакшен.
3. Обновленный процесс работы с ИИ, где определены границы задач, обязанности автора, правила ревью и разрешенный доступ инструментов.
4. План устранения ограничения на 30 дней с владельцами, изменением мощности, автоматизацией и ожидаемым движением метрик.
5. Передача процесса внутреннему владельцу, который научится проводить разбор и менять правила.

Во время работы требуйте подтверждения внедрения. Один сервис должен пройти по обновленному пути до релиза. У одного повторяющегося ручного барьера должен появиться владелец, автоматическое правило или явное решение об удалении с принятием риска. Одна панель или еженедельная таблица должна связать готовность продукта с продакшеном. Команда должна уметь объяснить, почему после устранения нынешнего ограничения станет видно следующее.

Определите экономическую границу до начала работы. Короткого аудита может быть достаточно, если диагноз неясен. Дробное руководство имеет смысл, когда компании на несколько месяцев нужен человек, который проведет решения через разные функции, изменит состав команды или архитектуру и подготовит внутреннего преемника. Постоянный сотрудник нужен, если объем и полномочия сохранятся после преобразований. Не превращайте временное исправление поставки в бессрочную консультационную подписку по привычке.

Защитите команду от миграции инструментов под видом руководства. Замена одного помощника другим, добавление агентов или установка новой панели могут входить в работу, но каждое изменение должно быть прямо связано с измеренным ограничением. Если очередь возникла из-за плохого понимания кода на ревью, более быстрый генератор скорее ухудшит ситуацию. Если проверка развертывания выполняется вручную и медленно, помогут наблюдаемость и безопасная автоматизация.

Условие выхода должно измеряться: внутренний владелец проводит разбор поставки, ответственность за стадии понятна, релизный процесс работает без внешнего руководителя, а согласованные метрики устойчиво движутся в нужную сторону. Конкретная цель зависит от исходной точки. Обязанность определить и проверить ее остается всегда.

Следующую инвестицию должны определять данные о релизах

Следующая инвестиция в ИИ должна опираться на данные из продакшена, а не на восторг от экрана пул-реквеста. Оставляйте инструменты, которые сокращают активную работу и не увеличивают ожидание, переделку или отказы на следующих стадиях. Меняйте процесс вокруг инструментов, которые создают больше запаса, чем команда может безопасно выпустить.

На следующей встрече руководства сравните четыре линии за один период: открытые пул-реквесты, слитые изменения, релизы в продакшен и изменения, которые пришлось исправить или откатить. Рядом положите самые старые невыпущенные изменения с причинами ожидания. Если первая линия растет, а линия релизов остается ровной, перестаньте обсуждать скорость разработчиков. Назовите стадию, где копится работа, и человека, который может ее изменить.

Поручите первое исправление внутреннему руководителю, если он отвечает за весь путь и может действовать на его границах. Привлекайте внешнее управление ИИ, если повторные трассировки показывают межфункциональное ограничение, компания не может назначить действенного владельца или внутреннее исправление не сдвинуло поставку. Это бизнес-решение, подтвержденное возрастом очереди, поведением релизов, стоимостью отказов и правами принятия решений. Объем пул-реквестов лишь подсказал, где искать.