Оцените идею AI-стартапа как технический сооснователь

Почему выбор модели отвлекает основателей

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

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

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

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

Возьмём черновики ответов поддержки. Неправильный первый вопрос — «Какая модель пишет самый красивый ответ?». Полезные вопросы куда скучнее. Сколько тикетов приходит в день? Сколько времени агент тратит на написание ответа? Что произойдёт, если плохой черновик проскочит наружу? Если черновик экономит 30 секунд, но на проверку уходит 2 минуты, выбор модели — это в основном шум.

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

Начните с рабочего процесса

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

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

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

Примерный рабочий процесс может выглядеть так:

1. Открыть тикет и прочитать сообщение клиента.
2. Найти прошлые заказы и правила возврата.
3. Подготовить ответ.
4. Проверить тон, политику и цифры.
5. Отправить или передать дальше.

Теперь посмотрите, какие части людям не нравятся и какие их замедляют. Скучные шаги часто хорошо подходят для автоматизации. Медленные шаги тоже могут подойти, но только если они встречаются достаточно часто. Задача, которая занимает 20 минут раз в месяц, менее интересна, чем задача, на которую уходит 4 минуты, но 200 раз в день.

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

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

Проверьте, создаёт ли процесс реальную ценность

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

Начните со времени. Если команда тратит на тикеты поддержки 15 часов в неделю, а AI сокращает это до 9, вы экономите 6 часов. При ставке $40 в час это примерно $240 в неделю, или чуть больше $12 000 в год до учёта затрат на модель и внедрение.

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

Не останавливайтесь на фразе «сэкономленное время». Плохие ответы создают дополнительную работу по доработке, а эта доработка часто съедает почти всю пользу. Черновик, который генерируется за 30 секунд, но проверяется 6 минут, уже не выглядит дешёвым, если старый процесс занимал 7 минут. Считайте время на проверку, повторные попытки, исправления промпта и стоимость исправления ошибок после того, как они дошли до клиента.

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

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

Стоимость проверки меняет математику

Результат, который генерируется за 20 секунд, но проверяется 4 минуты, всё ещё может оказаться плохой сделкой. Оцените стоимость проверки до того, как вас обрадует гладкое демо.

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

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

Сравнение обычно очень прямое:

• Если человек пишет ответ за 3 минуты, а AI плюс проверка занимают 2 минуты, у вас, возможно, что-то есть.
• Если человек пишет его за 3 минуты, а AI плюс проверка занимают 5 минут, продукт добавляет работу.
• Если проверка занимает одинаковое время у каждого результата, модель не несёт достаточно нагрузки.

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

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

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

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

Последствия ошибки показывают, где уместен AI

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

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

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

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

Простое правило помогает:

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

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

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

Оцените идеи в пять проходов

Грубая таблица оценки лучше долгих споров о бенчмарках. Сначала оцените работу. Потом говорите о моделях.

Используйте простую шкалу от 1 до 5 для каждой области:

• Боль процесса — насколько раздражающей или медленной является текущая задача? 1 означает, что люди почти не замечают проблему. 5 означает, что команды теряют на этом время каждый день.
• Ценность — что изменится, если вы улучшите эту задачу? 1 означает небольшое удобство. 5 означает явные деньги, скорость или влияние на клиента.
• Стоимость проверки — сколько времени человеку нужно после того, как AI выдаст результат? 1 означает, что нужно проверять каждую строку. 5 означает, что достаточно беглой выборочной проверки.
• Последствия ошибки — что произойдёт, если AI ошибётся? 1 означает, что ошибка может ударить по доверию, деньгам или безопасности. 5 означает, что ошибки дешёвые и легко исправляются.
• Доступ к данным и сложность внедрения — можете ли вы получить входные данные, очистить их и поддерживать поток? 1 означает, что отсутствие или грязные данные блокируют работу. 5 означает, что данные уже есть в удобном виде.

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

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

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

После этого выбирайте модель. До этого выбор модели — в основном шум.

Простой пример: черновики ответов поддержки

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

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

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

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

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

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

Ошибки, которые делают технические сооснователи

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

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

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

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

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

Быстрая проверка перед тем, как вы решитесь

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

Запишите пять вещей:

• Точный шаг, который меняется. Назовите входные данные, результат и момент, когда AI запускается.
• Человек, который проверяет. Укажите, кто проверяет результат, сколько времени занимает проверка и можно ли быстро исправить плохой ответ.
• Самая дорогая ошибка. Выберите один реальный минус, например неверный возврат денег, рискованное юридическое утверждение или плохой ответ разъярённому клиенту.
• Небольшую пачку реальной работы. Используйте 20–50 настоящих объектов, а не придуманные примеры, которые выглядят чище, чем рабочие данные.
• Сработает ли версия 1 без кастомного обучения. Если без дополнительных наборов данных и недель настройки не обойтись, идея может быть слабее, чем кажется.

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

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

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

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

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

Начните с одной страницы и заполните только три вещи:

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

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

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

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

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

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

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