Бриф для фракционного CTO: четыре результата для первой встречи

Почему роль вначале становится размытой

Размытая роль CTO очень быстро съедает время. Основатель думает, что новый человек наведет порядок в delivery. Команда ждет более понятной архитектуры. Инвесторы хотят лучшей отчетности. Уже ко второй неделе все просят о разном.

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

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

Представьте стартап, который нанимает CTO на неполную занятость «помочь с продуктом и инженерией». Через несколько встреч основатель хочет более быстрые релизы, инженеры — меньше отвлечений, а финансы — меньшие траты на облако. Все эти просьбы разумны. Но это все еще три разные задачи.

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

Начните с маржи

Если вы не можете сказать, где сегодня утекают деньги, роль так и останется размытой. Поставьте цифру перед первой встречей. Это может быть просто: поднять gross margin с 48% до 58%, сократить расходы на инфраструктуру на 20% или уменьшить долю кастомной поддержки, которая постоянно съедает прибыль.

Цифры делают разговор честным. «Повысить эффективность» — слишком расплывчато. «Сэкономить $6,000 в месяц на облаке и инструментах за 90 дней» — уже достаточно ясно, чтобы действовать.

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

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

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

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

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

Опишите delivery простыми словами

Delivery превращает размытую роль в рабочий план. Хороший бриф не обещает общие вещи вроде «лучший продукт» или «чистая архитектура». Он называет небольшой набор результатов, которые команда реально может выпустить в первом цикле.

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

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

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

Будьте строгими в определении done. Done — это не «код слит» и не «лежит за флагом». Done — это работает в продакшене, удобно в использовании, достаточно протестировано для текущего уровня риска и принято тем, кто это запросил. Если команда говорит, что делает AI-инструмент для поддержки, done может означать, что support-команда уже использует его на реальных тикетах и экономит около 15 минут на каждом случае.

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

Проведите границу по найму

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

Пишите просто. Возможно, никто не отвечает за релизы. Возможно, продукт тормозит, потому что один senior engineer проверяет все подряд. Возможно, вопросы поддержки постоянно отвлекают разработчиков от выпуска продукта. Начните с этих пробелов, а не с должностей.

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

Это важно, потому что ранние наймы закрепляют расходы и подстраивают команду под сегодняшнюю боль. Это может быть дорого. Во многих случаях лучший процесс решает больше, чем еще одна зарплата. Если один человек каждую неделю теряет часы на release notes, code review или настройку тестов, более чистый процесс или нужная автоматизация могут помочь лучше, чем запрос на новую ставку.

Поставьте ограничения до того, как кто-то начнет рекрутинг. Обозначьте лимиты по числу людей и ежемесячным расходам. Например, можно разрешить одного full-time engineer и одного part-time specialist в следующем квартале, но без управленческих наймов. Жесткие ограничения заставляют выбирать, а выбор — это и есть суть.

Полезно также назвать роли, которые не стоит нанимать первыми. В большинстве маленьких компаний это означает engineering manager для крошечной команды, рекрутера до появления реального потока найма, full-time специалиста по инфраструктуре для легких операций, data- или AI-специалиста без понятного сценария использования и второго senior-лидера для управления работой, которая пока еще сама неясна.

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

Назовите риски заранее

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

Начните с продуктового риска. Где delivery может застопориться? Может быть, scope меняется каждую неделю. Может быть, checkout ломается слишком часто. Может быть, одна функция выпускается неделями. Может быть, клиенты регистрируются и быстро перестают пользоваться продуктом. Компания может какое-то время жить без дополнительной функции. Но ей трудно, когда ломается основной сценарий.

Безопасность тоже нужно описывать простыми словами. Ищите открытые клиентские данные, слабый контроль доступа, отсутствие резервных копий, отсутствие процесса реагирования на инциденты или AI-инструменты для написания кода, которые могут трогать production без ревью. Одна утечка или один долгий outage могут стереть месяцы продажной работы.

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

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

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

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

Соберите бриф по шагам

Начните с одной страницы. Если черновик читается дольше двух минут, он уже слишком длинный.

Напишите одно предложение, которое простыми словами описывает бизнес-цель. Без технических терминов. «Снизить cost per release, сохранив еженедельный темп продуктовой работы» — уже достаточно хорошо. Люди понимают это быстро.

Затем добавьте четыре короткие строки:

