---
name: project-brief
description: Используй при создании Project Brief, определении идеи проекта или уточнении scope. Структурированное исследование проблемы, пользователя, решения и границ MVP.
---

# Project Brief: мозговой штурм

## Цель

Превратить размытую идею проекта в сфокусированный Project Brief на 2-3 страницы через структурированный диалог.

## Процесс

### Фаза 1: Исследование проблемы

Задавай вопросы ПО ОДНОМУ. Жди ответа перед следующим вопросом.

1. "Опиши ситуацию: кто сейчас сталкивается с этой проблемой и как справляется без твоего решения?"
2. "Что в этом плохого? Почему текущий способ не устраивает?"
3. "Как часто это происходит? Насколько это больно по шкале от 1 до 10?"

Если пользователь не может сформулировать проблему, спроси: "Забудь про решение. Расскажи историю конкретного человека, у которого что-то не получается."

### Фаза 2: Уточнение пользователя

4. "Кто конкретно твой пользователь? Не 'все фермеры', а какой именно фермер?"
5. "В каком контексте он столкнётся с твоим продуктом? Где, когда, с какого устройства?"
6. "Что этот человек уже пробовал? Почему не сработало?"

### Фаза 3: Определение решения

7. "Теперь расскажи своё решение. Что система ДЕЛАЕТ (не как устроена внутри)?"
8. "Пользователь открыл приложение. Что он делает первым? Что вторым? Что видит в результате?"
9. "Чем это лучше того, как он справляется сейчас?"

### Фаза 4: Границы MVP

10. "У тебя 2 недели на первую версию. Какие 2-3 функции обязательны, чтобы решить главную проблему?"
11. "Что хочется добавить, но можно отложить на потом?"
12. "Есть ли внешние зависимости или интеграции, без которых MVP не работает?"

### Фаза 5: Критерии успеха

13. "Представь: продукт готов. Как ты покажешь, что он работает? Опиши один конкретный сценарий от начала до конца."
14. "Как поймёшь, что пользователь доволен? Что он скажет или сделает?"

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

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

## Результат

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

```markdown
# Project Brief: [Название]

## Проблема

[Описание текущей ситуации: кто, что делает, почему это плохо. 
Конкретная история или пример. 4-5 предложений]

## Пользователь

[Кто именно, в каком контексте, какой опыт. 
Что уже пробовал, почему не подошло. 4-5 предложений]

## Решение

[Что продукт делает для пользователя. Основной сценарий использования.
Ключевое отличие от существующих альтернатив. 5-6 предложений, без технических деталей]

## Границы MVP

**Входит:**
- [функция 1 — краткое описание]
- [функция 2 — краткое описание]
- [функция 3 — краткое описание]

**Не входит (на потом):**
- [отложенное 1]
- [отложенное 2]

**Зависимости и интеграции:**
- [если есть внешние API, сервисы, данные]

## Критерии успеха

[Конкретный сценарий: пользователь X делает Y, получает Z.
Как понять, что цель достигнута. 3-4 предложения]
```

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

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