Прогнозы сроков поставки с AI, которые совпадают с реальностью ревью и тестов

Почему оценки выглядят быстрыми, а выпускаются медленно

Задача может казаться почти законченной в тот момент, когда AI-инструмент выдает рабочий черновик. Это первая разница. Написанный код — это еще не выпущенный код.

Команды часто чувствуют скорость в первый день, а потом теряют время на комментарии в ревью, неудачные проверки, переписывание и еще один круг согласований. Код уже существует, но команде все еще нужно доказать, что он готов для production.

AI меняет то, куда уходит время. Он может сильно сократить время на черновик. Фича, на которую раньше уходило два дня на набросок, может появиться за два часа. Но следующие этапы обычно почти не сокращаются. Старшие инженеры по-прежнему проверяют рискованные изменения. Тесты по-прежнему падают по странным причинам. Кто-то все равно решает, безопасен ли код, понятен ли он и стоит ли его мержить.

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

Пропавшее время обычно прячется в нескольких местах:

• очередь ревью, когда один или два человека одобряют почти все изменения
• flaky tests, которые падают без реальной проблемы в продукте
• retry churn, когда исправление ломает что-то еще или следующий черновик от AI создает новую работу для ревью
• проверки перед релизом, staging-проверки и cleanup, которые никогда не попадают в оценку

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

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

Где прячется дополнительное время

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

Большинство команд считают время сборки и написания кода. Они пропускают ожидание между этапами. Pull request может висеть четыре часа, прежде чем его кто-то откроет. Потом ревьюер просит изменения, автор обновляет код, и то же ревью начинается заново.

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

Flaky tests добавляют еще одну задержку. Падающая проверка, которая проходит со второго запуска, все равно съедает время. Кому-то нужно разобраться в сбое, решить, настоящий он или нет, перезапустить pipeline и ждать результата. Один нестабильный тест может превратить 15-минутную проверку в 40 минут реального времени, не изменив ни одной строки продуктового кода.

Та же картина повторяется и дальше по пути к production:

• CI jobs падают по причинам, которым никто не доверяет, поэтому их перезапускают
• деплой тайм-аутится и требует еще одной попытки
• этапы согласования стопорятся, потому что нужный человек занят
• маленькие замечания ревьюера запускают еще один commit и еще один полный pipeline

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

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

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

Как считать нагрузку на ревью

Время на ревью — это часть времени на выпуск. Команды часто не учитывают его, потому что в этот промежуток никто не пишет код, но работа все равно стоит.

С AI это становится еще заметнее, потому что первый черновик появляется очень быстро. Изменение может выглядеть как "готово" уже к обеду, а потом лежать в очереди pull request до следующего дня.

Начните не с памяти, а с последних PR. Посмотрите на 20–30 обычных изменений вашей команды. Пропустите редкие случаи вроде аварийных hotfix'ов, огромных переписываний или работы, которая зависла из-за отпусков.

Для каждого pull request отметьте четыре числа:

• время от открытия pull request до первого реального ревью
• число раундов ревью до одобрения
• время, потраченное на небольшие исправления после комментариев
• время, потраченное на более крупные изменения после замечаний по дизайну или архитектуре

Первое число важнее, чем многие ожидают. Если среднее ожидание до первого ревью — 18 часов, эта задержка должна быть в прогнозе, даже если само ревью занимает 12 минут.

Потом считайте раунды комментариев. Один раунд — обычное дело. Два — тоже нормально. Три и больше обычно означают, что что-то пропустили раньше или изменение слишком большое. Используйте среднее по недавним задачам, а не идеальную цель.

Держите мелкие исправления отдельно от более широких замечаний. Мелкие исправления — это, например, изменение имени, один забытый тест или быстрая рефакторинговая правка. Более широкие замечания могут просить другой подход, разбиение на части или изменение потока данных. Такие комментарии могут добавить полдня или несколько дней, поэтому их нельзя складывать в одну корзину.

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

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

Если цифры кажутся неожиданно высокими, скорее всего они ближе к правде, чем была первая оценка.

Как считать flaky tests и retry churn

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

