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

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

Что сломалось в привычном интервью с клиентом

Коротко: сломалась граница между вопросом для исследования и просьбой сделать исследование за исполнителя.

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

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

Особенно плохо звучит вопрос:

Чем это отличается от того, что уже стоит в проде?

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

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

Как эта поломка выглядела снаружи

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

Вопросы могли быть правильными по форме:

Проблема была не в самих формулировках. Она была в моменте, когда их задавали.

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

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

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

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

Почему я сначала искал проблему не там

Коротко: я пытался улучшать формулировки, хотя ломался порядок работы до интервью.

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

Это делает бриф приятнее, но не устраняет причину. Даже короткий список раздражает, если в нём спрашивают уже известное.

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

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

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

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

Где проходит новая граница приличия

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

Я делю информацию перед разговором на четыре слоя.

Первый слой - факты, которые можно проверить напрямую:

Второй слой - расхождения:

Третий слой - неизвестное:

Четвёртый слой - решение клиента:

Неприличным стал вопрос из первого слоя, если исполнитель мог сам получить ответ. Полезным остаётся вопрос из третьего или четвёртого слоя, потому что модель, сайт и интерфейс не имеют права придумывать мотив владельца.

Настоящая причина была не в нейросетях

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

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

Опасность начинается там, где гипотеза перестаёт быть помеченной гипотезой.

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

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

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

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

Какие вопросы теперь отправляются в корзину

Коротко: вопрос убирается, если ответ доступен исполнителю без догадки и без участия клиента.

Перед разговором я проверяю каждый вопрос по простой схеме.

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

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

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

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

Если ответ относится к намерению владельца, вопрос остаётся. Намерение невозможно честно извлечь из интерфейса.

Так исчезают вопросы вроде:

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

Как я закрыл это механизмом в НЕВОДЕ

Коротко: система сначала собирает проверенные сведения о моих разработках, а затем не пропускает материал без связи с конкретным продуктом.

У НЕВОДА есть реестр продуктов и кейсов. Он собирается из карточек моих проектов. Перед выпуском материал проверяется на привязку к реальной разработке.

Это важнее красивой инструкции в промпте. Просьба писать конкретно остаётся пожеланием. Проверка, которая возвращает общий текст на доработку, становится механизмом.

Контур выглядит так:

  1. Синхронизировать сведения о продуктах из источника истины.
  2. Выбрать разработку, вокруг которой строится материал.
  3. Проверить её статус.
  4. Разрешить только те утверждения, которые этому статусу соответствуют.
  5. Отклонить общий текст без продуктовой привязки.
  6. Не выпускать материал наружу без записи об одобрении владельца.

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

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

Доказательство у такого подхода наблюдаемое: материал либо проходит проверку привязки к продукту, либо возвращается на доработку. Для публикации отдельно проверяется запись одобрения. Уверенность автора и красота текста на решение не влияют.

Что нейросеть действительно даёт перед встречей

Коротко: она ускоряет чтение и сопоставление, но не получает права объявлять догадку фактом.

Нейросеть полезна в подготовке, когда ей дают узкую работу:

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

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

Вот чего нейросеть не даёт:

В итоге встреча становится короче за счёт вынесенной подготовки. Клиент тратит внимание на то, что без него действительно нельзя решить.

Готовый промпт для подготовки вопросов клиенту

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

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

Контекст проекта:
- Продукт или компания: [НАЗВАНИЕ]
- Цель разговора: [ОДИН РЕЗУЛЬТАТ РАЗГОВОРА]
- Что клиент хочет изменить: [ЗАПРОС КЛИЕНТА]
- Рабочая версия продукта: [ССЫЛКА ИЛИ СЛОВО НЕТ]
- Переданные документы: [СПИСОК ДОКУМЕНТОВ]
- Публичные страницы: [СПИСОК ССЫЛОК]
- Допустимые источники: [ПЕРЕЧЕНЬ ИСТОЧНИКОВ]
- Запрещённые источники: [ПЕРЕЧЕНЬ ИЛИ СЛОВО НЕТ]
- Ограничения проекта: [СРОКИ, БЮДЖЕТ, ДОСТУПЫ И ПРАВИЛА, ЕСЛИ ОНИ ИЗВЕСТНЫ]
- Цена ошибки: [ЧТО ПРОИЗОЙДЁТ ПРИ НЕВЕРНОМ ВЫВОДЕ]

