Discovery Interview

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

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

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

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

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

Фаза 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 вопроса на каждую):

Категория	Ключевые вопросы	Сигналы пробелов
A: Проблема и цели	Текущая боль? Как измерить успех? Стейкхолдеры?	Описывает решение вместо проблемы
B: UX и путь пользователя	Что делает новый пользователь? Основное действие? Обработка ошибок?	Описывает фичи вместо сценариев
C: Данные и состояние	Что хранить? Откуда данные? Кто владелец? Приватность?	«Просто базу данных» без понимания схемы
D: Технический стек	Существующие системы? Ограничения? Среда деплоя? Экспертиза команды?	Выбирает технологии без понимания трейдоффов
E: Масштаб и производительность	Сколько пользователей? Допустимое время ответа? Поведение при пиках?	«Миллионы пользователей» без понимания инфраструктуры
F: Интеграции	Внешние сервисы? API? Фолбек при сбоях? Аутентификация?	Считает интеграции простыми без понимания rate limits
G: Безопасность и доступ	Кто что может делать? Чувствительные данные? Соответствие требованиям?	«Просто базовый логин» без понимания безопасности
H: Деплой и операции	Как деплоить? Мониторинг? Откаты? Disaster recovery?	Не думал про ops, считает что «просто работает»

Фаза 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"»

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

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

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

Сигнал	Действие
«Я думаю...» или «Может быть...»	Углубиться, предложить исследование
«Звучит хорошо» (на ваше предложение)	Убедиться, что понимают последствия
«Просто простой/базовый X»	Уточнить — что значит «простой»
Технические buzzwords без контекста	Спросить, что они думают это означает
Противоречивые требования	Явно обозначить конфликт
«Что угодно стандартное»	Объяснить, что универсального стандарта нет
Долгие паузы / короткие ответы	Упростить — возможно, перегружены

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

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

discovery-interviewинтервью обнаружения Continuous Claude

Установка