Чек-лист передачи проекта от агентства перед переводом работы внутрь команды

Почему контроль агентства становится риском

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

Первая проблема — зависимость. Ваши люди не могут выпускать изменения без агентства. У одного разработчика из агентства может быть единственное право на выкладку в продакшн. У другого — единственный админ-доступ к GitHub, GitLab, облачному аккаунту, магазину приложений или DNS. В обычной работе это может казаться безобидным. В день релиза это способно за считаные минуты остановить продажи, поддержку и доверие клиентов.

Слабые места обычно прячутся в скучных деталях: забытое устройство для 2FA, почтовый ящик, привязанный к подрядчику, CI-секрет, который никто не записал, или сертификат сборки, лежащий на одном ноутбуке. Код может быть готов и просмотрен, но релиз все равно встанет.

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

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

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

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

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

Что вернуть в первую очередь

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

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

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

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

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

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

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

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

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

Составьте карту всех аккаунтов и согласований

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

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

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

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

Затем углубитесь в права. Формулировка «есть доступ» говорит очень мало. Вам нужно знать, кто может сливать изменения в основную ветку, выкатывать на staging, выкатывать в production, утверждать изменения инфраструктуры, публиковать мобильную сборку, менять секреты, менять DNS и откатывать неудачный релиз.

Именно здесь и проявляется скрытый риск. Репозиторий может числиться на вашу компанию, но контроль над релизами все еще может оставаться у одного инженера агентства через deployment token, согласование в магазине приложений или правило защищенной ветки. Если этого человека нет, ваша команда ждет.

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

Затем наведите порядок в путях согласования. Уберите личные аккаунты из списков обязательных согласующих, из approvals на production deploy и из шагов аварийного отката. При необходимости оставьте агентство в коротком периоде параллельной работы, но финальное «да» должно принадлежать компании.

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

Передавайте контроль в правильном порядке

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

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

1. Сначала перенесите владение репозиториями в корпоративные аккаунты. Основной Git-провайдер, админ-доступ, правила защиты веток и резервный доступ должны быть у людей, которым платит ваша компания. Агентство пока оставьте в репозитории, но как участников, а не владельцев.
2. Соберите и обновите все секреты. API-ключи, облачные токены, сертификаты подписи, пароли для выкладки и webhook secret'ы должны оказаться в одном корпоративном vault'е. Не оставляйте production-учетные данные в ноутбуках агентства, чатах или личных менеджерах паролей.
3. Перестройте путь релиза под своим контролем. Ваша команда должна владеть job'ами сборки, реестром пакетов, доступом к магазину приложений, правами на выкладку в облако и шагами отката. Если релизы все еще проходят через аккаунт агентства, вы ими еще не управляете.
4. Проверьте права в реальной жизни. Попросите команду войти в систему, запустить тестовую сборку, посмотреть логи, утвердить выкладку и сделать откат в staging. Это звучит просто, но так вы поймаете недостающий доступ до того, как он заблокирует живое исправление.
5. Выпустите одно небольшое изменение в production под наблюдением вашей команды. Выберите безопасное обновление, например текст, флажок-функцию или маленькое исправление бага. Пусть агентство при необходимости наблюдает, но кнопки и шаги должны нажимать ваши люди.

После первого релиза убирайте доступ поэтапно, а не сразу весь. Сначала снимите права на production deploy и доступ к секретам, потом сократите админ-роли в системах контроля версий, облаке, мониторинге и сторонних инструментах. Оставьте короткое окно параллельной работы для вопросов, с назначенным контактным лицом и письменным сроком ответа.

Сейчас же — правильный момент, чтобы записать порядок релиза простым языком. Runbook должен подсказывать уставшему сотруднику, что делать в 7:00 утра во время сбоя. Он не должен звучать как внутренний маркетинг. Держите его коротким: где лежит код, кто утверждает релиз, как выкатывать, как откатывать и где смотреть логи.

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