Правила работы:

1. Используй только предоставленные материалы и наблюдаемое поведение продукта.
2. Не додумывай аудиторию, функции, результаты, мотивы команды, ограничения и причины решений.
3. Для каждого факта укажи конкретное основание: документ, страницу, экран, поле или наблюдаемый шаг.
4. Если основания нет, пометь утверждение как гипотезу.
5. Если источники расходятся, не выбирай победителя самостоятельно. Запиши расхождение отдельным пунктом.
6. Не задавай клиенту вопрос, если ответ уже есть в доступном источнике.
7. Не проси клиента пересказывать сайт, документацию, тарифы или работающий сценарий.
8. Вопрос о существующей функции сначала преврати в проверку продукта.
9. Вопрос о различии между новой идеей и текущим продом задавай только после самостоятельного сравнения.
10. Не предлагай решения до фиксации текущего состояния.
11. Не считай наличие функции доказательством её востребованности или эффективности.
12. Не выполняй внешние действия и не меняй данные.
13. Если информации недостаточно, напиши не знаю и укажи, чем это можно проверить.
14. Сохраняй формулировки клиента дословно только тогда, когда они даны во входных материалах.
15. Не используй кавычки для собственных формулировок.

Сначала составь таблицу фактов со столбцами:
- Факт
- Основание
- Статус проверки: подтверждено, противоречие или неизвестно
- Влияет на решение: да или нет

Затем составь таблицу сравнения текущего продукта и запроса клиента:
- Элемент
- Что уже есть в проде
- Что предлагается изменить
- Подтверждённое различие
- Что пока неизвестно

После этого раздели возможные вопросы на три группы.

Группа 1. Не задавать клиенту.
Включи сюда вопросы, ответы на которые уже найдены. Для каждого укажи найденный ответ и основание.

Группа 2. Проверить самостоятельно.
Включи сюда вопросы, для которых нужен дополнительный просмотр продукта, документа или данных. Для каждого укажи точное действие проверки.

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

Для каждого вопроса из группы 3 укажи:
- Зачем он нужен
- Какое решение изменит ответ
- Что уже известно до вопроса
- Короткую формулировку без канцелярита

В финале выдай:
1. Краткое описание текущего состояния продукта.
2. Подтверждённые отличия нового запроса от прода.
3. Список противоречий.
4. Список неизвестного.
5. Не более [МАКСИМАЛЬНОЕ ЧИСЛО] вопросов клиенту.
6. Первый вопрос, с которого стоит начать разговор.
7. Решения, которые нельзя принимать без ответа клиента.
8. Проверки, которые нужно выполнить после разговора.

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

Как проверить, что подготовка больше не сломается

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

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

Первая - проверка источника. У каждого утверждения есть место, откуда оно взято. Если места нет, перед нами неизвестное или гипотеза.

Вторая - проверка самостоятельности. Можно ли получить ответ без клиента? Если можно, вопрос возвращается исследователю.

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

Четвёртая - проверка статуса. Не описывается ли концепт как работающий продукт? Не превращается ли цель в достигнутый результат?

Пятая - проверка прода. Сравнивал ли исполнитель новую идею с реальной версией или только с её кратким описанием?

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

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

Что ты уносишь

Коротко: клиент больше не должен быть поисковой строкой для исполнителя.

Главное правило можно применить к продаже, разработке, маркетингу и консалтингу:

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

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

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

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

Другие примеры того, как я превращаю такие правила в проверяемые рабочие контуры, собраны на Витрине кейсов.

Если хотите пересобрать интервью под свой продукт

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

Напишите мне в личку кодовое слово «ВОПРОСЫ КЛИЕНТУ».