Владение системой после роста подрядчиков: как его восстановить

Что ломается, когда целой системой никто не владеет

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

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

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

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

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

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

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

Начните с бизнес-границ

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

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

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

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

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

Многие команды делают наоборот. Они начинают с названий репозиториев вроде «checkout-service» или «reporting-api» и считают, что владение должно следовать этой форме. Но названия репозиториев отражают старые решения, личные привычки или границы подрядчиков. Они почти никогда не совпадают с реальной работой. Клиенту все равно, в каком репозитории случилась ошибка. Ему важно, чтобы заказ, счет и подтверждение совпали.

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

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

Нарисуйте карту системы, которую люди смогут прочитать

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

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

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

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

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

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

Названия важны. Переименуйте блоки, которые больше не соответствуют реальности. «Temporary importer», который работает уже 18 месяцев, вовсе не временный. «Core API» может на самом деле скрывать три отдельных бизнес-области под одним старым ярлыком. Плохие названия удерживают плохое владение.

Именно поэтому многие проверки со стороны внешнего CTO начинаются с карты. Когда страница честная, права на выпуск, границы команд и пути эскалации становится намного проще исправить.

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

Назначьте права на выпуск до изменения структуры команд

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

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

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

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

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

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

У прав на откат должна быть та же ясность. Во время инцидента команды теряют время, если никто не знает, кто может откатить релиз, отключить feature flag или остановить задачу. Запишите, кто может откатить код, кто может отключить рискованные функции, кто может остановить фоновые задачи и кого нужно уведомить после отката.

Растущий стартап может дать команде onboarding полные права на выпуск экранов и писем для онбординга, а изменения в billing потребуют проверки и владельца billing, и владельца finance. Это просто, а простые правила выдерживают стресс.

Восстанавливайте владение небольшими шагами

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

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

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

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

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

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

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

SaaS-стартап быстро рос и нанимал подрядчиков туда, где нагрузка появлялась первой. Одна команда занималась checkout, другая — billing, а третья выпускала изменения в мобильном приложении. На бумаге все выглядело неплохо. Каждая группа двигалась быстро и еженедельно выкатывала код.

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

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

Компания решила это, перестроив работу вокруг бизнес-потока, а не вокруг старых договоров. Вместо отдельных корзин для checkout, billing и mobile они создали одну границу для checkout и возврата после платежа, а затем вторую — для поддержки после покупки.

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

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

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

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

Ошибки, из-за которых владение остается размытым

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

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

Еще одна типичная ошибка — назначать владельцев репозиториям и считать, что на этом все. Владение кодом — это только часть владения системой. Кто-то должен отвечать и за on-call, и за решение об откате, и за доступ к production, и за первый ответ, когда sales или support спрашивают: «Что сломалось, кто это чинит и когда все вернется?» Если эти задачи распределены между разными людьми без явного лидера, целиком системой никто не владеет.

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

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

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

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

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

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

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

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

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

Дайте поддержке простой тестовый случай. Если клиент говорит: «Я оплатил, но доступа не получил», поддержка должна точно знать, куда уходит этот вопрос. Если им приходится гадать между billing, backend и ops, граница недостаточно ясна.

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

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

Что делать в ближайшие 30 дней

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

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

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

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

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

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

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

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

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

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

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