Передача MVP от агентства: верните контроль без переписывания

Почему MVP от агентства застревают

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

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

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

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

Быстрая проверка всё это проясняет:

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

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

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

Как выглядит контроль

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

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

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

Владение поддержкой — ещё одна чёткая граница. Обращения клиентов, оповещения о простоях, сообщения о безопасности и отчёты о сбоях должны сначала попадать к вашим людям. Если продакшн падает в 9:10 утра, ваш инженер или владелец продукта должен узнать об этом в 9:11, а не после цепочки сообщений через агентство.

Здоровая схема часто выглядит так:

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

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

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

Сначала составьте карту владения

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

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

Что включить в карту

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

• репозитории с исходным кодом и package registry
• облачные аккаунты, серверы, домены, DNS и SSL
• базы данных, хранилища, бэкапы и инструменты мониторинга
• почта, аналитика, support inbox и платёжные системы
• дизайн-файлы, аккаунты магазинов приложений и сторонние API

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

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

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

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

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

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

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

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

После этого перенесите системы, которые вашей команде нужны каждый день для разработки и эксплуатации продукта. Передайте репозиторий кода, платформу развёртывания, доступ к серверам, package registry и аккаунты CI/CD. Сначала добавьте внутренних администраторов, убедитесь, что они могут войти, и только потом уменьшайте права агентства.

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

Меняйте секреты после каждого переноса, а не в самом конце. Меняйте пароли, personal access token, SSH-ключи, API-ключи, секреты вебхуков и ключи для деплоя небольшими партиями. Если что-то сломается, вы сразу поймёте, какое изменение стало причиной.

Прежде чем удалить старый доступ, проверьте восстановление. Задайте простые вопросы и убедитесь в ответах:

• Кому придёт письмо для сброса пароля?
• У кого есть резервные коды MFA?
• Кто может назначить нового администратора?
• Сможет ли ваша команда выкатить релиз, если один человек будет офлайн?

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

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

Верните права на релизы

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

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

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

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

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

С каждым релизом храните эти четыре вещи:

• кто его одобрил
• что изменилось
• как его откатить
• где находится предыдущая стабильная версия

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

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

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

Передайте поддержку своей команде

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

Начните с переноса всех точек входа в поддержку в аккаунты, принадлежащие компании. Это включает общий почтовый ящик, help desk, чат, уведомления о статусе, а также любые телефонные или биллинговые почтовые ящики, связанные с продуктом. Измените и recovery email, и роли администраторов, и платёжные данные. Удивительно много команд пропускают эти мелочи и в итоге остаются без доступа, когда что-то ломается.

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

Хорошо работает простой раздел:

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

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

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

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

Назначьте конечную дату этого резервного периода. После неё агентство становится вариантом для эскалации, а не первой линией. Именно тогда ваша продуктовая команда начинает действовать как настоящий владелец.

Простой пример передачи

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

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

Первая неделя выглядит скучно на бумаге, но именно она важнее всего. Основатель переводит под компанию контроль над исходным кодом, оплатой облака, доступом к магазину приложений, аналитикой, отслеживанием ошибок и почтовыми аккаунтами. У агентства доступ остаётся, но только как у приглашённых пользователей, а не владельцев. Это маленькое изменение превращает «передачу MVP от агентства» из надежды в реальность.

Потом инженеры начинают брать на себя ежедневную работу.

• Неделя 1: компания получает владение над Git, хостингом, оплатой, аналитикой и инструментами поддержки.
• Неделя 2: внутренняя команда проводит релизы на staging и в продакшн, а агентство подключается к звонку ради подстраховки.
• Неделя 3: обращения клиентов сразу идут в команду стартапа, а агентство отвечает только тогда, когда баг находится в модуле, который оно знает лучше всего.
• Неделя 4: команда пишет базовые runbook, вводит чек-лист релиза и убирает доступ агентства, для которого уже нет понятной причины.

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

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

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

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

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

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

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

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

Команды снова и снова забывают про несколько активов:

• аккаунты магазинов приложений
• доступ к аналитике и Tag Manager
• контроль над регистратором домена и DNS
• отслеживание ошибок и оповещения о простоях
• support inbox и владение help desk

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

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

Быстрые проверки перед тем, как отходить от агентства

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

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

Проведите короткую проверку перед тем, как менять модель поддержки.

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

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

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

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

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

Следующие шаги для команды под руководством CTO

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

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

Практический 30-дневный план обычно выглядит так:

• Неделя 1: подтвердить админский доступ к коду, хостингу, доменам, аналитике, оплате и инструментам деплоя
• Неделя 2: перенести права на релизы и продакшн-учётные данные на аккаунты компании
• Неделя 3: передать поддержку, разбор багов и реагирование на инциденты вашей команде
• Неделя 4: задокументировать открытые риски, недостающие знания и всё, что всё ещё зависит от агентства

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

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

Fractional CTO, такой как Oleg Sotnikov, может помочь с этим аудитом и планом передачи. Его опыт охватывает продуктовую работу в стартапах, продакшн-инфраструктуру и lean AI-first инженерные процессы, поэтому он может оценить, где на самом деле скрыты риски передачи и что ваша команда может взять на себя уже сейчас. Для передачи MVP от агентства такой разбор часто спасает компанию от поспешного неправильного решения.

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