---
name: discovery-interview
description: Структурированное интервью-discovery ПЕРЕД проектированием. Два режима. FEATURE — заказчик описывает проблему, боль или цель без готового решения («менеджеры жалуются на…», «сделки теряются», «хочу чтобы…»): JTBD-интервью вскрывает проблему до решения и отдаёт discovery-brief в brainstorming. SYSTEM — запрос ориентации по проекту («сориентируй», «где мы сейчас», «что в тулчейне / на карте», «catch-up по…»): синтез по мета-слою (карта, CLAUDE.md, MEMORY, Открытые_вопросы, Tooling, git log). SKIP — чёткий директив на реализацию («интегрируй X», «закрой находку Y», «поправь Z»): это не discovery. SKIP — анализ бизнес-процесса из кода или диагностика просадки измеримой метрики/конверсии («как устроен процесс X», «process discovery», «где узкое место», «почему просела конверсия»): это skill process-analysis. Используй при «discovery interview», «проведи discovery», «сориентируй по проекту» и при расплывчатом проблемном запросе, даже если слово «discovery» не названо.
---

# Discovery Interview

Структурированное интервью, которое вскрывает **проблему** прежде, чем кто-либо
начнёт проектировать решение. Два режима — FEATURE (интервью заказчика перед
фичей) и SYSTEM (интервью-ориентация по состоянию проекта).

Зачем скил существует: запрос вида «менеджеры жалуются на X» или «хочу, чтобы Y» —
это симптом, не задача. Уйдёшь сразу в дизайн — спроектируешь решение не той
проблемы. Discovery interview удерживает разговор в проблемном поле ровно столько,
сколько нужно, чтобы понять *настоящую* потребность, и только потом передаёт
эстафету проектированию.

## Когда какой режим

| Запрос | Действие |
|---|---|
| Заказчик описал проблему / боль / цель без решения | режим **FEATURE** |
| Заказчик просит сориентировать по проекту | режим **SYSTEM** |
| Заказчик дал чёткий директив («сделай X», «интегрируй Y») | скил не нужен — работай напрямую |
| Вопрос про устройство бизнес-процесса из кода | скил `process-analysis`, не этот |

## Несущий принцип — три слоя-источника

Этот скил соседствует со скилом `process-analysis` (раздел C10 карты). Чтобы не
дублировать его, способности разведены по **слою данных**, с которым работают:

| Способность | Слой-источник | Метод |
|---|---|---|
| `process-analysis` | app-код — `routes/`, `app/Jobs`, `audit_*` | реконструкция бизнес-процесса из кода |
| discovery-interview **FEATURE** | голова заказчика | интервью человека |
| discovery-interview **SYSTEM** | мета-слой — карта, CLAUDE.md, MEMORY, Открытые_вопросы, Tooling, git log | интервью + синтез |

Правило разведения: если ответ добывается **чтением кода** — это `process-analysis`.
Если ответ лежит в голове заказчика или в управляющих документах — это
discovery-interview.

## Режим FEATURE

### Триггер

Заказчик описывает проблему, боль, раздражение или цель — но НЕ готовое решение.
Признаки: «менеджеры жалуются…», «X теряется», «неудобно делать Y», «хочу, чтобы…»,
«было бы хорошо, если…».

### SKIP

Не запускай FEATURE, если запрос — чёткий директив на реализацию: «интегрируй X»,
«закрой находку Y», «поправь Z», «добавь endpoint». Проблема уже понята заказчиком,
discovery только затормозит. Работай напрямую — или через `brainstorming`, если
дизайн решения нетривиален.

Не запускай FEATURE и если запрос — **диагностика просадки измеримой метрики или
конверсии** («почему падает конверсия B2», «где теряем в воронке», «почему лиды не
доходят до оплаты»). Ответ там добывается анализом кода и audit-данных — это скил
`process-analysis`. FEATURE — про UX-боль и желаемые возможности, не про диагностику
чисел.

### Процесс

1. **Один вопрос за раз.** Не вываливай список — это интервью, не анкета. Ответ на
   первый вопрос определяет второй.
