Первое задание для нового CTO стартапа: одна реальная проблема

Почему первая неделя почти ничего не показывает

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

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

Первое задание не должно быть в духе «посмотреть стек» или «поделиться 90-дневным планом». Такие задачи легко приукрасить и сложно проверить. Умный человек может неделю звучать правильно, так и не доказав, что он умеет урезать объём работ, защищать выручку или сказать «нет» рискованному исправлению, которое на бумаге выглядит быстрым.

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

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

Если растёт отток на платном плане или падает конверсия из пробного периода после релиза, у каждого выбора есть цена. Исправлять сразу, остановить roadmap или подождать ещё день ради более хороших цифр? Живая продуктовая проблема заставляет нового CTO показать суждение там, где на кону стоят деньги. Это скажет о нём больше, чем любая отполированная первая неделя.

Что должно показать это задание

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

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

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

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

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

Полезная проверка отвечает на четыре простых вопроса:

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

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

Выберите одну живую проблему, которая влияет на выручку

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

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

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

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

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

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

Как настроить задание

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

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

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

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

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

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

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

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

Поставьте ограничители до начала работы

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

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

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

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

Установите жёсткий потолок по стоимости и вниманию. Небольшой бюджет часто говорит больше, чем большой, потому что заставляет выбирать. Можно разрешить 20 часов инженеров, 10 часов дизайна и до 2000 долларов расходов. Для CTO на частичной занятости это особенно важно. У него меньше времени на расшифровку неписаных правил, значит, правила должны быть видны.

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

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

Хорошие ограничители не загоняют умных людей в угол. Они делают суждение видимым. В этом и смысл задания.

Простой пример из SaaS-команды

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

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

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

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

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

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

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

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

Первая ошибка — туманная цель. «Улучшить платформу» звучит серьёзно, но даёт новому лидеру слишком много свободы задним числом определять успех. Один человек начнёт настраивать запросы, другой переделывать roadmap, третий заговорит о найме. Нельзя оценивать решения, когда цель расплывчата.

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

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

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

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

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

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

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

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

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

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

Понятный язык — ещё один тест, который команды часто пропускают. Объясните задачу человеку вне инженерной команды в двух-трёх предложениях. Если он всё ещё выглядит растерянным, бриф не готов. Хорошие задания звучат просто: «Слишком много пользователей пробного периода ломаются на этапе настройки. Нужно снизить этот отвал за две недели, не сломав существующие аккаунты».

Есть ещё одна вещь, на которой команды спотыкаются постоянно. Кто-то должен владеть решением о релизе. Назовите этого человека до первого дня. Кто говорит «да» запуску? Кто может остановить работу? Кто решает, делать ли откат, если метрика идёт не туда? В маленьком стартапе это часто CEO или продуктовый лидер. Если это не определено, новый CTO потратит первую неделю на поиски разрешений вместо решения проблемы.

Что делать после результата

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

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

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

Мнение команды здесь очень важно. Спросите, где CTO уменьшил путаницу, а где добавил её. Задавайте простые вопросы:

• Что стало понятнее после того, как этот человек включился?
• Где работа пошла быстрее?
• Где приоритеты стали мутнее?
• Кому пришлось слишком долго ждать ответа или согласования?

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

После этого примите одно решение и скажите его прямо:

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

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

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