Перед наймом fractional CTO сначала зафиксируйте эти факты

Почему эта подготовка важна

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

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

Память — плохая система. Slack ещё хуже. Люди помнят разные версии одной и той же проблемы, а переписки прячут контекст в десятках каналов. Один инженер вспоминает неудачную миграцию полгода назад. Фаундер помнит проблему с ценами. Product-менеджер переживает из-за сорванных сроков. Всё это может быть правдой, но по отдельности не складывается в полезную картину.

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

Хороший стартовый пакет даёт три полезные вещи:

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

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

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

Покажите, какие системы у вас уже работают

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

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

Потом опишите связи простыми словами. Вам не нужна красивая архитектурная диаграмма. Коротких заметок достаточно:

• «Веб-приложение отправляет действия клиентов в API.»
• «API читает данные из PostgreSQL и хранит файлы в object storage.»
• «Сервис биллинга зависит от payment webhooks.»
• «Саппорт-инструмент каждый час синхронизирует данные клиентов в CRM.»

Такая карта системы для команды разработки часто уже позволяет быстро заметить скрытые зависимости.

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

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

Если вы делаете это перед наймом fractional CTO, стремитесь к ясности, а не к идеалу. У небольшой SaaS-команды на бумаге может быть всего восемь систем, но потом выясняется, что забытый worker обрабатывает возвраты и отправляет алерты на почту бывшего сотрудника. Это как раз тот факт, который стоит обнаружить заранее.

Соберите все расходы в один обзор

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

До найма fractional CTO соберите все регулярные расходы в одну таблицу. Включите облачный хостинг, базы данных, мониторинг, CI/CD, саппорт-софтовые сервисы, дизайн-инструменты, домены, почту, security-сервисы и любого поставщика, который выставляет счёт по графику. Если компания платит за это каждый месяц или каждый год, запишите это.

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

Достаточно короткого списка колонок:

• название сервиса или инструмента
• ежемесячная или ежегодная стоимость
• владелец в команде
• дата продления
• категория
• кто всё ещё этим пользуется

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

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

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

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

Запишите продуктовые цели

Продуктовая цель должна отвечать на один простой вопрос: чего должен достичь продукт в ближайшие 6–12 месяцев? Если ответ звучит как «расти быстрее» или «выпускать больше», он слишком размытый, чтобы помогать принимать хорошие решения.

Пишите цели простым языком, с цифрами, если они есть. «Снизить churn с 5% до 3%», «обслуживать 200 платящих команд» или «запустить биллинг для годовых планов к октябрю» дают внешнему CTO что-то конкретное для работы.

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

Это разделение важно, потому что команды часто путают результат с объёмом работы. Выпустить шесть фич мало что значит, если ни одна из них не помогает продажам, удержанию или расширению.

Простой способ это записать — оставить четыре коротких блока:

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

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

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

Одна ясная страница лучше, чем красивая презентация. Такой советник, как Oleg, намного быстрее заметит пробелы, когда цели конкретные: «выиграть двух enterprise-клиентов, которым нужны audit logs и role-based access до Q4» — гораздо понятнее, чем «двигаться в более крупный сегмент». Такая детализация превращает первый разговор в планирование, а не в гадание.

Выпишите открытые риски

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

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

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

Риски по людям часто прячутся на виду. Запишите, где один человек знает слишком много. Частые примеры:

• один инженер знает весь процесс деплоя
• один подрядчик контролирует доступ к облаку
• один руководитель саппорта знает обходной путь для биллинга
• один фаундер утверждает каждое продуктовое решение

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

Ранжируйте по влиянию на бизнес

Не ранжируйте риски по тому, насколько они раздражают. Ранжируйте по ущербу. Задавайте простые вопросы: останавливает ли это выручку? Создаёт ли юридические или security-проблемы? Вредит ли клиентам каждую неделю? Заставляет ли команду тратить часы на работу, которую мог бы сделать скрипт?

Хорошо работает короткий список рисков. Для каждого пункта фиксируйте:

• проблему
• влияние на бизнес
• как часто это происходит
• кто отвечает за это сейчас
• какой временный обходной путь использует команда

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

Как собрать информацию по шагам

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

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

Потом соберите цифры из тех мест, где они уже лежат:

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

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

Попросите тимлидов проверить черновик и заполнить пробелы. Engineering может подтвердить системы и риски. Finance — счета и контракты. Product — записать следующие цели простым языком, например: «снизить отвал на онбординге» или «выпустить customer portal к сентябрю».

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

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

Ошибки, которые замедляют помощь внешнего CTO

Первые встречи идут не туда, когда команды смешивают жёсткие факты с мнениями и подают их как равнозначные. «Время загрузки страницы выросло с 1,2 до 3,8 секунды» — это факт. «Приложение тормозит, потому что бэкенд старый» — это мнение. До найма fractional CTO разделяйте эти вещи. Это экономит время и помогает избежать плохих ранних решений.

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

Команды также теряют время, когда скидывают огромные выгрузки в общую папку и надеются, что кто-то разберётся. Сырые выгрузки биллинга, все Jira-задачи и месяцы переписок обычно не помогают в первый день. Начинайте с короткой сводки, которую человек может прочитать за 10 минут. Укажите, что делает система, кто за что отвечает, сколько это стоит, что ломается и что ещё неясно.

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

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

Перед первым звонком помогает короткий фильтр:

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

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

Простой пример из небольшой софтверной компании

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

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

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

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

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

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

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

Быстрая проверка перед первым звонком

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

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

Проверьте себя по списку «да/нет»:

• Может ли один человек объяснить текущий стек простыми словами, включая хостинг, приложения, хранилища данных и внешние сервисы?
• Можете ли вы назвать самые большие ежемесячные расходы на технологии, не открывая шесть разных дашбордов или счетов?
• Можете ли вы показать цели продукта на одной странице с понятными приоритетами на следующий квартал?
• Можете ли вы указать на самые большие открытые риски сегодня — например, пробелы в безопасности, хрупкие системы, пропущенные сроки или неясную ответственность?
• Может ли новый советник сразу увидеть, чего не хватает, потому что пробелы видны, а не спрятаны в чатах и головах людей?

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

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

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

Что делать дальше

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

Хороший бриф простой и короткий. Большинству команд нужен всего один документ и несколько вложений:

• простая карта систем с инструментами, сервисами и владельцами
• одна страница по ежемесячным расходам на технологии
• текущие продуктовые цели на ближайшие 3–6 месяцев
• открытые риски с пометкой о влиянии и о том, кто больше всего о них знает
• короткий список неизвестных, которые ещё нужно подтвердить

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

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

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

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