Это потерянное время должно попасть в оценку. Если спрятать его внутри отчетов CI, работа на бумаге выглядит быстрее, чем ощущается для тех, кто ее выпускает.

Что измерять

Начните с одного простого правила: считайте сбои, которые происходят без изменений в коде. Если тот же commit падает, а потом проходит при повторном запуске, вы, скорее всего, нашли flaky test, а не баг в продукте.

Отслеживайте четыре числа для каждой команды каждую неделю:

• сколько pipeline потребовали хотя бы одного повторного запуска
• сколько всего повторных запусков сделала команда
• сколько времени обычно занимает один повторный запуск, включая ожидание
• сколько сбоев оказалось flaky, а не реальными дефектами

Держите flaky failures отдельно от реальных багов. Реальный баг требует поиска причины и изменения кода. Flaky test обычно требует повторных запусков, проверки логов и короткого обсуждения, можно ли безопасно игнорировать сбой. Это разные типы задержек.

Простой пример делает математику понятной. Допустим, команда запускает 40 pipeline в неделю. Двенадцать из них требуют повторного запуска. Всего команда делает 22 повторных запуска, и каждый из них стоит 9 минут между очередью, выполнением теста и проверкой результата. Это 198 минут, то есть больше 3 часов, которые исчезают еще до того, как кто-то начнет чинить настоящую проблему.

Включайте время на retry в фичу

Теперь верните это время обратно в планирование поставки. Если в спринте пять похожих фич, не прячьте эти 3 часа внутри общего числа CI. Разнесите стоимость повторных запусков по планируемой работе.

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

Это также помогает командам не чинить не то. Если время на повторные запуски продолжает расти, проблема не в "медленных разработчиках". Проблема в нестабильности тестов. Считайте ее отдельно, отделяйте от остального и включайте в стоимость работы, пока команда не уберет flaky tests.

Как собрать прогноз шаг за шагом

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

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

1. Запишите базовый объем задачи без помощи AI.
2. Оцените время на черновик с теми инструментами, которые команда использует сейчас, а не с теми, которые хотелось бы иметь.
3. Добавьте время на ревью из недавней истории команды, включая комментарии, доработки и повторные проходы.
4. Добавьте время на повторные запуски тестов, flaky failures, исправления и retry при деплое.
5. Зафиксируйте два результата: лучший сценарий и вероятный сценарий.

Шаг ревью важнее, чем многие признают. Если pull request обычно получает два раунда комментариев и ждет полдня, прежде чем его кто-то проверит, эта задержка должна попасть в прогноз. AI может быстро написать код, но он не заставит коллегу проверить его раньше и не сделает рискованное изменение легче для одобрения.

С тестовой нестабильностью нужно работать так же. Если CI часто падает по причинам, не связанным с изменением, учитывайте это трение. Команде, которая перезапускает тесты дважды на каждый merge и тратит 20 минут на проверку ложных падений, нужно добавлять это время каждый раз. То же касается retry при deploy, проверок rollback и небольших commit'ов после staging.

Хорошо работает простая формула: базовый объем, уменьшенное время на черновик, плюс время на ревью, плюс время на retry. Потом разбейте ее на две строки. Лучший сценарий предполагает быстрое ревью и стабильные тесты. Вероятный сценарий использует вашу обычную скорость ревью и обычную частоту сбоев.

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

Простой пример из обычного спринта

Небольшая фича часто выглядит дешево на бумаге. Допустим, команда добавляет одно изменение API, чтобы вернуть новое поле delivery_window, а затем делает небольшое обновление интерфейса, которое показывает это окно на странице заказа.

AI-инструмент для программирования может сделать первый черновик почти готовым. Он пишет обработчик API, обновляет схему, добавляет React-компонент и даже предлагает тесты примерно за 40 минут. После быстрой доработки разработчиком работа выглядит как задача на один день.

Примерная оценка на бумаге может быть такой: 3 часа на программирование, 1 час на тесты, 1 час на ревью и 1 час на merge и deploy. Итого 6 часов.

Потом появляется обычное трение команды.

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

