Первые 30 дней фракционного CTO: аудит, доверие, быстрые победы

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

Первые 30 дней с фракционным CTO напряжённы почти для всех.

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

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

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

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

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

Что нужно узнать за первую неделю

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

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

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

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

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

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

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

Как провести аудит стека без драмы

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

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

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

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

Короткий чеклист помогает держать аудит спокойным:

• Что ломалось в проде недавно?
• Как команда это заметила?
• Сколько заняло восстановление?
• Может ли команда быстро откатиться?
• Что всё ещё зависит от одного человека?

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

Решения, которые нельзя откладывать

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

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

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

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

Правила согласований так же важны. Если продажи обещают даты, основатели меняют scope, а инженеры сами вносят фикс‑патчи в прод — никто не владеет результатом. Назначайте имена, не должности. Один человек утверждает изменения scope. Один человек утверждает время релиза. Один человек владеет доступом в прод.

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

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

Быстрые победы, которые строят доверие рано

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

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

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

Шум от алертов — ещё одна лёгкая зона для доверия. Если Sentry, Grafana или уведомления по почте срабатывают весь день по мелочам, люди перестают на них смотреть. Уберите дублирующие алерты, поднимите пороги там, где это имеет смысл, и направьте реальные проблемы к нужному человеку. Тихая система помогает команде видеть, что действительно требует действий.

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

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

Как работать с основателями и командой

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

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

Задавайте простые вопросы. Что должно случиться в ближайшие 30–60 дней для бизнеса? Какая работа постоянно срывается и почему? Что тормозит инженеров каждую неделю? Какое обещание команда может дать сейчас, не догадываясь?

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

Объясняйте компромиссы простым языком. Скажите: «Мы можем выпустить эту фичу в этом месяце, но тогда придётся отложить уборку биллинга», или «Мы можем быстрее сократить инциденты, если сначала починим деплой, а не наймём ещё людей». Большинству основателей не нужны глубокие технические детали. Им нужны ясные варианты и вероятные последствия.

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

Простой план на 30 дней

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

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

Дни 8–14: проверьте, как работа на самом деле движется. Посмотрите релизы, баги, инциденты, облачные счета, расходы подрядчиков и роадмап. Здесь проявляются паттерны. Может быть, деплои занимают два дня. Может быть, никто не доверяет тестам. Может быть, один старый сервис вызывает большую часть проблем поддержки.

Дни 15–21: примите несколько решений и сделайте их понятными. Назначьте владельца для каждой рискованной системы. Решите, какая работа останавливается, что продолжается, а что требует доказательств прежде, чем тратить на это время. Установите одно правило доставки, например, более мелкие релизы каждую неделю. Исправьте линию отчётности по инцидентам и приоритетам.

Дни 22–30: добейтесь видимого прогресса. Выпустите две‑три быстрые победы, а не десять полуготовых идей. Одна команда может сократить облачные расходы, добавить базовый трекинг ошибок и убрать застрявший проект из роадмапа. Другая может ужесточить код‑ревью и сократить согласование релиза с трёх человек до одного.

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

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

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

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

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

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

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

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

Реалистичный пример из маленькой продуктовой команды

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

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

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

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

В этом нет ничего эффектного. Это именно та работа, которая успокаивает уставшую команду.

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

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

Быстрая проверка перед 30‑м днём

К 30‑му дню люди должны быстро отвечать на базовые вопросы. Если основатель спрашивает: «Что может нам навредить больше всего в этом квартале?» — команда должна назвать топ‑риски за минуту‑две. Если на это всё ещё уходит долгое совещание, картина размыта.

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

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

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

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

Это та работа, которой занимается Oleg Sotnikov на oleg.is как фракционный CTO и советник стартапов. Цель не эффектный ребилд. Цель — быстро сделать ситуацию разборчивой, назначить владельцев и ввести простые привычки релиза и мониторинга до того, как предотвратимые проблемы распространится.

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

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

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

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

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

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

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

Месяц после первого месяца должен чувствоваться спокойнее, а не загруженнее.