От агентства к продуктовой команде с ИИ: верните контроль над поставкой

Почему эта передача застревает

Передача тормозит, когда агентство владеет не только кодом. Репозиторий может существовать, но настоящая карта продукта живёт в головах нескольких людей: какая ветка идёт в прод, какой сервис падает после перезапуска, какой фикс для клиента так и не попал в тикет-систему и какой обходной путь никто не хочет признавать, хотя он всё ещё в production.

Из-за этого зависимость появляется очень быстро. Новые сотрудники открывают репозиторий, читают короткий README и всё равно не могут ответить на базовые вопросы. Почему один сервис выкатывается первым? Что поменялось в конфиге в прошлом месяце? Почему команда пропустила тесты на этом пути? Кто-то когда-то принимал эти решения, но никто не вёл понятный журнал.

Обычно глубинная проблема — это не качество кода, а владение. Репозиторий висит на аккаунте агентства. Доступ к cloud идёт через почту подрядчика. CI jobs используют общий админ-логин. Компания платит за продукт, но не контролирует аккаунты, которые держат его в рабочем состоянии.

Один и тот же паттерн повторяется снова и снова:

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

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

ИИ становится полезным только после того, как команда контролирует базу: доступ к репозиторию, окружения, логи, credentials и понятный путь релиза. До этого он заполняет пробелы догадками. В черновике это терпимо. Когда в пятницу днём нужно срочно выпустить production-фикс, это уже очень дорого.

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

Что компания должна взять под контроль первым делом

Начните с того, что может заблокировать вас или положить продукт. Обычно это исходный контроль версий, cloud hosting, domain registrar, DNS, аккаунты магазинов приложений, аналитика, отслеживание ошибок, email delivery и платёжные системы. В каждом из этих сервисов у вашей компании должен быть самый высокий admin role.

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

Переносите владение в аккаунты компании, а не в личные почтовые ящики и не в billing profile агентства. Это касается хостинга кода, package registry, облачного биллинга, писем для оповещений, резервных копий, support inbox и каналов сообщений от клиентов.

Биллинг важнее, чем многие founders ожидают. Когда агентство оплачивает облако, сторонние инструменты или fees магазинов приложений, оно контролирует время. Одна неудачная карта, просроченная подписка или пропущенное fraud alert — и продукт уже под угрозой, пока ваша команда ждёт, когда кто-то другой среагирует.

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

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

Сначала возьмите под контроль аккаунты, денежный поток и inbox. Всё остальное после этого становится проще.

Составьте карту всех репозиториев, окружений и credentials

Нельзя вернуть delivery, если вы не знаете, что вообще существует. Многие команды думают, что продукт у них уже есть, когда получают доступ только к главному Git-репозиторию. А потом находят второй репозиторий для background jobs, приватный package registry, забытый staging server и deployment secrets, которые лежат в одном аккаунте агентства.

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

Смотрите шире, чем на основное приложение. Добавьте worker services, landing pages, внутренние admin tools, инфраструктурный код, мобильные приложения и даже старые ветки, которые всё ещё используются для hotfixes. Включите package registries, container registries, CI pipelines и все точки deployment — будь то VPS, AWS account, Kubernetes cluster или аккаунт магазина приложений.

Потом нанесите на карту живые системы вокруг кода. Запишите staging и production, а также базы данных, очереди, object storage, запланированные задачи, webhooks и мониторинг. Если никто не может сказать, где выполняются cron jobs, проверьте старые CI scripts и crontab на серверах. Маленькие задачи часто отвечают за счета, импорты или очистку. И они же часто тихо ломаются.

Проследите все secrets. Составьте список API keys, service accounts, SSH keys, доступа к DNS, токенов CDN, credentials платёжного провайдера и аккаунтов поставщиков моделей. Рядом с каждым пунктом отметьте, где он сейчас хранится: в password manager, переменных CI, cloud secret manager, локальном .env файле или на чьём-то ноутбуке.

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

Верните контроль над релизами внутрь команды

Передача становится настоящей только тогда, когда ваша команда может одобрить или остановить production deploy. До этого агентство по-прежнему контролирует самую важную часть.