Затем CI дважды падает на flaky browser test, который вообще не связан с фичей. Каждый повторный запуск занимает около 15 минут реального времени, плюс несколько минут на просмотр логов и решение, что это просто шум. Это примерно 40 минут retry churn, и ни одна из этих минут не двигает фичу вперед.

После второго ревью появляется еще одна проблема. На узком экране новый badge с доставкой переносится некрасиво и сдвигает кнопку вниз. Исправление занимает 30 минут, после чего команда снова запускает UI tests.

Теперь картина другая:

• AI-черновик и доработка: 1 час
• цикл ревью и переработки: 1 час 15 минут
• два повторных запуска из-за flaky tests: 40 минут
• небольшая доработка интерфейса: 30 минут
• финальный прогон тестов, merge, deploy: 1 час

Задача по-прежнему выглядела как работа на 6 часов. Но реальный путь до релиза занял ближе к 8 часам 25 минутам, и это при условии, что никто не переключался между задачами, пока ждал CI или ревью. Вот почему прогнозы должны считать нагрузку на ревью, влияние flaky tests и retry churn, а не только скорость создания черновика.

Ошибки, которые ломают прогноз

Плохие прогнозы обычно ломаются по простой причине: команды считают генерацию кода прогрессом, но не считают работу, которая идет следом. AI может выдать первый черновик за минуты. Ревью, исправления, повторные запуски тестов и cleanup по-прежнему занимают часы или дни.

Проблема становится еще больше, когда люди принимают вывод AI за готовую работу. Сгенерированный pull request может выглядеть готовым на 80 процентов, но последние 20 процентов часто содержат основную задержку. Один неясный запрос, один неверный edge case или одно замечание по безопасности могут снова отправить задачу в ревью.

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

Нестабильность тестов часто прячется внутри размытой категории "engineering overhead". Это скрывает реальную стоимость. Если набор тестов дважды в день падает случайно, команда тратит время на просмотр логов, повторные запуски и восстановление доверия к сигналу. Считайте влияние flaky tests отдельно, потому что оно ведет себя не так, как обычное время сборки.

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

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

Признаки обычно видны рано:

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

Обычный пример — фича на два дня, которую AI черновиком собирает за полдня. Потом команда тратит день на комментарии ревью, полдня на повторные запуски flaky tests и еще несколько часов на merge conflicts, потому что ветка слишком долго лежала без движения. На бумаге работа выглядела быстрее. В планировании production она заняла три дня, а не два.

Быстрая проверка перед тем, как обещать срок

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

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

Потом проверьте тестовый набор, который затронет эта задача. Не спрашивайте, обычно ли тесты проходят. Спросите про flake rate именно в этой части набора. Если API tests падают один раз из восьми без продуктовой причины, этот шум съест и время, и уверенность.

Короткий чеклист помогает:

• проверьте, кто может ревьюить изменение в этом спринте и сколько ревью он уже должен
• проверьте недавний flake rate для тех тестов, которые запустит эта работа
• проверьте, кто отвечает за повторные запуски, поиск по логам и cleanup после retry, когда тесты падают
• проверьте, затрагивает ли изменение рискованный код, например billing, auth, migrations или deploy scripts
• проверьте, помещается ли в спринт вероятный сценарий, а не только лучший

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

Рискованный код требует большего запаса. Изменение рядом с login, payments или infrastructure часто тянет за собой дополнительное ревью, ручные проверки и более осторожный rollout. Oleg Sotnikov часто подчеркивает этот момент, когда говорит об architecture software и delivery systems: стоимость обычно сидит не в коде как таковом, а в очереди вокруг него.

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

Что делать дальше

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

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

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

• исходная оценка
• количество раундов ревью на задачу
• неудачные запуски CI
• время на retry
• фактическая дата релиза

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

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

Если нужна помощь извне, держите ее практичной. Oleg Sotnikov делится таким подходом к AI-first engineering и Fractional CTO work на oleg.is, с сильным фокусом на delivery systems, infrastructure и automation, которые команды действительно могут использовать. Полезный результат очень прост: прогнозы, которые совпадают с реальной работой по выпуску, а не только со скоростью черновика.