Interview Me

Проинтервьюируй меня

Обзор

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

Самый дешёвый момент найти этот разрыв — до того, как появились план, спека или код. Как только стройка началась, издержки переключения становятся реальными, и пользователь рационализирует неправильную вещь до состояния «ну, сойдёт». Несоответствие фиксируется навсегда.

Этот скилл закрывает разрыв, пока он ничего не стоит. Остальные скиллы фазы «Определение» предполагают, что ты уже примерно знаешь, чего хочешь: idea-refine порождает варианты из идеи, spec-driven-development записывает требования, doubt-driven-development проверяет план на прочность после того, как ты его набросал. Interview-me — это то, что идёт до всего этого: ты задаёшь по одному вопросу за раз, приложив свою лучшую догадку, пока не сможешь предсказать ответ пользователя раньше, чем он его произнесёт.

Когда применять

Применяй этот скилл, когда:

• В запросе отсутствует хотя бы одно из: кто пользователь, зачем ему это, как выглядит успех, какое ограничение является связывающим
• Запрос конвенциональный, а не конкретный («сделай мне X», «сделай быстрее»), и ты не можешь распаковать конвенцию, не гадая
• Тебя тянет начать с допущений, которые ты не проговорил
• Пользователь не сказал, какую ценность оптимизирует, когда две разумные ценности в противоречии (простота против гибкости, стоимость против скорости)
• Пользователь явно вызывает: «проинтервьюируй меня», «допроси меня», «перед стартом — мы точно уверены?», «проверь моё мышление на прочность»

Когда НЕ применять:

• Запрос однозначен и самодостаточен («переименуй эту переменную», «исправь эту опечатку»)
• Пользователь явно попросил скорость вместо проверки
• Чисто информационные запросы («как работает X?», «что делает этот код?»)
• Механические операции (переименования, форматирование, перемещение файлов)
• У тебя уже ≥95% уверенности; перечитай условие остановки ниже, прежде чем решить, что это не так

Ограничения загрузки

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

Процесс

Шаг 1: выдвини гипотезу с числом уверенности

Прежде чем что-либо спрашивать, запиши своё текущее лучшее прочтение того, чего хочет пользователь, одним предложением, плюс честное число уверенности (0–100%):

ГИПОТЕЗА: вам нужен способ отвечать на вопрос «как у нас дела?» на стендапе, а «дашборд» — это первая пришедшая в голову конвенция.
УВЕРЕННОСТЬ: ~30% — не хватает: для кого это, что значит «метрики» в этом контексте и как выглядит успех

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

Когда уверенность ниже ~70%, добавь в той же строке краткую причину — что осталось неразрешённым или отсутствует. Это точно говорит пользователю, что интервью должно вытащить наружу, и не даёт числу быть размытым сигналом.

Шаг 2: задавай по одному вопросу за раз, к каждому прикладывай догадку

Формат:

В: <один сфокусированный вопрос>
ДОГАДКА: <твоя гипотеза ответа с рассуждением, которое к ней привело>

Дождись реакции пользователя, прежде чем задавать следующий вопрос.

Почему по одному, а не пачкой:

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

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

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

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

Шаг 3: слушай, где «хочу» расходится с «должен хотеть»

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

• Ответами, попадающими в шаблон разговоров о лучших практиках («хочу, чтобы это масштабировалось», «чистая архитектура») без конкретики
• Ответами со ссылкой на конвенцию («как это делает большинство приложений», «стандартный подход»)
• Оборотами вроде «наверное, надо бы…», «кажется, я должен…», «хорошая инженерная практика говорит…»
• Модными словами вместо целей — когда ответ это «современный», «масштабируемый», «надёжный» вместо конкретного результата

Услышав такое, задавай вопрос:

«Если бы вам не нужно было ни перед кем это обосновывать, чего бы вы хотели на самом деле?»

Один этот вопрос часто делает больше, чем предыдущие пять.

Шаг 4: перескажи намерение словами пользователя

Когда уверенность высока, напиши обратно то, чего, как ты теперь считаешь, хочет пользователь. Держи кратко (5–8 строк), по возможности используй его язык и структурируй так, чтобы можно было подтвердить или поправить построчно:

Вот что, как я теперь понимаю, вам нужно:

- Результат:       <одна строка>
- Пользователь:    <одна строка — кому это выгодно>
- Почему сейчас:   <одна строка — что изменилось>
- Успех:           <одна строка — как поймём, что сработало>
- Ограничение:     <одна строка — связывающий предел>
- Вне границ:      <одна строка — что мы явно не делаем>

Да / нет / уточнить?

Строка «Вне границ» не обсуждается. Половина рассогласования — это молчаливое несогласие о том, что не строится.

Шаг 5: подтверждение — явное «да», а не «делай как считаешь нужным»

Ворота — это явное «да». Вот что «да» не является:

• «Делай как считаешь нужным.» → Пользователь делегирует, а значит и у него нет 95% уверенности. Переспроси, предложив выбор из двух конкретных вариантов.
• «Звучит хорошо.» → Неоднозначно. Спроси: «Что бы вы уточнили?» Молчание не подтверждение.
• «Ага, погнали.» → Часто вежливый выход из разговора, а не одобрение. Тот же уточняющий вопрос.
• Молчание, а затем «ладно, начинаем». → Пользователь сдался в интервью, а не сошёлся с тобой. Остановись и спроси, не упустил ли ты чего-то.

Если тебя поправляют — впиши поправку и перескажи заново. Повторяй, пока не получишь явное «да».

Остановка на 95% уверенности

Ты закончил, когда можешь ответить «да» на вопрос:

Могу ли я предсказать реакцию пользователя на следующие три вопроса, которые я бы задал?

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