2. **Спрашивай про прошлое поведение, не про гипотетику.** «Расскажи, как ты делал
   это в последний раз» сильнее, чем «как бы ты хотел». Люди плохо предсказывают
   своё поведение и точно помнят прошлое.
3. **Копай до корня — «5 почему».** Первая названная проблема обычно симптом.
4. **Не задавай наводящих вопросов.** «Тебе мешает отсутствие фильтра?» подсказывает
   ответ. Спроси открыто: «что именно замедляет тебя на этом экране?».
5. **Поняв проблему — собери discovery-brief и остановись.** Не проектируй решение —
   это работа `brainstorming`.

Банк вопросов по шагам JTBD — `references/jtbd-questions.md`.

### Артефакт — discovery-brief

Проблема · JTBD (какую работу заказчик «нанимает» решение сделать) · Текущий обходной
путь · Цена боли (время / деньги / частота) · Сигнал успеха (как поймём, что закрыто)
· Ограничения. Шаблон — `docs/discovery/templates/discovery-brief.md`.

### Хэндофф

discovery-brief — это вход для `brainstorming`. Передай brief как готовую проблемную
секцию: `brainstorming` берёт её и переходит к решению — он **не перезадаёт** уже
выясненные вопросы. discovery-interview отвечает за «что за проблема», brainstorming —
за «что построим». Отдельным файлом FEATURE-brief не сохраняется — он вливается в
спеку brainstorming.

## Режим SYSTEM

### Триггер

Заказчик просит сориентировать его по состоянию проекта: «сориентируй», «где мы
сейчас», «что у нас по X», «что в тулчейне / на карте», «catch-up».

### SKIP

Не запускай SYSTEM, если вопрос про устройство **бизнес-процесса** («как устроен
процесс сделок», «process discovery», «где узкое место в воронке») — это скил
`process-analysis`, он читает код. SYSTEM отвечает на «где мы в проекте», не «как
работает процесс X».

### Процесс

1. **Короткое уточнение scope** — что именно ориентировать? Весь проект, конкретный
   раздел, тулчейн, открытые вопросы? Без scope ответ будет рыхлым.
2. **Синтез по мета-слою:** карта `docs/automation-graph.html`, `CLAUDE.md`, MEMORY,
   `docs/Открытые_вопросы_*.md`, `docs/Tooling_*.md`, `git log`.
3. **Запрет:** не читай `app/`-код для реконструкции процессов — это исключительный
   метод `process-analysis`. SYSTEM работает только с мета-слоем.
4. **Выдай синтез**, а не пересказ документа целиком — ответ на запрос ориентации с
   пинами на источники.

### Артефакт — system-snapshot

Если ориентация существенная — сохрани `docs/discovery/YYYY-MM-DD-<тема>.md` по
шаблону `docs/discovery/templates/system-snapshot.md`. Мелкий устный ответ файла не
требует.

## JTBD-дисциплина (общая для обоих режимов)

- **Один вопрос за раз** — интервью, не анкета.
- **Прошлое, не гипотетика** — «когда это случилось в последний раз?».
- **«5 почему»** — корень, не симптом.
- **Не наводи** — открытые вопросы, без подсказанного ответа.
- **Слушай, не защищай** — если заказчик критикует существующее, не оправдывай его,
  копай дальше.

## Границы

- **`brainstorming`** — проектирование решения. discovery-interview вскрывает проблему
  и передаёт brief; brainstorming проектирует. Не дублируй его вопросы.
- **`process-analysis`** (раздел C10) — анализ as-is бизнес-процесса из кода и
  диагностика метрик/конверсии. Если ответ требует чтения `routes/` / `app/Jobs` /
  `audit_*` или расчёта метрик процесса — это `process-analysis`, не этот скил.
- **`audit-portal`** — качественный вердикт о здоровье портала. SYSTEM даёт
  ориентацию («где мы»), не вердикт («здорово ли»).
- **Интервью конечных пользователей Лидерры** — вне этого скила (defer post-Б-1; для
  методологии user research — `design:user-research`).