Выберите двух или трёх конкретных людей внутри компании, которые могут одобрять релизы. Один человек — слишком хрупко. Десять человек — это хаос. Лучше всего работает небольшая группа: обычно product owner, engineer и один запасной.

Затем перенесите права на production deploy на этих людей в source control и CI/CD. Если агентство всё ещё выкатывает напрямую в production, поменяйте это как можно раньше. Оно может готовить релиз, но решать, когда он выходит, должна ваша команда.

Напишите один release checklist, которому новый инженер сможет следовать без поиска tribal knowledge. Сделайте его коротким и привяжите к реальным шагам, которые использует ваша команда. В большинстве команд там достаточно нескольких пунктов:

• что должно быть merged до релиза
• кто утверждает deploy
• какие smoke tests запускаются сразу после выката
• как работает rollback
• что смотреть в первые 30 минут

Rollback заслуживает такой же внимательности, как и deployment. Если план отката — это «спросить у агентства», значит, контроля над релизами у вас нет. Команда должна знать, какую версию вернуть, кто это делает, сколько времени это занимает и что почувствуют клиенты, если что-то пойдёт не так.

Smoke tests должны быть простыми. Могут ли пользователи войти? Могут ли они оплатить? Могут ли они завершить основное действие в продукте? Этот небольшой набор ловит очень многое.

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

На этом этапе держите доступ агентства узким. Пусть они отвечают на вопросы, поддерживают release и исправляют проблемы по запросу. Не позволяйте им утверждать релизы, менять scope в последний момент или выкатывать что-то самостоятельно. Эта граница важнее, чем кажется многим командам.

Проведите передачу за четыре недели

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

Неделя 1: проверьте всё

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

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

Неделя 2: посмотрите один реальный релиз

Пусть агентство проведёт релиз, а ваш внутренний лидер наблюдает за каждым шагом и записывает всё простыми словами. Если нужно, запишите звонок. Зафиксируйте и скучные детали: какие проверки идут первыми, кто утверждает production, как работает rollback и как команда понимает, что релиз прошёл нормально.

Если какой-то шаг нельзя объяснить ясно, считайте это незавершённой работой. Цель плана передачи знаний — не собрать файлы. Цель — сделать delivery повторяемым внутри вашей компании.

Неделя 3: проведите релиз сами

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

Неделя 4: работайте без страховки

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

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

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

Простой пример небольшой SaaS-команды

У небольшой SaaS-компании есть два founders, один in-house engineer и одно агентство, которое создало продукт. Основатели занимаются продажами и поддержкой. Инженер исправляет баги и отвечает на технические вопросы, но релизы по-прежнему контролирует агентство. На бумаге компания выглядит близкой к переходу на команду с ИИ. На практике она всё ещё зависит от внешних людей, чтобы безопасно что-то выпустить.

Слабые места проявляются быстро. Основные репозитории лежат в аккаунте, которым управляет агентство. Deploy keys находятся в личных логинах. Шаги релиза существуют только в сообщениях чата. Никто не написал notes по rollback, поэтому если релиз ломает биллинг или вход, команде приходится гадать, какую версию вернуть и в каком порядке.

Именно здесь компании стоит остановиться и привести всё в порядок. До следующего релиза она переносит каждый repo, secret и deployment permission в аккаунты компании. Основатели создают company Git organization, company cloud users и общий password vault. Инженер обновляет secrets, заменяет личные deploy keys и проверяет, что CI jobs по-прежнему работают. Агентство остаётся в процессе, но больше не держит единственный набор ключей.

Последовательность простая. Скопируйте репозитории с полной историей. Перенесите secrets в хранилище под управлением компании. Напишите один release checklist и один rollback checklist. Дайте внутреннему инженеру право выкатывать в staging и production. Попросите агентство проверить первый внутренний релиз, а не вести его.

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

После этих двух релизов роль агентства меняется. Оно может остаться на подхвате или на code review, но зависимость от подрядчика исчезает. Компания теперь владеет кодом, путём релиза и знаниями, которые нужны, чтобы продолжать выпускать продукт.

