Interview Me

Интервью с пользователем

Обзор

Самый дешёвый баг — тот, что не написан, потому что нужный вопрос задали до реализации, а не после код-ревью. Этот skill заменяет накопление предположений структурированным интервью: задавай целевые вопросы малыми пачками, скармливай каждый ответ следующему раунду и останавливайся только тогда, когда acceptance criteria можно написать не выдумывая. Он выносит разговор, который иначе случится как rework после ревью, в начало — до того как задача уйдёт профильному агенту.

Когда использовать

• Запрос на одну-две фразы описывает то, что явно больше одной-двух фраз ("добавь оффлайн-режим").
• Требования противоречат друг другу или текущему поведению приложения/бэкенда.
• Возможны несколько трактовок, и ошибиться в выборе дорого (миграция схемы, публичный контракт, необратимое решение — см. также doubt-driven-development, если он у вас появится, либо сразу documentation-and-adrs-практику для фиксации решения).
• Перед тем как отдать задачу business-analyst на проверку acceptance criteria, или профильному инженерному агенту на реализацию.
• Пользователь говорит в духе "ты понимаешь, о чём я" — не понимаешь.

Не используй, если: задача маленькая и однозначная (rename, точечный багфикс с понятной причиной), или acceptance criteria уже заданы явно пользователем/issue/спекой — тогда сразу делегируй по rules/workflow.md. Интервью не должно быть предлогом не начинать работу.

Процесс

Шаг 1. Зафиксируй, что уже понятно

Прежде чем задавать вопросы, письменно зафиксируй текущее понимание и уровень уверенности:

## Понимание: оффлайн-очередь мутаций задач
- Пользователь видит закэшированные задачи офлайн — уверенно (сказано явно)
- Пользователь может СОЗДАВАТЬ задачи офлайн — предположение, не сказано
- Стратегия разрешения конфликтов — неизвестно
- Триггер синка (при открытии приложения? WorkManager?) — неизвестно
Уверенность: ~40%

Строки "предположение" и "неизвестно" становятся списком вопросов. Если таких строк не возникло — интервью не требовалось.

Шаг 2. Задавай вопросы малыми целевыми пачками

3–5 вопросов за раунд, самое дорогое решение — первым. Один вопрос — одно решение, конкретные варианты вместо открытых формулировок:

1. Если задачу отредактировали офлайн на двух устройствах, что побеждает при синке — последняя
   запись или конфликт показывается пользователю?
2. Создание задач должно работать офлайн, или в v1 офлайн — только чтение?
3. Синк по открытию приложения или фоновый через WorkManager (с учётом Doze/App Standby)?
4. Что происходит с несинканными офлайн-изменениями при логауте?

Правила вопросов:

• Спрашивай про поведение, которое видит пользователь, а не про реализацию ("что побеждает?", а не "OT или CRDT?").
• Предлагай дефолт: "Предлагаю last-write-wins для v1 — годится?" — легко подтвердить, легко поправить.
• Поднимай платформенные реалии, которые заказчик может не знать: фоновые ограничения (Doze, WorkManager retry/backoff), KMP-паритет поведения между Android и iOS (если фича общая для shared/), реконнект realtime-канала (SignalR) после разрыва сети, требования Google Play/App Store review.
• Никогда не переспрашивай то, что уже закрыл предыдущий ответ.

Шаг 3. Скорми ответы обратно и итерируй

После каждого раунда обнови документ понимания — перескажи ответы своими словами, отметь закрытые пункты, дай новым вопросам возникнуть из ответов:

Закрыто: офлайн-чтение и создание в v1; last-write-wins; синк по открытию приложения.
Новый вопрос из "last-write-wins": тихая потеря данных при конфликте — ок, или логировать для
саппорта?
Уверенность: ~80%

Шаг 4. Останавливайся на ~95% и передавай дальше

Выходи из интервью, когда каждый acceptance criterion можно написать не выдумывая. Идеальная уверенность — не цель; оставшиеся ~5% фиксируются как явные предположения:

Предположения (продолжаем, пока не поправят):
- Конфликты достаточно редки, чтобы тихий last-write-wins был приемлем для v1.

Передай результат дальше по rules/workflow.md: если решение архитектурное или необратимое — сначала business-analyst на проверку с продуктовой стороны и/или ADR по documentation-and-adrs-практике; реализацию отдай профильному агенту (kotlin-engineer, compose-builder, swift-engineer, swiftui-builder) вместе с документом понимания как частью постановки задачи — не как отдельное сообщение, которое потеряется в чате. Для оффлайн-очереди из примера выше следующий шаг обычно — create-offline-outbox.

Типичные отговорки

Красные флаги

• Реализация начата, а документ понимания всё ещё содержит "неизвестно" по ключевому поведению.
• Вопросы про детали реализации, а не про видимое пользователю поведение.
• Задача делегирована профильному агенту с нерешённой неоднозначностью вместо того, чтобы закрыть её в main-сессии до делегирования.
• Один и тот же вопрос задан дважды, потому что ответ не зафиксировали.
• Ноль зафиксированных предположений в задаче, где неоднозначность точно была (значит, их сделали молча).
• Стена из двадцати вопросов одним сообщением.
• "Интервью" продолжается после того, как acceptance criteria уже можно написать — это уже затягивание, а не уточнение.

Чек-лист

• Документ понимания существует и явно делит пункты на подтверждённые / предположенные / неизвестные.
• Каждое видимое пользователю поведение закрыто ответом или явным предположением — без тихих пробелов.
• Оставшиеся предположения записаны и показаны пользователю, а не оставлены только в голове агента.
• Acceptance criteria можно сформулировать, ничего не выдумывая.
• Платформенные ограничения стека (Doze/WorkManager, KMP-паритет Android/iOS, реконнект realtime, Play/App Store review) подняты там, где релевантны.
• Результат передан дальше как часть постановки задачи для business-analyst и/или профильного агента — по rules/workflow.md, а не потерян в чате.