Пишите runbook'и, которыми люди реально будут пользоваться

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

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

Добавьте рядом с каждым шагом время. Людям нужно понимать, занимает ли выкладка обычно 8 минут или 25, и должен ли откат занимать 3 минуты. Это убирает панику, когда job работает дольше ожидаемого.

Что включить

В каждом runbook'е должны быть несколько простых проверок, которые подтверждают, что система здорова. Делайте их измеримыми. Хорошие примеры: главная страница открывается, вход работает, health check API возвращает 200, уровень ошибок в течение 10 минут остается около обычного, размер очереди не продолжает расти, а последний тег релиза совпадает с версией в production.

Затем скажите людям, где искать подтверждение. Не пишите «проверьте логи». Напишите, где лежат логи, какую панель открыть, какой канал оповещений отслеживать и как выглядит нормальное состояние. Если ваша команда использует Grafana, Sentry, Prometheus или Loki, укажите точную панель, проект или запрос.

Названия быстро устаревают. «Prod server» и «main dashboard» — недостаточно. Используйте реальные названия систем и обновляйте команды каждый раз, когда агентство или внутренняя команда меняет инструменты.

Проверьте это на человеке, который не писал документ

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

Небольшой пример показывает разницу. «Запусти production deploy» — это слишком размыто. «Выкати api-service v2.14.3 в пайплайне GitLab release-prod, подожди завершения migration job, убедись, что /health возвращает 200, а потом смотри на панель 5xx в течение 10 минут» — это уже рабочая инструкция.

Если вы планируете перевести разработку внутрь команды, воспринимайте runbook'и как рабочий инструмент, а не как бумагу для передачи. Когда один человек вне агентства может выкатить hotfix и откатить его без просьб о помощи, runbook готов.

Как выглядит чистая передача

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

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

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

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

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

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

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

Ошибки, из-за которых все затягивается

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

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

Следующая волна задержек появляется из-за размытых записей. «Вызывается из CI» — это не runbook. «Конфиг лежит в облачной консоли» — тоже нет. Вашей команде нужны точные шаги, названия аккаунтов, точки согласования и порядок действий. Если человек не может следовать этим записям в обычный рабочий день, он не справится с ними и во время сбоя.

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

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

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

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

Проверки перед тем, как сокращать объем работ агентства

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

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

Используйте короткий чек-лист перед изменением контрактов:

• Ваша команда может выпустить релиз без просьб к агентству о доступе, согласовании или недостающем контексте.
• Один админ-аккаунт, принадлежащий компании, может попасть во все важные системы, включая репозитории, CI/CD, хостинг, домены, магазины приложений и мониторинг.
• Ваша команда может сегодня же обновить секреты и понимает, что сломается, что нужно перезапустить и кто проверяет результат.
• Кто-то может откатить последний релиз меньше чем за час по письменным инструкциям.
• Новый инженер может следовать runbook'у и завершить релиз без живой помощи агентства.

Именно эту последнюю проверку большинство команд пропускает. Она быстро выявляет расплывчатую документацию. Если в runbook'е написано что-то общее вроде «выкатывай из CI» или «проверь логи», он еще не готов.

Как использовать ИИ после возвращения контроля

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

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

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

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

Перед тем как сокращать объем работ агентства, внешняя проверка может помочь увидеть, чего еще не хватает. Fractional CTO обычно быстро находит слабые места в владении репозиториями, правах на релизы, доступе к окружениям и runbook'ах, которыми ваша команда действительно будет пользоваться. Такая проверка часто обходится дешевле, чем исправление одной плохой передачи.

Если вам нужна именно такая практическая проверка, Oleg Sotnikov на oleg.is работает со стартапами и небольшими командами в формате Fractional CTO, инфраструктуры и AI-assisted development workflows. Полезная часть тут не в теории — а в том, чтобы убедиться, что ваша команда действительно может выпускать продукт, восстанавливаться после сбоев и сохранять контроль после передачи.