Ошибки, которые замедляют переход

Самые медленные передачи обычно ломаются по обычным причинам. Команда завершает контракт с агентством, а потом выясняет, что один Git-аккаунт, один облачный проект и одно production-оповещение всё ещё завязаны на логины агентства. Внешняя delivery остаётся под контролем намного дольше, чем это написано в документах.

Ещё одна частая ошибка — считать живую демонстрацию доказательством. Инженер агентства показывает deploy, перезапускает сервис или восстанавливает backup во время звонка. В моменте это выглядит нормально, но не помогает вашей команде в следующий вторник, когда никто уже не помнит точный порядок шагов. Вам нужны письменные runbooks с понятными действиями, названными владельцами и одним местом для credentials.

Команды также оставляют одного инженера агентства единственным admin «пока что». Это лишь смягчает ту же проблему. У вашей компании должно быть как минимум два внутренних admin для репозиториев, cloud, домена, CI/CD, мониторинга и биллинга. Если один человек заболеет или уйдёт, работа должна продолжаться.

Вот несколько проверок, которые ловят большинство проблем:

• проверьте каждый access point до даты окончания контракта
• вынесите secrets из тредов чата и разрозненных файлов в один vault, а потом обновите их
• дайте внутреннему человеку выпустить маленькое production-изменение без помощи агентства
• используйте ИИ осторожно, если старые документы неполные или неверные

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

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

Быстрые проверки перед завершением контракта

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

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

Проведите вторую проверку вокруг безопасности. Поменяйте один low-risk secret, например API key для staging integration или service account с ограниченной областью. Затем проверьте приложение, background jobs и мониторинг. Это помогает найти скрытые credentials в скриптах, старых CI jobs и забытых серверах.

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

Ещё сильнее помогает короткий обзор владения:

• кто владеет каждым repo, окружением, базой данных, доменом, внешним аккаунтом и CI pipeline
• кто может одобрять релизы и кто может их откатывать
• кто может восстановить данные из backup и кто уже проверял этот шаг
• кто получит первый алерт, если приложение упадёт в 2 часа ночи
• что первым замечают клиенты, если основное приложение останавливается, и что команда делает в первые 15 минут

Такая встреча должна занимать около 30 минут. Если владение понятно, ответы приходят быстро. Если никто не уверен, вы всё ещё зависите от подрядчика, даже если контракт говорит об обратном.

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

Что делать дальше небольшой команде с ИИ

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

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

Обычно лучше всего работает такое разделение:

• внутренняя команда владеет репозиториями, окружениями, CI/CD, релизами, инцидентами и приоритетами продукта
• внешние партнёры выполняют ограниченные задачи с узким доступом и понятными сроками
• внутренний владелец утверждает каждый merge в protected branches
• внутренний владелец может выпустить релиз, не ожидая подрядчика

Когда владение становится ясным, ИИ начинает помогать по-настоящему. Используйте его, чтобы писать тесты перед рискованным рефакторингом, проверять pull requests на очевидные пробелы и превращать изменения в коде в короткие документы, которые команда действительно прочитает. ИИ помогает больше всего после того, как вы исправили доступ и контроль над релизами. Если и это остаётся размытым, более быстрый output только маскирует ту же зависимость.

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

Этого хватает и для короткого monthly checklist:

• удалите старые аккаунты и старые vendor tokens
• проверьте backup и шаги rollback
• убедитесь, что документация всё ещё совпадает с текущей системой
• подтвердите, что on-call ownership остаётся внутри компании
• посмотрите, где ИИ сэкономил время, а где добавил шума

Если всё ещё ощущается как беспорядок, может помочь короткий внешний аудит. Oleg Sotnikov на oleg.is работает со стартапами и небольшими командами над передачей от fractional CTO, релизным потоком и практичной настройкой ИИ. Во многих случаях несколько прямых исправлений дают больше, чем ещё один месяц встреч по передаче.

Цель простая: ваша команда должна уметь выкатить маленькое изменение, посмотреть на него в production и исправить его в тот же день без просьбы о разрешении у кого-то снаружи.