Это проверяемый тест, а не ощущение. У него есть и нижняя граница: если ты прошёл несколько раундов и всё ещё не можешь предсказывать, это информация о самом запросе, а не повод молотить дальше. Остановись и скажи пользователю: «Я задал X вопросов и всё ещё не могу предсказать ваши реакции. Чего-то основополагающего не хватает. Отойдём на шаг назад?»

Результат

Результат этого скилла — подтверждённая формулировка намерения: пересказ из шага 4 с явным «да» из шага 5. Это и есть поставляемый артефакт. Спеки, планы и списки задач идут ниже по потоку, они потребляют намерение, которое произвёл этот скилл.

Если пользователь хочет, чтобы намерение сохранилось (многосессионный проект, передача другому участнику), предложи сохранить его в docs/intent/[topic].md. Сохраняй только при подтверждении.

Пример

Короткое «до и после».

Без interview-me:

Пользователь: сделай мне дашборд для наших метрик
Агент: <начинает предлагать библиотеки графиков и варианты вёрстки>

Агент предположил: для кого это, какие метрики, что значит «наши», как выглядит успех. Ничего из этого не сказано. Каждое допущение — место, где пользователь потом скажет «я не это имел в виду».

С interview-me:

Пользователь: сделай мне дашборд для наших метрик

Агент:
ГИПОТЕЗА: вам нужен способ отвечать на «как у нас дела?» на стендапе, а «дашборд» пришёл в голову, потому что так принято отвечать.
УВЕРЕННОСТЬ: ~30% — не хватает: для кого это, что за «метрики» и как выглядит успех

В:       Когда вы говорите «как у нас дела?», кто спрашивает — вы сами, инженерная команда на стендапе или наверх по цепочке (руководитель, топ-менеджер, совет директоров)?
ДОГАДКА: инженерная команда на стендапе, потому что «мы» обычно означает именно это, а стендап — место, где такой вопрос и задают. Если это для топ-менеджеров, метрики и подача сильно меняются.

Пользователь: На самом деле это для меня. Я всё время теряю нить, какие эксперименты запущены и какой у них ранний сигнал.

Агент:
Обновлённое прочтение: это вообще не командный дашборд. Это личный трекер экспериментов. Уверенность: ~60% — всё ещё не хватает: что значит «ранний сигнал» и как выглядит «готово».

В:       Проблема в том, что вы не знаете, какие эксперименты существуют, или в том, что не видите их результаты в одном месте?
ДОГАДКА: второе. Список экспериментов у вас где-то есть, но их результаты живут в пяти разных инструментах, и сводить их руками вы устали.

Пользователь: Первое, на самом деле. У меня буквально нет списка. Они разбросаны по разным документам.

Агент: <продолжает>

Через два вопроса агент выяснил, что настоящий запрос — не «дашборд». Это «список». Другой артефакт, другой объём работ, другая работа. Дашборд был бы неверным решением.

Взаимодействие с другими скиллами

• idea-refine: ниже по потоку. Если подтверждённое намерение звучит как «я хочу X, но не знаю, как очертить границы», передавай в idea-refine, чтобы породить варианты уже под явное намерение.
• spec-driven-development: ниже по потоку. Если подтверждённое намерение конкретно («я хочу X для пользователей Y с критериями успеха Z»), передавай в spec-driven-development, чтобы это записать.
• planning-and-task-breakdown: через два шага ниже по потоку (после спеки).
• doubt-driven-development: противоположный конец шкалы времени. Interview-me — извлечение намерения до решения, doubt-driven — ревью артефакта после решения. Оба ловят расхождение, но в разные моменты.
• source-driven-development: ортогонален. Interview-me проясняет, чего хочет пользователь; SDD проверяет факты о фреймворках. Они не конкурируют.

Типовые самооправдания

Тревожные признаки

• Три и более вопроса в одном сообщении — это пачка, а не интервью
• Вопрос без приложенной гипотезы — это опрос, а не позиция
• Принятие «делай как считаешь нужным» в качестве финального ответа
• Выдача спеки, плана или списка задач до явного подтверждения пересказа пользователем
• Вопросы в формулировке «что было бы лучшей практикой?» вместо «чего вы на самом деле хотите?»
• Пользователь даёт ответ, сигнализирующий об искушённости («масштабируемый», «чистый», «современный»), а ты принимаешь его, не проверив, этого ли он на самом деле хочет
• Три и более раунда без заметного роста твоей уверенности — ты задаёшь не те вопросы, отойди и переформулируй
• Уверенность ниже ~70% без приложенной причины — пользователь не может помочь закрыть пробел, если не знает, чего не хватает
• Сохранение документа с намерением до подтверждения пользователем (сам документ подразумевает «да», которого не было)
• Пропуск строки «Вне границ» в пересказе (молчаливое несогласие о не-целях — половина всего рассогласования)

Проверка

После применения interview-me:

• В первом же ходе заявлена явная гипотеза с числом уверенности
• К каждому числу уверенности ниже ~70% приложена однострочная причина (что осталось неразрешённым или отсутствует)
• Вопросы задавались по одному, к каждому приложена догадка агента
• Хотя бы раз прозвучал зондирующий вопрос «чего бы вы хотели, если бы не надо было это обосновывать?» — когда пользователь дал ответ, сигнализирующий об искушённости или конвенции
• Пользователю написан конкретный пересказ (Результат / Пользователь / Почему сейчас / Успех / Ограничение / Вне границ)
• Пользователь подтвердил пересказ явным «да» (не «делай как считаешь», не «звучит хорошо», не молчанием)
• В точке остановки агент мог предсказать реакции на следующие три вопроса, которые он задал бы
• Любая передача скиллу ниже по потоку (idea-refine, spec-driven-development) сформулирована в терминах подтверждённого намерения, а не исходного недоопределённого запроса