---
name: mvp-scope
description: Используй при детализации MVP Scope на основе Project Brief. Структурированное исследование пользовательских сценариев, приоритетов и критериев готовности.
---

# MVP Scope: детализация

## Цель

Превратить Project Brief в детальный MVP Scope с конкретными пользовательскими сценариями, приоритетами и критериями готовности через структурированный диалог.

## Входные данные

Перед началом прочитай `docs/PROJECT_BRIEF.md`. Если файл не найден — сообщи пользователю и предложи сначала создать Project Brief.

## Процесс

### Фаза 1: Валидация понимания

Кратко перескажи суть Project Brief (3-4 предложения) и спроси:

1. "Я правильно понимаю суть проекта? Что-то изменилось с момента написания Brief?"

### Фаза 2: Декомпозиция фич на сценарии

Для каждой фичи из раздела «Входит» в Project Brief задавай ПО ОДНОМУ вопросу. Жди ответа перед следующим.

2. "Возьмём [фича]. Опиши конкретный сценарий: пользователь хочет [цель] — какие шаги он проходит от начала до результата?"
3. "Есть ли в этом сценарии альтернативные пути? Что если [вариант A] или [вариант B]?"
4. "Какой минимальный вариант этого сценария уже приносит пользу? Что можно упростить, а что нельзя?"

Повтори вопросы 2-4 для каждой фичи. Предлагай свои варианты сценариев, если пользователь затрудняется.

### Фаза 3: Приоритизация

Когда все сценарии собраны:

5. "Вот все сценарии, которые мы обсудили: [список]. Какие из них критичны для первого запуска, а какие можно добавить итерацией?"
6. "Если бы ты мог показать MVP только с тремя сценариями — какие это были бы?"
7. "Есть ли технические или бизнес-ограничения, которые влияют на порядок реализации?"

### Фаза 4: Критерии готовности

8. "Для каждого сценария — как понять, что он реализован? Что конкретно пользователь должен увидеть или получить?"
9. "Есть ли нефункциональные требования, которые критичны уже для MVP? Например: скорость отклика, количество одновременных пользователей, работа офлайн?"

### Фаза 5: Риски и зависимости

10. "Какой сценарий кажется самым сложным технически? Почему?"
11. "Есть ли внешние зависимости, которые могут заблокировать реализацию?"

### Фаза 6: Формирование документа

Когда все ответы собраны — представь MVP Scope блоками по 200-300 слов. После каждого блока спрашивай: "Эта часть выглядит верно?" Будь готов вернуться и уточнить, если что-то не сходится.

## Результат

После валидации всех блоков создай файл `docs/MVP_SCOPE.md`:

```markdown
# MVP Scope: [Название проекта]

## Обзор

[Краткое описание цели MVP и ключевой ценности для пользователя. 2-3 предложения]

## Пользовательские сценарии

### Сценарий 1: [Название]

**Приоритет:** Критичный / Важный / Желательный

**Описание:** [Что пользователь хочет сделать и зачем. 1-2 предложения]

**Основной поток:**
1. [Шаг 1]
2. [Шаг 2]
3. [Шаг N]

**Альтернативные пути:**
- [Если условие X — то Y]

**Критерий готовности:** [Как понять, что сценарий реализован]

### Сценарий N: [Название]

[Аналогичная структура]

## Нефункциональные требования MVP

- [Требование 1 — конкретная метрика или ограничение]
- [Требование N]

## Упрощения и допущения

[Что сознательно упрощено в MVP по сравнению с полным видением.
Какие допущения сделаны. 3-5 пунктов]

## Риски и зависимости

| Риск / зависимость | Влияние | Митигация |
|---|---|---|
| [Описание] | [Высокое / Среднее / Низкое] | [Что делаем] |

## Порядок реализации

[Рекомендуемая последовательность реализации сценариев с обоснованием.
Какие сценарии можно делать параллельно]
```

## Ключевые принципы

- **Один вопрос за раз** — не перегружай собеседника множеством вопросов
- **Варианты ответов предпочтительнее** — предлагай 2-3 варианта, на них проще отвечать
- **Конкретика вместо абстракций** — требуй примеры, шаги, метрики
- **Челлендж «хочу всё»** — заставляй выбирать приоритеты, MVP не может включать всё
- **Сценарии вместо фич** — фича «дашборд» ничего не значит, а «пользователь видит статус всех модулей» — значит
- **Критерии готовности обязательны** — каждый сценарий должен иметь проверяемый критерий
- **Инкрементальная валидация** — представляй документ блоками, проверяй каждый
- **Будь гибким** — возвращайся и уточняй ранние решения, если что-то не сходится