Границы между CTO и внешним агентством для растущих команд

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

Агентство может двигаться быстро, когда один человек дает четкое «да». Во многих стартапах этим человеком становится основатель, потому что он ближе к клиентам и хочет ответы прямо сейчас. Агентствам такая схема нравится, потому что не нужно ждать.\n\nНа первой неделе эта скорость кажется полезной. Через месяц она начинает создавать проблемы.\n\nКогда основатель просит агентство «просто решить» мелкие детали продукта, таких решений накапливается слишком много. Подпись на кнопке — мелочь. А вот правило выставления счетов, модель прав доступа или упрощение отчетности — уже нет. Вскоре агентство начинает принимать продуктовые компромиссы, а не просто выполнять задачи, и CTO узнает об этом уже после того, как код повлиял на сам продукт.\n\nИменно так чаще всего ломаются границы между CTO и внешним агентством. CTO по-прежнему отвечает за архитектуру, надежность, безопасность и долгосрочные затраты. Но агентство уже могло выбрать библиотеки, потоки данных, привычки релизов и скрытые допущения. CTO получает систему, которую не выбирал, и все равно оказывается виноватым, если что-то ломается.\n\nДавление сроков только усиливает проблему. Близится дедлайн для продаж, инвесторы ждут видимого прогресса, или клиент просит еще одно изменение. Люди перестают спрашивать, кто это утверждает, и начинают спрашивать, можно ли выкатить сегодня. Если правила релиза не были определены заранее, агентство может отправить код, основатель — одобрить, а CTO увидит все уже после пользователей.\n\nЗдесь снова и снова повторяются несколько типичных сценариев:\n\n- основатель отвечает на продуктовые вопросы в чате, и никто не фиксирует компромисс\n- агентство сливает код, который меняет модель данных или правила доступа\n- CTO подключается поздно и вынужден откатывать решения в условиях дедлайна\n- все думают, что кто-то другой проверил безопасность, мониторинг или план отката\n\nЭто не значит, что агентство сделало что-то неправильно. Агентства просто реагируют на ту схему, которую вы им даете. Если вы поощряете скорость и размытое владение, они будут заполнять пустоты сами. У большинства команд проблема не в людях. Проблема в распределении полномочий.\n\nКто-то внутри компании должен иметь право сказать «да», право сказать «нет» и право остановить запуск. Если эти права каждую неделю переходят от одного человека к другому, споры почти неизбежны.\n\n## Что остается внутри компании у CTO\n\nЕсли агентство пишет большую часть кода, CTO все равно отвечает за те решения, которые могут позже навредить бизнесу. Четкие границы между CTO и внешним агентством начинаются с простого правила: компания оставляет у себя карту, ключи и финальное решение по релизу.\n\nCTO сохраняет архитектуру системы внутри компании, потому что это решение живет дольше, чем любой контракт с агентством. Внешняя команда может предложить стек, разбиение на сервисы или временный обходной путь, но именно CTO определяет долгосрочное направление. Это влияет на найм, расходы на облако, безопасность и на то, насколько болезненным будет следующий рефакторинг.\n\nCTO также оставляет у себя утверждение релизов. Ваша команда должна решить, кто может выкладывать в production, что должно пройти перед релизом, когда нужно поставить изменения на паузу и кто может быстро откатить выпуск, если что-то сломалось. Если агентство может само отправлять код в прод, компания не контролирует бизнес-риски.\n\nПродуктовые компромиссы тоже остаются внутри компании, если они меняют затраты, риски или roadmap. Агентство может выбирать самый быстрый путь к сдаче. CTO же должен учитывать более широкий набор издержек: рост ежемесячных расходов на инфраструктуру, зависимость от поставщика, нагрузку на поддержку, сдвиг сроков по другим задачам и дополнительную работу по исправлению через полгода.\n\nНекоторые контрольные точки должны оставаться у компании с первого дня:\n\n- владение облачными аккаунтами, доступом к production и исходным кодом\n- финальное утверждение релизов и правила отката\n- минимальные требования к тестам, логам и оповещениям\n- контроль над секретами, резервными копиями и живыми данными\n\nЭто не мелочи. Именно они определяют, кто отвечает, когда что-то ломается в 2 часа ночи. И именно они показывают, сможете ли вы потом сменить агентство без хаоса.\n\nТакой подход не замедляет сильное агентство. Он просто дает ему понятную зону ответственности. Команда пишет код, оценивает задачи и выпускает продукт в рамках правил, которые принадлежат вашей компании.\n\nДля небольших команд fractional CTO может выстроить эти правила без найма дорогого штатного руководителя. Часто этого достаточно, чтобы защитить архитектуру, доступ к production и продуктовые решения, пока внешняя команда берет на себя большую часть разработки.\n\n## Что агентство делает каждый день\n\nВнешняя команда должна отвечать за поставку, а не за продуктовую власть. Как только объем спринта записан, агентство должно превращать его в работающий софт без необходимости спрашивать одобрения на каждую мелочь. Оно планирует работу, выбирает порядок задач и двигает разработку вперед.\n\nВ рамках согласованных границ агентство может выбирать детали реализации. Оно решает, как лучше построить функцию, куда поместить правило проверки или как написать тесты. Но оно не должно самостоятельно менять архитектуру, сроки релиза, продуктовые компромиссы или правила работы с данными.\n\nХорошее агентство также разбивает общие запросы на реальные задачи. Если в тикете написано «добавить приглашения в команду», оно должно разложить это на работу с API, состояния интерфейса, письмо на email, крайние случаи и тесты. Вам не нужно разбирать каждую историю за него.\n\nЕженедельный ритм работы должен выглядеть так:\n\n- работать по письменному объему задач и плану спринта\n- превращать функции в понятные задачи с владельцами и оценками\n- давать короткие обновления и быстро отмечать блокеры\n- отправлять pull request с подтверждением тестов, заметками и всем, что внутренней команде нужно проверить\n- задавать вопросы заранее, если требования выглядят размыто или рискованно\n\nПоследний пункт важнее, чем многие готовы признать. Агентства попадают в неприятности, когда начинают гадать. Один короткий вопрос на второй день дешевле, чем переписывание на десятый.\n\nPull request — это часть работы, а не формальность. Каждый из них должен показывать, что изменилось, как команда это протестировала и что компании нужно знать до слияния или релиза. Хорошие заметки по передаче экономят время внутреннему инженеру или CTO, который будет проверять работу позже.\n\nПростой пример делает разделение понятнее. Допустим, компания просит новую страницу для выставления счетов. Агентство может решить, как собрать форму, как проверить поля и как покрыть сценарий тестами. Но если работа предполагает другой способ списания денег, перенос релиза или изменение того, как данные по биллингу проходят через систему, агентство должно остановиться и спросить.\n\nКогда эта граница ясна, агентства обычно работают лучше. Они быстро двигаются там, где действительно отвечают за результат, а компания сохраняет контроль над решениями, которые формируют продукт.\n\n## Как провести границу с самого начала\n\nЕсли вы нанимаете агентство и ждете до второго спринта, чтобы установить правила, вы сами зовете споры. Первая неделя должна закончиться коротким письменным списком решений, а не только бэклогом и контрактом.\n\nЭтот документ не должен быть юридическим. Одной страницы часто достаточно. В нем нужно указать, какие решения остаются внутри компании, какие агентство может принимать самостоятельно, а какие требуют быстрого согласования до начала разработки. Именно так границы между CTO и внешним агентством остаются понятными, когда внешняя команда работает быстро.\n\n### Назначьте людей на конкретные решения\n\nНачните с одного внутреннего человека, который отвечает за архитектурные вопросы. Не комитет. Когда агентство спрашивает, можно ли изменить структуру базы данных, заменить сервис или пойти на упрощение, отвечает один человек. Если у вас нет штатного CTO, fractional CTO для стартапов может взять эту роль на себя и удерживать направление продукта стабильным.\n\nЗатем запишите права на утверждение простыми словами. Оставьте права на релиз внутри компании. Оставьте внутри компании и владение продуктовыми компромиссами. Агентство может предлагать варианты, оценивать объем работ и отмечать риски, но ваша команда должна утверждать:\n- решения по дизайну, которые влияют на продукт дольше, чем один спринт\n- релизы в production\n- изменения объема работ, которые меняют бюджет, сроки или пользовательский опыт\n- исключения из стандартов программирования или правил безопасности\n\nНе оставляйте сроки ответа размытыми. Если агентство ждет ответа три дня, оно либо остановится, либо начнет гадать. Простое правило вроде «на архитектурные вопросы отвечаем в течение одного рабочего дня» сильно снижает трение.\n\nЕженедельный обзор помогает лучше, чем длинные чаты. Используйте его, чтобы снять открытые компромиссы, принять застрявшие решения и закрыть риски, которые агентство подняло в течение недели. Не устраивайте театр статусов. Десять честных минут по нерешенным вопросам могут сэкономить дни переделок.\n\nВсе исключения фиксируйте в общем письменном журнале. Если команда выкатила временное решение, отложила тест или согласилась на дополнительный технический долг ради даты, запишите, кто это утвердил, почему и когда команда вернется к этому вопросу. Память становится очень избирательной, когда сроки начинают давить.\n\nНебольшой пример: агентство хочет быстрее запустить оплату, временно обойдя внутренний сервис расчета цен только для одного релиза. Это может быть разумным упрощением. Внутренний владелец решает, подходит ли это архитектуре, владелец продукта — стоит ли пользовательская польза такого долга, а агентство реализует утвержденный путь. Три роли, одна запись, никаких догадок.\n\n## Кто за что отвечает\nКоманды работают быстрее, когда права на решения определены до скучного просто. Если никто не назначил владельца, агентство начинает принимать продуктовые решения, продуктовый менеджер — архитектурные, а CTO в итоге расхлебывает оба направления.\n\nХорошие границы между CTO и внешним агентством разделяют полномочия, а не трудозатраты. Агентство может писать большую часть кода. Но это не значит, что оно должно выбирать стек, переделывать модель данных или ослаблять правила безопасности ради сроков.\n\nCTO должен сохранять контроль над техническими решениями, которые потом создают длинную работу по исправлению. Сюда входят смена стека, изменения базы данных и схемы, схема хостинга, правила доступа, работа с секретами и все, что влияет на надежность или соответствие требованиям. Если агентство хочет заменить PostgreSQL, добавить новую очередь или изменить способ входа пользователей, решение принимает CTO.\n\nПродуктовый лидер отвечает за продуктовую сторону. Именно он решает пользовательские сценарии, сокращение объема, цели релиза и то, что выйдет сейчас, а что позже. Агентство может предложить более простой сценарий или сказать, что функция займет больше времени, чем планировалось. Но окончательное решение о том, что увидит пользователь и что может подождать, остается за продуктовым лидером.\n\nАгентство не должно вести себя как просто пара рук. Оно должно приносить варианты. Для каждого варианта просите три вещи простыми словами: стоимость, время и риск. Так управление софтверным агентством остается практичным. Вам не нужна презентация. Вам нужен понятный компромисс.\n\nКогда деньги или сроки меняют план, окончательное решение принимает основатель. Обычно это происходит, когда CTO хочет более безопасный путь, продуктовый лидер — более быстрый, а бюджет позволяет только один вариант.\n\nЗапишите красные линии. Сделайте их короткими и заметными:\n\n- утверждение выкладки в production\n- подключение новых поставщиков\n- изменения схемы и миграций\n- правила аутентификации, прав доступа и безопасности\n- решение о том, запускать релиз или нет\n\nНебольшой пример все упрощает. Агентство говорит: «Мы успеем к пятнице, если пропустим audit logs и изменим модель данных». Продуктовый лидер может убрать отчет из релиза. CTO решает вопрос с моделью данных и audit logs. Если это увеличивает стоимость, основатель решает, по-прежнему ли пятница так важна. Если у вас работает fractional CTO для стартапов, такое разделение особенно полезно, потому что внешние команды часто торопятся и по умолчанию считают, что обладают властью, если вы это явно не определили.\n\n## Простой пример\n\nПредставьте стартап с шестью сотрудниками. Он нанимает агентство, чтобы собрать клиентский портал, потому что команде нужен рабочий продукт за восемь недель, а не за восемь месяцев.\n\nСначала агентство просит использовать новый фреймворк, с которым уже хорошо знакомо. Оно говорит, что так сможет работать быстрее и переиспользовать часть прошлых решений. Это звучит разумно, пока CTO не начинает думать о том, кто будет поддерживать портал после запуска.\n\nУ компании уже есть инженеры, привычки поддержки и планы найма, выстроенные вокруг текущего стека. Если агентство добавит новый фреймворк, любые исправления станут сложнее, новых сотрудников придется дольше обучать, а мелкие изменения могут снова и снова возвращаться к агентству. CTO сохраняет текущий стек, даже если из-за этого разработка идет чуть медленнее.\n\nПри этом агентство все равно отвечает за многое. Оно пишет большую часть кода, разбивает работу на задачи и предлагает лучшие способы реализации экранов и сценариев. Но компания оставляет за собой архитектурные решения, правила развертывания и доступ к production.\n\nВ середине проекта сроки начинают сдвигаться. Продуктовый лидер смотрит на бэклог и убирает из первого релиза одну отчетную функцию. Клиенты по-прежнему смогут входить в систему, управлять аккаунтами и пользоваться основными возможностями портала. Отчеты могут подождать версии два.\n\nАгентству это может не понравиться, особенно если функция уже была частично спроектирована. Но владение продуктовыми компромиссами все равно остается внутри компании. Стартап знает свои обещания клиентам, нагрузку на поддержку и запас денег. Агентство — нет.\n\nК последней неделе агентство уже выкатило портал и исправило самые заметные баги. Оно не утверждает запуск самостоятельно. Внутренняя команда проверяет готовность поддержки, заметки к релизу, мониторинг и шаги отката. Затем компания утверждает запуск.\n\nВот так и выглядят четкие границы между CTO и внешним агентством. Агентство строит портал. Стартап решает, на какой технологии он будет жить, какой объем выйдет сейчас и когда к нему получат доступ клиенты. Если у стартапа нет штатного CTO, fractional CTO для стартапов может взять эту роль на себя и удерживать такие решения внутри бизнеса.\n\n## Ошибки, которые позже приводят к конфликтам\nБольшинство споров с агентством начинается не со злого умысла. Они начинаются с размытых согласований, отсутствия правил доступа и поспешных решений в условиях дедлайна.\n\nОбычное сообщение в чате — одна из самых опасных ловушек. Кто-то пишет «все ок» или «делайте», а через несколько недель каждая сторона помнит это по-своему. Агентство воспринимает сообщение как официальное одобрение. CTO считает, что это была просто быстрая реакция, а не формальное согласование. Если изменение затрагивает объем работ, архитектуру, безопасность или сроки релиза, фиксируйте решение в тикете или документе согласования. Две строки записи лучше длинного спора потом.\n\nЕще одна частая проблема начинается с доступа к production. Если у агентства единственные учетные данные для продакшена, оно контролирует гораздо больше, чем просто разработку. Тогда каждый хотфикс, откат и релиз становятся зависимыми от внешней команды. Оставьте права на релизы внутри компании, даже если агентство ведет большую часть повседневной разработки. Внутренние владельцы должны контролировать production-аккаунты, права на деплой, настройки домена и доступ к резервным копиям.\n\nДедлайны тоже подталкивают команды к плохим решениям. Продакт-менеджер просит разработчиков «просто выбрать лучший вариант», потому что запуск уже близко. Разработчики тогда принимают продуктовые компромиссы, которые им не стоит брать на себя, например сокращают онбординг, откладывают проверки оплаты или меняют то, как пользователи видят данные. Эти решения влияют на бизнес, а не только на код. В здоровых границах между CTO и внешним агентством агентство предлагает варианты, а внутренняя команда выбирает компромисс.\n\nДемо создают другую проблему. Красивое демо может скрыть слабую архитектуру, жестко зашитую логику или упрощения, которые ломаются на масштабе. Если CTO пропускает архитектурную проверку только потому, что экран выглядит хорошо, счет потом приходит в виде медленных релизов, хрупких интеграций и внезапных переписываний. Красивая программа все еще может оказаться дорогой программой.\n\nНапряжение появляется и тогда, когда команда принимает код без заметок по тестам, шагов отката и базовых инструкций по эксплуатации. «На staging работает» — этого недостаточно. Внутренней команде нужно понимать, что изменилось, как проверить это в production, что может сломаться и как быстро откатить релиз.\n\nОдно простое правило предотвращает массу конфликтов: задача не считается завершенной, пока код, запись о решении, заметки по тестам и план отката не лежат в одном месте. Это звучит строго. Но это все равно дешевле, чем разбираться в виноватых после сломанного релиза.\n\n## Быстрая проверка перед утверждением работы\n\nПроверка релиза должна занимать десять минут, а не два часа спора. Если одобрение зависит от того, что агентство должно присутствовать и объяснять каждое изменение, значит, ваша команда еще не владеет продуктом по-настоящему.\n\nПеред тем как сказать «да», спросите, кто может остановить релиз, если риск вырастет. Этот человек должен быть внутри вашей компании, обычно это CTO или тот, кто его заменяет. Агентство может предупреждать, оценивать и рекомендовать. Ваша команда решает, выпускать ли, откладывать ли, откатывать ли или сокращать объем.\n\nЗатем проверьте операционную независимость. Если агентство пропадет на день, сможет ли ваша команда сама выкатить релиз, откатить его, прочитать логи и справиться с простым инцидентом? Если нет, утверждать еще рано, даже если функция выглядит завершенной. Именно здесь управление софтверным агентством чаще всего ломается: команды утверждают код, который еще не умеют обслуживать самостоятельно.\n\nКороткая проверка хорошо работает, если каждый спринт отвечает на пять вопросов:\n- кто может поставить релиз на паузу и по какой причине\n- может ли ваша команда деплоить без помощи извне\n- менял ли кто-то схему, поставщика или инфраструктурный план\n- собраны ли все открытые продуктовые и инженерные компромиссы в одном письменном списке\n- сможет ли новый инженер объяснить границу за пять минут\n\nПоследняя проверка быстро ловит размытое владение. Если новый сотрудник не может объяснить, кто решает по архитектуре, кто отвечает за права на релизы внутри компании и кто владеет продуктовыми компромиссами, значит, граница все еще слишком размыта.\n\nХраните один общий документ для нерешенных компромиссов. Он может быть простым и коротким. Например: «Выпускаем сейчас, но поиск будет медленнее» или «Откладываем запуск и убираем риск зависимости от поставщика». Когда решения живут в чатах или созвонах с агентством, никто уже не помнит, почему команда выбрала именно этот путь.\n\nКоманды, которые работают с fractional CTO для стартапов, часто используют такую проверку как финальный рубеж. Она простая, и в этом смысл. Если релиз проходит эти проверки, утверждение становится гораздо меньше похоже на догадку и гораздо больше — на контролируемое решение.\n\n## Что делать дальше, чтобы схема стала здоровее\nМногим командам не нужен большой пересмотр процессов. Им нужно несколько правил, которые можно увидеть и которым можно следовать. Начните с одновременной проверки текущего контракта, списка доступов и процесса согласования. Когда все это лежит в разных местах, команды замечают пробелы только после неудачного релиза.\n\nЗатем исправьте одну границу на этой неделе. Выберите ту, где риск самый высокий. Чаще всего это права на релиз или доступ к production. Если агентство может выкатывать в production без внутреннего одобрения, исправьте именно это в первую очередь. Если у внешних аккаунтов все еще слишком широкие права администратора, сократите этот список до следующего деплоя.\n\nКороткая рабочая заметка часто полезнее, чем еще одно совещание. Держите ее на одной странице и пишите простыми словами.\n\n- CTO отвечает за архитектурные решения, доступ к production и финальное утверждение релиза.\n- Агентство отвечает за реализацию, оценки и ежедневную поставку в рамках согласованного объема.\n- Компания оставляет продуктовые компромиссы внутри, когда меняются бюджет, риск или сроки roadmap.\n- Любое исключение требует письменного согласования в том же месте, где команда ведет задачи.\n\nПоделитесь этой заметкой с основателями, продуктовой командой, инженерами и лидом агентства. Попросите каждого подтвердить одну и ту же версию. Устные правила быстро разваливаются, когда сроки начинают поджимать, а именно тогда обычно и начинаются конфликты по границам.\n\nПолезно также добавить простую ежемесячную проверку. Просматривайте, у кого есть доступ к production, кто может утверждать релиз и какие решения ушли за пределы компании так, что этого никто не заметил. Эта маленькая привычка помогает держать границы между CTO и внешним агентством ясными еще до того, как они превратятся в проблему доверия.\n\nЕсли вам нужен внешний взгляд, fractional CTO может проверить роли, владение архитектурой и процесс релиза до того, как работа агентства разрастется во что-то, что уже трудно контролировать. Oleg Sotnikov помогает стартапам выстраивать практичные границы и оставлять технические решения внутри компании, пока внешние команды продолжают выпускать продукт.