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

Почему продукты, созданные агентствами, застревают после запуска

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

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

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

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

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

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

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

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

Что исправить до того, как трогать код

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

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

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

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

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

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

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

Возьмите релизы под контроль за неделю

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

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

Перезапуск за пять дней

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

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

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

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

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

Ужесточите доступ к продакшену

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

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

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

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

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

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

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

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

Напишите несколько архитектурных правил

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

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

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

Для многих команд достаточно короткого набора правил:

• Держите бизнес-правила в API или в одном общем сервисе, а не одновременно на экранах, в cron-задачах и в SQL.
• Логируйте каждый запрос с одинаковым набором полей, чтобы можно было проследить проблему от браузера до сервера.
• Храните секреты в одном утвержденном месте, а не в исходном коде и не в случайных env-файлах на ноутбуках.
• Используйте понятные названия для репозиториев, сервисов и окружений, чтобы любой мог отличить «client-app-prod» от «client-app-staging» без догадок.
• Проверяйте части, которые влияют на деньги, доступ или данные клиентов, перед каждым релизом.

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

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

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

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

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

Самое дешевое исправление — не переделка с нуля. Сначала владелец берет под контроль процесс.

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

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

Ничего сложного. Одной страницы достаточно.

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

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

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

Ошибки, которые сжигают время и деньги

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

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

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

Короткая проверка перед тем, как финансировать переделку

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

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

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

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

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

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

Что делать дальше, если нужна внешняя помощь

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

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

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

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

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

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