Как составить бюджет перехода AI-команды

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

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

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

У параллельного запуска должна быть одна задача

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

Я разделяю три формата, которые компании часто смешивают:

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

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

Опишите границы одним абзацем. Например:

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

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

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

Оценивайте старую команду по защищенной емкости

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

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

Достаточно простой таблицы емкости:

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

Для каждой роли используйте формулу:

стоимость защищенной емкости за неделю = зарезервированные часы перехода × полная почасовая стоимость

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

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

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

Время ревью заслуживает отдельного центра затрат

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

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

Для начала используйте четыре категории:

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

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

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

Требуйте, чтобы каждый pull request с участием AI содержал короткий блок доказательств:

## Change evidence
- Ticket acceptance criteria covered: AC-1, AC-2, AC-3
- Tests added or changed: billing_discount_spec, checkout_api_spec
- Manual check performed: staging checkout with existing customer account
- Risky boundaries touched: none
- Rollback: revert commit; no data migration

Это не бюрократия ради бюрократии. Блок сокращает время, которое ревьюер тратит на поиск замысла, и делает пробелы заметными. Если доказательства постоянно отсутствуют, исправьте шаблон задачи или привычки команды. Не заставляйте ревьюеров бесконечно компенсировать этот недостаток.

Полезный недельный показатель - коэффициент ревью:

коэффициент ревью = общее время ревью / общее время реализации

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

Для расходов на инструменты нужны лимит и ответственный

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

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

Создайте строку бюджета для каждой категории инструментов:

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

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

Для агентов командной строки также ограничьте объем работы, который может выполнить автономный запуск. CLI Anthropic Claude Code документирует режим разрешений для планирования и параметр --max-turns для неинтерактивной работы. Эти ограничения не заменяют инженерное решение, но помогают не дать экспериментальной автоматизации бесконечно блуждать по задаче.

Например, используйте ограниченное задание для анализа репозитория, прежде чем разрешать изменения кода:

claude -p --max-turns 4 --permission-mode plan \\
  "Inspect the failing test output. Propose the smallest fix, list files that would change, and stop before editing."

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

Покрытие специалистами - это страховка, а не запоздалая мысль

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

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

• Продакшен-операции и право отката.
• Идентификация, разрешения, секреты и работа с данными клиентов.
• Миграция данных и правила хранения.
• Финансовая логика, регулируемое поведение и договорные обязательства.
• Основные архитектурные решения, затрагивающие несколько сервисов.

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

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

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

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

Составляйте прогноз понедельно

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

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

Рассчитывайте недельный итог по формуле:

стоимость параллельного запуска = защищенная емкость старой команды
                                  + труд новой команды
                                  + расходы на инструменты
                                  + резерв специалистов
                                  + резерв на инциденты

Затем посчитайте второе значение, которого руководство часто избегает, потому что оно требует честного сравнения:

стоимость принятого изменения в продакшене = стоимость параллельного запуска / принятые изменения в продакшене

Не используйте в знаменателе необработанные pull request, количество измененных строк, отправленные запросы или тикеты со статусом «готово». Считайте изменение только после того, как оно соответствует критериям приемки и достигает заранее определенного состояния в продакшене. Если класс работы включает feature flag или поэтапные релизы, определите это состояние до первой недели.

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

Каждую пятницу отслеживайте отклонения:

отклонение = фактическая стоимость недели - прогноз стоимости недели
процент отклонения = отклонение / прогноз стоимости недели

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

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

Провал может несколько недель выглядеть как продуктивность

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

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

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

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

Исправьте настройку и переклассифицируйте работу:

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

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

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

Критерии выхода нужно определить до первого эксперимента

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

Определите критерии в четырех группах:

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

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

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

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