CTO на раннем этапе: от чего в первый месяц сказать «нет» в первую очередь

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

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

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

У многих небольших команд релизы до сих пор завязаны на привычки, которые никто не выбрал бы сознательно. Один инженер по памяти помнит шаги deploy. Кто-то другой вручную проверяет production после каждого запуска. Rollback занимает слишком много времени, поэтому люди избегают выпусков ближе к вечеру. Со стороны продукт может выглядеть стабильным. Но под капотом путь в production держится на временных решениях.

Именно здесь первый месяц чаще всего идет не так. Большие изменения выглядят продуктивно, потому что их видно. Rewrite, migration инструментов, разделение репозитория, переход в cloud или новый platform-проект создают ощущение, что прогресс уже начался. На практике такие проекты добавляют еще больше движущихся частей до того, как команда разберется с delivery risk, который уже живет в production.

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

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

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

Как выглядит реальный риск delivery

Риск delivery становится заметен, когда команда начинает считать поломанные релизы нормой. Люди уже заранее ждут, что deploy может не пройти, фикс может потребовать еще одного фикса, а кому-то придется сидеть онлайн допоздна «на всякий случай». Это не мелкая проблема процесса. Это нестабильный выпуск изменений.

Один из частых признаков — размытая ответственность. Никто не может сказать, кто принимает решение о времени релиза, кто может безопасно сделать rollback и кто занимается hotfix, если production ломается. Работа все равно уходит в релиз, но происходит это на привычке и везении. Когда что-то идет не так, снова возникает тот же вопрос: «Кто вообще знает, как это работает?»

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

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

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

Проверка простая. У релиза должен быть один понятный owner по срокам выпуска. Минимум два человека должны уметь сделать rollback без помощи. Шаги hotfix должны быть записаны и проверены. Количество открытых багов не должно расти неделя за неделей. И команда должна продолжать выпускать изменения, даже если один senior-инженер не на месте.

В первые 30 дней CTO это важнее споров о tools. Если команда не может безопасно выпускать изменения уже на этой неделе, migration или крупный platform-проект добавит стресс, а не контроль.

Что поставить на паузу в первый день

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

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

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

Rewrite — самый легкий капкан. Инженеры часто хотят заменить старый сервис, потому что знают: сейчас они смогут сделать его лучше. Возможно, это так. Но если клиенты получают обновления поздно, rewrite забирает внимание у тестирования, процесса релиза, разбора багов и реакции на инциденты. Старый код, который работает и выпускается в production, часто менее рискован, чем новый код, который еще не закончен.

Миграции tools создают такую же просадку. Команда может потратить две недели на перенос issue tracking, CI, чатов, документации или cloud-сервисов, а потом обнаружить, что ничего не стало выпускаться быстрее. В первые 30 дней инструмент стоит менять только тогда, когда текущий вариант прямо вызывает outages, блокирует релизы или скрывает серьезные проблемы.

Широкая platform-работа может звучать ответственно. Команды предлагают новую event-систему, полную чистку data layer, более удобный internal framework или новый observability stack. Если за этим не стоит живой инцидент, отложите это. Сначала устраните bottleneck релиза.

Используйте простой фильтр: если работа не снизит delivery risk в ближайшие несколько недель, поставьте ее на паузу. Запишите это, сохраните заметку и вернитесь к ней, когда команда снова сможет выпускать изменения без драмы.

Что исправить до любого большого изменения

Для CTO небольшой команды первый месяц — это в основном возвращение к скучным релизам. Rewrite не спасет команду, которая не может безопасно выпускать маленькие изменения. Когда delivery risk высокий, новые tools и platform work обычно добавляют еще один движущийся элемент в и без того шаткий процесс.

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

Дальше дайте каждой области приложения понятного owner. Это не значит, что нужны силосы. Это значит, что один человек отвечает за checkout, один — за email worker, один — за billing. В небольшой команде один человек может отвечать сразу за несколько сервисов. Но это все равно лучше, чем общая путаница, когда что-то ломается ближе к вечеру.

Затем добавьте базовые alerts. Они должны быть скучными и полезными. Команда должна знать, когда приложение упало, когда резко выросло число ошибок и когда background jobs остановились или накопились в очереди. Если первый alert приходит от клиента, значит команда не управляет системой, а только гадает.

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

Сократите объем нестабильных функций, пока релизы не станут спокойнее. Если новый onboarding flow ломается через один deploy, пока перестаньте добавлять edge cases и полировку. Сведите его к самой маленькой рабочей версии, уберите повторяющиеся сбои и посмотрите, как пройдут два-три спокойных релиза.

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

Простой порядок на первые 30 дней

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

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

Вторая неделя должна смотреть назад. Возьмите несколько недавних релизов и выпишите три сбоя, которые принесли больше всего боли. Пишите простыми словами. Может быть, deploy срывались, потому что тесты запускались слишком поздно. Может быть, approvals лежали по два дня. Может быть, hotfix обошел review и утром вызвал еще один outage.

К третьей неделе выберите одну повторяющуюся проблему и уберите ее. Только одну. Маленький фикс, который меняет повседневную работу, лучше, чем большой проект, который красиво звучит на встрече. Таким фиксом может быть release checklist, один понятный owner deploy, заметка о rollback для каждого изменения в production или правило, что по пятницам никто не делает merge без реальной причины.

