Первый технический найм после работы агентства: вернуть контроль

Почему передача выглядит сломанной

Первый сюрприз после работы агентства обычно не в коде. Он в владении.

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

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

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

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

Чем должен владеть первый сотрудник

Первая задача — не новая фича. Это контроль.

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

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

Четыре вопроса показывают большую часть рисков:

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

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

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

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

Начните с доступов, бэкапов и рисков

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

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

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

Быстрый обзор обычно выявляет слабые места: продакшен‑хостинг, DNS, кодовый репозиторий, путь деплоя, доступ к базе данных, бэкапы, аккаунты в магазинах приложений, доставка почты, платёжные системы, логи и оповещения. Основатели часто недооценивают доступ к аккаунтам магазинов приложений и платёжным системам, пока что‑то не ломается. Если один сотрудник агентства владеет Apple, Google, Stripe или аккаунтом почтовой рассылки — исправляйте это рано.

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

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

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

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

Составьте карту продукта, прежде чем менять код

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

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

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

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

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

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

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

Восстановите деплой без драмы

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

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

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

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

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

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

План восстановления на 30 дней

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

Лучший план прост:

• Дни 1–3: соберите все логины, контракты, счета, записи доменов, облачные аккаунты, репозитории, трекеры ошибок, аналитики и аккаунты магазинов приложений. Проверьте право собственности. Если агентство всё ещё контролирует продакшен, бэкапы или биллинг — отметьте это в первый день.
• Дни 4–10: составьте карту системы простым языком. Определите кодовую базу, хранилища данных, сервисы для почты, платежей, файлов и аутентификации, и правила для каждого окружения.
• Дни 11–20: превратите племенное знание в повторяемые процессы. Задокументируйте триаж поддержки, шаги деплоя, шаги отката и восстановление из бэкапа. Проведите одно сухое восстановление и один сухой деплой в безопасной среде.
• Дни 21–30: выпустите одно небольшое реальное исправление. Выберите что‑то с низким риском, пройдите ревью и релиз, посмотрите логи и подтвердите результат с основателем или командой поддержки.

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

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

Пример: SaaS с доступами агентства

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

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

Та же картина повторяется и в других местах. Stripe под личный логин. Аккаунт отправителя почты у бывшего подрядчика. Аналитика в чей‑то приватной Google‑учётке. Ничто полностью не сломано, но внутри компании нет настоящего владения.

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

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

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

Вот тогда владение начинает ощущаться реальным.

Ошибки, которые случайно создают переписывание

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

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

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

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

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

Быстрые проверки для основателя

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

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

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

Один «нет» не катастрофа. Три обычно указывают на проблему владения, а не на проблему с кодом.

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

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

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

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

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

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

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