Найм CTO после AI-прототипа: что проверить первым

Почему на этом этапе совершают ошибки при найме

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

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

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

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

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

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

Люди, которые уже запускали AI-системы в продакшене, обычно замечают это заранее. Oleg Sotnikov часто работает с командами именно на этом этапе: прототип уже доказал интерес, но компании все еще нужны устойчивые AI-рабочие процессы, зоны проверки и план поддержки, с которым обычная команда может жить. Именно этот разрыв часто не замечают на интервью, и именно он подводит хороших основателей на этом этапе найма.

Что CTO нужно превратить в систему

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

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

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

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

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

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

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

Кто-то также должен отвечать за сбои в обычной работе. Если плохой ответ дошел до клиента в 16:00, кто это исправляет? Поддержка, продукт, инженерная команда и основатель не могут все считать, что кто-то другой вмешается. CTO должен назвать ответственного, определить время реакции и написать простой план поддержки AI, которым команда сможет пользоваться без созвона.

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

Проведите практическое интервью-упражнение

Самый быстрый способ оценить человека после AI-демо — показать ему реальный прототип и попросить сделать так, чтобы он выдержал ежедневную работу. Это важнее, чем отполированная речь. При найме CTO после AI-прототипа вам нужно доказательство, что кандидат может превратить аккуратный поток промптов в работу, которую команда сможет запускать, проверять и поддерживать.

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

Попросите кандидата описать все вокруг модели, а не только саму модель. Сильный ответ обычно включает:

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

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

Затем надавите на объем. Спросите, что сломается первым, если нагрузка вырастет в 10 раз за месяц. Слабые кандидаты сразу переходят к более мощным серверам или новой модели. Лучшие задают более точные вопросы: важна ли задержка? Часто ли меняются промпты? Что на самом деле является узким местом — время проверки, лимиты запросов, очередь, стоимость или плохие исходные данные? Многие AI-системы ломаются не из-за слабой модели. Они ломаются потому, что никто не продумал повторы, версионирование, одобрения или запасные пути.

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

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

Вопросы, которые показывают реальное операционное мышление

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

Задавайте вопросы, которые заставляют кандидата называть людей, шаги и компромиссы.

• «Перед тем как AI-сгенерированный результат попадет к клиенту, кто его проверяет?» Слабый ответ остается расплывчатым и говорит, что модель со временем станет лучше. Сильный ответ называет зону проверки, например поддержку, операционный отдел или владельца продукта, и объясняет, когда проверок может стать меньше позже.

• «Что происходит, когда модель выдает ерунду?» Хорошие кандидаты не считают плохой ответ редким крайним случаем. Они объясняют запасное поведение: скрыть результат, попросить повторный запуск, передать задачу человеку или сохранить кейс для проверки.

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

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

• «Что мы можем выпустить за две недели, не создав долга в поддержке?» Этот вопрос особенно хорош, потому что проверяет сдержанность. Лучшие кандидаты быстро урезают объем. Они выбирают один узкий процесс, определяют успех и оставляют более сложные случаи на потом вместо того, чтобы запускать хрупкую версию.

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

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

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

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

Небольшая команда продаж строит AI-инструмент, который пишет follow-up письма по заметкам с созвонов. Основатель пробует его на нескольких аккуратных примерах, и демо выглядит отлично. Заметки полные, запрос клиента понятен, а черновик письма звучит почти по-человечески.

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

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

CTO, который может превратить такое демо в реальную систему, обычно добавляет несколько простых контролей:

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

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

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

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

Частые ошибки во время поиска

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

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

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

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

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

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

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

Более безопасный поиск обычно отбирает по таким привычкам:

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

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

Быстрые проверки перед предложением о работе

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

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

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

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

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

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

Задайте еще один вопрос: «Кого бы вы наняли следующим и почему?» Ответ показывает, как человек строит системы. Некоторые сразу попросят еще prompt-инженеров. Это часто плохой знак. Более сильный ответ может включать backend-инженера с дисциплиной в архитектуре, оператора с продуктовым мышлением или руководителя поддержки, который умеет замыкать цикл между проблемами пользователей и исправлениями системы.

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

Следующие шаги для вашей команды

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

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

Соберите этот процесс на одной странице и оставьте все простым:

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

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

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

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

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

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