Четвертая неделя — время еще раз посмотреть на большие идеи. Вернитесь к rewrite, migration инструментов или platform-проекту, который вы хотели одобрить в первый день. Какие-то из них все еще будут иметь смысл. Другие уже будут выглядеть гораздо менее срочными, когда команда снова сможет выпускать изменения спокойно.

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

Реальный пример из небольшой SaaS-команды

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

Но support tickets рассказывали более срочную историю. После Friday deploy у клиентов появлялись ошибки в checkout. У одних не проходила оплата. У других деньги списывались, но обновление аккаунта не появлялось до понедельника, когда кто-то делал hotfix. Выручка не останавливалась, но доверие проседало каждые выходные.

Новый CTO сказал migration пока нет.

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

CTO сузил работу до трех изменений: добавить автоматические тесты для checkout-пути, включая скидки, неудачные платежи и активацию аккаунта; настроить простой rollback, чтобы команда могла отменить плохой deploy за минуты; и назначить одного человека явным owner релиза, с правилом, что по пятницам нельзя выкатывать изменения в checkout поздно вечером.

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

Уже через два release cycle Friday deploy снова стали скучными. Объем обращений в support снизился. Команда видела, какие изменения создают проблемы, а rollback перестал быть панической гонкой в групповом чате. Инженеры также перестали гадать, кто должен что чинить, потому что ответственность стала понятной.

Только после этого CTO снова вернулся к разговору о migration. Команда пересмотрела тот же frontend move уже с лучшей информацией: как часто он выпускался, где появлялись баги, насколько хорошо он покрыт тестами и решит ли новый stack реальную продуктовую проблему.

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

Ошибки, которые съедают первый месяц

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

Одна из ошибок — выбирать tools до того, как найден bottleneck delivery. Новая система для ticket, новый CI, новый cloud-сервис могут подождать несколько недель. Сначала посмотрите на недавние релизы. Прочитайте notes по инцидентам, историю pull request и шаги deploy. Если никто не может объяснить, почему два последних релиза сорвались, выбор tools — это просто движение ради движения.

Еще один плохой ход — начинать архитектурную работу до того, как измерены реальные сбои релизов. Команды любят спорить о границах сервисов, планах rewrite и выборе пакетов. А последний релиз мог провалиться по простой причине: не было rollback plan, ревью шло слишком медленно, тестирования было мало или ownership был неясен. Для этого не нужен большой redesign. Нужны факты из уже выпущенной работы.

Обучать команду новым системам во время пожарной тревоги — еще один убийца месяца. Если production хрупкий, сейчас не время переводить всех на новый flow репозитория, новый deployment tool или новую observability-настройку. Кривые обучения реальны. Даже сильные инженеры начинают работать медленнее, когда должны одновременно выпускать изменения и заново учить свой базовый workflow.

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

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

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

Быстрые проверки, прежде чем одобрять большой проект

Большие проекты на roadmap выглядят аккуратно. Но очень часто они делают delivery хуже до того, как становится лучше.

Если команда все еще борется с неудачными релизами, неожиданными outages или hotfix каждую пятницу, rewrite или migration обычно плохая ставка. Прежде чем одобрять что-то крупное, задайте пять простых вопросов:

• Убирает ли эта работа реальный сбой, который есть у команды сейчас? «Мы хотим обновить stack» — слабый аргумент. «Deploy падает дважды в неделю, потому что build идет 70 минут, а rollback ломается» — это реальная проблема.
• Может ли кто-то объяснить rollback за одну минуту? Если ответ требует схемы и встречи, команда еще не готова выпускать это безопасно.
• Почувствуют ли клиенты изменения в течение 90 дней? Если пользователи не увидят более быстрых страниц, меньше багов или меньше обращений в support, работу, скорее всего, можно отложить.
• Сможет ли та же команда продолжать выпускать изменения, пока это идет? Проект, который забирает всех сильных инженеров из production-работы, — это риск, а не прогресс.
• Были ли последние два релиза спокойными? Если оба релиза требовали ночных исправлений, не добавляйте еще больше движущихся частей.

Один знакомый паттерн у небольших команд повторяется снова и снова. Команда хочет сменить CI, переехать в cloud и разбить приложение на сервисы. А при этом все еще не может предсказать, пройдет ли Friday deploy. В таком случае первым одобрением должна стать безопасность релиза: более короткие build, health checks, шаги rollback и один owner для каждого deploy.

Этот фильтр еще и экономит деньги. Тот же урок хорошо видно в работе Oleg Sotnikov с lean infrastructure и небольшими engineering-командами: не начинайте с широкого platform work только потому, что он кажется чище. Начинайте там, где ломается live delivery. Когда команда два релиза подряд выпускает спокойно, большие ставки уже гораздо легче оценивать.

Что делать дальше после первого месяца

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

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

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

Когда rewrite или migration снова появятся на столе, свяжите их с понятной проблемой. Хорошие причины конкретны: продуктовое изменение, которое нельзя выпустить на текущем stack; слишком высокая стоимость; или operational pain, который продолжает бить по команде каждую неделю. «Код выглядит старым» — этого недостаточно.

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

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

Некоторым основателям нужен еще один взгляд со стороны, прежде чем они одобрят rewrite, migration или более крупный архитектурный шаг. Это может помочь, особенно когда команда устала и каждая опция кажется срочной. Oleg Sotnikov на oleg.is анализирует delivery risk, привычки релизов и ближайшие технические решения как fractional CTO advisor. Короткий внешний review может остановить дорогой обходной путь еще до того, как он начнется.