1. Margin — что должно улучшиться в расходах, тратах или производительности команды.
2. Delivery — что команда должна выпустить и к какому сроку.
3. Hiring — какие роли вы добавите, не будете нанимать или отложите.
4. Risk — что может ударить по выручке, uptime, безопасности или доверию.

Теперь превратите каждую строку в вопрос для звонка. Вопросы дают лучшие ответы, чем лозунги. «Где мы сегодня теряем деньги?» лучше, чем «Нам нужна эффективность». «Что обязательно должно выйти в ближайшие 90 дней?» лучше, чем «Нам нужен roadmap».

Так вы еще и увидите, как думает основатель. Одних больше всего волнует скорость. Других — burn, надежность или ошибки найма. Хорошие вопросы быстро делают эти приоритеты видимыми.

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

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

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

Их бриф все равно помещается на одну страницу:

• Margin — сократить расходы на облако и поставщиков на 20% за 90 дней. Компания платит за слишком большие database instances, старые staging-серверы, которые работают весь месяц, и несколько перекрывающихся инструментов.
• Delivery — перейти с крупных ежемесячных релизов на еженедельный ритм релизов с планом отката.
• Hiring — добавить одну недостающую роль, а не устраивать волновой найм. В этом случае команде нужен senior engineer, который сможет взять на себя релизный процесс, подчистить backlog и перестать ежедневно делать из основателя project manager.
• Risk — сначала закрыть два пробела. Uptime нестабилен, потому что после работы alerts никто не отслеживает, а безопасность слабая, потому что команда пользуется одной admin account и никогда не проверяла восстановление из backup.

Такой короткий бриф меняет первую встречу. Вместо спора о названиях должностей или вопроса «а нужен ли компании CTO» основатель и советник могут говорить о цифрах, сроках и ответственности.

Margin прямо указывает на расходы на облако и поставщиков. Delivery — на процесс релизов. Hiring — на одну роль, которая убирает ежедневное трение. Risk — на работу по uptime и безопасности, которая не должна ждать аудита или серьезного сбоя.

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

Ошибки, которые ослабляют бриф

Слабые брифы обычно начинаются как список хотелок. Основатель просит более быстрый delivery, меньшие расходы на облако, лучший найм, более сильную безопасность, более чистый код, новые дашборды и план по AI — все сразу. Это не создает фокус. Это превращает первую встречу в сортировку.

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

Когда бриф превращается в список пожеланий

Еще одна частая ошибка — путать задачи с результатами. «Нанять двух инженеров», «перейти на Kubernetes» или «настроить CI/CD» — это задачи. Они могут помочь, но это не тот итог, который вам нужен. Лучший бриф говорит: «сократить задержки релизов с трех недель до трех дней» или «уменьшить стоимость инфраструктуры на 25% без ущерба для uptime». Тогда CTO может сам выбрать способ.

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

Проговаривайте компромисс прямо:

• Если дата фиксирована, scope может сократиться.
• Если scope фиксирован, бюджет может вырасти.
• Если бюджет фиксирован, delivery может замедлиться.

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

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

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

Быстрая проверка перед первой встречей

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

Большая часть проблем начинается с мягких формулировок. «Улучшить delivery» ничего не значит. «Выпускать клиентские исправления в течение пяти рабочих дней» дает CTO реальную рабочую цель. То же правило действует для маржи, найма и рисков. У каждого пункта должна быть цифра, срок или проверка на да/нет.

Перед тем как отправлять бриф, проверьте пять вещей:

• Весь документ достаточно короткий, чтобы прочитать его за две минуты.
• У каждого результата есть измерение: ежемесячные расходы, скорость релизов, размер команды или uptime.
• Ограничения по бюджету записаны простыми цифрами, даже если они приблизительные.
• Главные риски уже перечислены: например, зависимость от одного клиента, хрупкая инфраструктура или пробел в найме.
• Есть место для предположений, которые CTO может оспорить на первом звонке.

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

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

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

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

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

Начинайте только с четырех результатов: margin, delivery, hiring и risk. Попросите CTO сначала отреагировать именно на них, а уже потом говорить об инструментах, оргструктуре или архитектуре. Так разговор будет держаться на бизнес-результатах, а не уйдет слишком рано в технические детали.

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

Простой agenda вполне достаточно:

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

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

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

Если вам нужен внешний взгляд до старта работы, Oleg Sotnikov на oleg.is делает именно такую работу как Fractional CTO и startup advisory. Короткий разбор брифа может сделать первую встречу гораздо полезнее и сэкономить недели путаницы после нее.