Стартап, доставшийся от агентства: чек-лист ментора

Почему такие передачи часто идут не так

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

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

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

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

Первый серьёзный инцидент обычно и показывает все пробелы:

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

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

Что собрать в первую очередь

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

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

Начните с активов, которые могут остановить бизнес: репозитории исходного кода, хостинг, DNS, доступ к регистратору домена, корпоративная почта, инструменты CI/CD, аккаунты в магазинах приложений, системы аналитики, биллинг и отслеживание ошибок. Храните в одном месте последний контракт, statement of work, roadmap, открытые баги и отзывы клиентов.

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

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

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

Сначала проверьте владение кодом

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

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

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

Быстрая проверка владения должна включать:

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

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

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

Проверьте доступ к деплою

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

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

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

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

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

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

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

Сделайте архитектуру понятной

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

Используйте реальную продакшен-настройку, а не версию, которую люди хотели бы собрать. Вынесите на страницу все движущиеся части и подпишите их точными названиями, которые команда увидит в коде, облачных панелях и счетах. Укажите каждое приложение или сервис в продакшене, все базы данных, cache, очереди, worker'ы и cron-задачи, внешних поставщиков для логина, почты, биллинга, хранения, аналитики и алертов, а также место, где лежат секреты, пользовательские файлы, логи и бэкапы.

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

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

Карта на одной странице не сделает систему лучше за ночь. Но она сделает риски очевидными, а в этом и смысл.

Напишите операционные документы

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

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

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

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

Держите процедуру hotfix короткой. Подтвердите серьёзность проблемы. Проверьте логи. Назначьте одного человека на исправление. Прогоните smoke test. Запишите шаг отката. Опубликуйте изменение. Две понятные страницы лучше, чем десять, которые никто не читает.

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

Небольшой пример

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

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

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

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

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

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

Проверьте первую неделю

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

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

День 2 — деплой в staging. Сделайте одно маленькое изменение, отправьте его, посмотрите сборку и убедитесь, что команда может откатить его без помощи агентства.

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

День 4 — документация. Напишите недостающие страницы runbook'а для шагов деплоя, отката, хранения секретов, проверки бэкапов и первой реакции на частые сбои.

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

Здесь помогает простой тест. Если не приходит письмо для сброса пароля, может ли команда понять, в чём проблема: в приложении, очереди, почтовом провайдере или DNS? Если нет, передача всё ещё неполная.

Ошибки, которые делают передачу ещё сложнее

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

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

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

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

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

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

Относитесь к отсутствующей документации как к операционному риску, а не как к бумажной работе.

Короткая проверка перед изменениями в продакшене

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

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

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

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

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

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

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

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

Затем используйте простой 30-дневный план. Первую неделю посвятите доступам и ротации секретов. Вторую — шагам деплоя и проверке отката. Третью — документации системы и чистке runbook'ов. Четвёртую — кодовым горячим точкам, мёртвым сервисам и расходам, которые не имеют смысла.

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

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