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

Почему это становится срочным

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

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

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

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

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

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

Первый вопрос простой: если ночью что-то сломается, сможет ли ваша компания исправить это без разрешения?

Проверьте, кто контролирует аккаунты

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

Начните с простого списка всех сервисов, связанных с продуктом:

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

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

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

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

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

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

Проверьте, кто контролирует релизы

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

Нарисуйте реальный путь до продакшена, а не тот, который рассказывают на встречах. Команды часто говорят: «у нас CI/CD», но релиз всё ещё зависит от одного ноутбука агентства, одной открытой браузерной сессии или одного инженера с доступом в app store. Проверьте всю цепочку: репозиторий, сборочный раннер, registry контейнеров, аккаунт хостинга, DNS, аккаунт app store и любой ручной скрипт, который завершает процесс.

Запишите пять фактов:

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

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

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

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

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

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

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

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

Для каждого сценария задайте четыре прямых вопроса:

• Останавливает ли это выручку сегодня?
• Открывает ли это доступ к данным клиентов?
• Нарушает ли это обещание, данное в продажах или в контракте?
• Знает ли команда, кто отвечает за исправление?

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

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

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

Хорошее техническое лидерство ставит риски для клиентов выше споров о том, что «надо бы почистить». Когда команда снижает самые опасные риски, работа с качеством кода становится проще и логичнее.

Найдите скрытые зависимости

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

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

Короткая карта зависимостей обычно быстро показывает слабые места:

• репозитории, CI-задачи и доступы к деплою
• облачные аккаунты, карты для оплаты и платные плагины
• подрядчики, фрилансеры и внешние сервисы без конкретного владельца
• домены, SSL-сертификаты, бэкапы и алерты мониторинга

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

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

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

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

Используйте план на первую неделю

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

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

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

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

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

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

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

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

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

Вот тут и нужна senior-техническая помощь. Хороший CTO не начинает с спора о структуре папок или покрытии тестами. Сначала он убеждается, что компания может управлять собственным продуктом без разрешения.

Первые исправления довольно прямолинейны:

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

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

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

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

Ошибки, которые тормозят работу

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

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

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

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

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

Быстрая проверка по списку

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

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

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

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

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

Соберите ответы на одной странице. Запишите пробел, кто за него отвечает и дедлайн. Пишите прямо. Например: «нет root-доступа к AWS — CEO восстановить к пятнице» или «скрипт отката не тестировался — руководитель разработки проверить на staging завтра». Один владелец должен поддерживать эту страницу в актуальном состоянии, пока все пробелы не закроются.

Выберите следующий шаг

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

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

Попросите агентство дать письменный список передачи на этой неделе. Сделайте его простым:

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

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

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

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

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