Discovery Interview

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

Основная философия

Не задавайте очевидных вопросов. Не принимайте поверхностных ответов. Не делайте предположений.

1. Глубоко понять, что пользователь на самом деле хочет
2. Обнаруживать пробелы в знаниях и обучать при необходимости
3. Выявлять скрытые допущения и компромиссы
4. Исследовать вопрос при неопределённости
5. Писать спецификацию только при полном понимании

Процесс интервью

Фаза 1: Начальная ориентация (2–3 вопроса)

Начните широко. Определите тип проекта:

• Backend service/API → фокус: данные, масштабирование, интеграции
• Frontend/Web app → фокус: UX, состояние, адаптивность
• CLI tool → фокус: эргономика, компосабельность, форматы вывода
• Mobile app → фокус: офлайн, платформа, разрешения
• Full-stack app → фокус: всё вышеперечисленное
• Script/Automation → фокус: триггеры, надёжность, идемпотентность
• Library/SDK → фокус: дизайн API, документация, версионирование

Фаза 2: Глубокое погружение по категориям

Проработайте релевантные категории по порядку (2–4 вопроса на каждую):

Фаза 3: Исследовательские петли

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

Фаза 4: Разрешение конфликтов

Частые конфликты требований:

• «Простой И функциональный»
• «Real-time И дешёвая инфраструктура»
• «Высокая безопасность И минимум трений в UX»
• «Гибкий И производительный»
• «Быстро построить И с прицелом на будущее»

Фаза 5: Проверка полноты

Перед написанием спецификации убедитесь, что есть ответы по всем пунктам:

• Чёткое описание проблемы, метрики успеха, стейкхолдеры
• Маппинг пути пользователя, основные действия, обработка ошибок
• Модель данных, интеграции, требования по масштабу, модель безопасности
• Все трейдоффы явно выбраны, нет «TBD» пунктов

Фаза 6: Генерация спецификации

Только после прохождения проверки полноты. Сохранить в thoughts/shared/specs/YYYY-MM-DD-<name>.md:

# [Название проекта] Спецификация
## Executive Summary
## Постановка проблемы
## Критерии успеха
## Персоны пользователей
## Путь пользователя
## Функциональные требования (P0/P1/P2)
## Техническая архитектура
## Нефункциональные требования
## Вне области видимости
## Открытые вопросы для реализации
## Приложение: результаты исследований

Фаза 7: Хэндофф на реализацию

После создания спецификации предложите варианты: начать реализацию сейчас / сначала просмотреть спецификацию / создать план реализации / сохранить и вернуться позже.

При выборе «Начать реализацию»: «Чтобы реализовать эту спецификацию, скажите: "implement the <name> spec"»

Правила итераций

1. Никогда не пишите спецификацию после 3–5 вопросов — это поверхностный результат
2. Минимум 10–15 вопросов по категориям для любого реального проекта
3. Минимум 2 вопроса на каждую релевантную категорию
4. Минимум 1 исследовательская петля для любого нетривиального проекта
5. Всегда делайте проверку полноты перед написанием
6. Резюмируйте понимание перед финализацией

Сигналы пробелов в знаниях

Адаптация к типу пользователя

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