questions for calls

This commit is contained in:
Alex Ant
2026-03-28 13:55:19 +05:00
parent b3fa2a5a5b
commit 3c3d3cc8d1
13 changed files with 930 additions and 266 deletions
@@ -0,0 +1,70 @@
# Шесть шляп — вопросы для фасилитатора на созвоне
**Назначение:** нетехническая синхронизация по одной теме. Полный порядок, тайминги и правила — в [`../six-thinking-hats-tutorial.md`](../six-thinking-hats-tutorial.md).
**Порядок блоков:** Синяя (старт) → Белая → Красная → Чёрная → Жёлтая → Зелёная → Синяя (итог). При необходимости — **круги** по туториалу (точечный повтор шляп).
---
## Синяя шляпа — старт
1. Какая **одна** тема сегодня на столе? (одна фраза.)
2. Сколько минут на каждый блок и кто держит таймер?
3. Что на выходе считаем готовым (бриф, список вопросов, решение «идём / не идём»)?
---
## Белая шляпа (только факты)
- Что уже **точно известно** по теме? (данные, решения, факты.)
- Чего **не знаем** и нужно выяснить позже?
- Какие **источники** подтверждают факты?
*Уточняющие (если уходят в оценку):* «Это наблюдение или гипотеза?»
---
## Красная шляпа (эмоции, без доказательств)
- Что **тревожит** лично вас по этой теме?
- Что вызывает **интерес / энтузиазм**?
- Какое **первое интуитивное** чувство по направлению?
*Не спрашивать:* «Почему ты так чувствуешь?» в форме требования аргумента.
---
## Чёрная шляпа (риски, слабые места)
- Что может **пойти не так**?
- Какие **ограничения** и **угрозы** видите?
- Где мы **наиболее уязвимы** (репутация, деньги, регуляторика, сроки)?
---
## Жёлтая шляпа (польза, возможности)
- **Зачем** это кооперативу / пользователям?
- Какие **выгоды** если получится?
- Какие **возможности** открываются?
---
## Зелёная шляпа (идеи, альтернативы)
- **Что ещё можно сделать**, кроме очевидного?
- Какие **обходные пути** для рисков с чёрной шляпы?
- **А что если…** (смелые варианты, без отбора на месте)?
---
## Синяя шляпа — итог
1. Что **зафиксировали** по фактам, рискам, плюсам, идеям?
2. Какие **открытые вопросы** переносим в бриф / следующий созвон?
3. **Кто** и **до когда** делает следующий шаг?
4. Нужен ли **ещё один круг** (какие шляпы, сколько минут)?
---
*Основано на методе де Боно и на `bmad-c9s/six-thinking-hats-tutorial.md`.*
@@ -0,0 +1,99 @@
# Мозговой штурм — вопросы (Creative Intelligence / brainstorm)
**Источник:** `bmad-v6/commands/brainstorm.md`
**Порядок:** цель и контекст → выбор 2–3 техник → **циклы** по техникам → группировка итогов (на созвоне можно упростить до 1–2 техник).
---
## Часть 1. Рамка (один проход)
**Q1.** О чём мы **мозгуем**? (тема одной фразой + примеры: идеи фич, решение проблемы, улучшение процесса, снятие рисков.)
**Q2.** **Контекст:** фаза проекта, ограничения (бюджет, срок, технологии), что уже пробовали, критерий успеха сессии.
**Q3.** Какой **желаемый результат**? (например: список из N идей, 3–5 жизнеспособных решений, карта рисков, альтернативы текущему подходу.)
---
## Часть 2. Выбор техник (фасилитатор объявляет)
Под задачу выбрать **23** из списка:
- Исследование проблемы: **5 Why**, **Starbursting**, **шесть шляп**
- Генерация решений: **SCAMPER**, mind map, brainwriting
- Риски: **обратный мозговой штурм**, чёрная шляпа, **SWOT**
- Стратегия: **SWOT**, mind map, starbursting
---
## Часть 3. Техника «5 Why» ⟳
**Цикл:** для сформулированной проблемы повторять, пока есть смысл (до ~5 раз):
- **Почему** это происходит / важно? → ответ
- **Почему** (следующий уровень)? → …
**Фиксировать:** корневая причина одной фразой.
---
## Часть 4. Техника SCAMPER ⟳
По каждому пункту задать вопрос к объекту/процессу:
1. **Substitute** — что можно **заменить**?
2. **Combine** — что **объединить**?
3. **Adapt** — что **адаптировать** из другого места?
4. **Modify** — что **изменить** в масштабе/форме?
5. **Put to other uses** — куда ещё **применить**?
6. **Eliminate** — что **убрать**?
7. **Reverse** — что если **наоборот**?
---
## Часть 5. Обратный мозговой штурм ⟳
- Как гарантированно **провалить** этот проект / процесс?
- Затем: что из списка **обратить** в меры предосторожности?
---
## Часть 6. Starbursting ⟳
По теме пройти вопросы:
- **Кто** вовлечён / пострадает / платит?
- **Что** конкретно делаем / не делаем?
- **Где** происходит (каналы, площадки)?
- **Когда** критичные моменты и сроки?
- **Почему** это нужно именно так?
- **Как** реализуем по шагам (грубо)?
---
## Часть 7. SWOT ⟳
- **Сильные стороны** (внутренние)?
- **Слабые стороны** (внутренние)?
- **Возможности** (внешние)?
- **Угрозы** (внешние)?
---
## Часть 8. Brainwriting (раунды) ⟳
**Раунд 1 (например, 5 мин):** каждый молча накидывает N идей.
**Раунд 2:** развить чужие идеи + новые.
**Раунд 3:** объединить и уточнить.
---
## Часть 9. После техник
1. Как **сгруппировать** идеи по смыслу?
2. Что **дубли** — объединить?
3. Какие **3–7 ключевых инсайтов** с высоким влиянием и реалистичностью?
---
*Извлечено из `bmad-v6/commands/brainstorm.md`.*
@@ -0,0 +1,55 @@
# Исследование — вопросы постановки задачи
**Источник:** `bmad-v6/commands/research.md`
На **групповом созвоне** вы **формулируете**, что исследовать и какие вопросы должны получить ответ. Сбор фактов — отдельная работа (ручная или потом агент по вашим ответам здесь).
---
## Q1. Тема исследования
**Что** мы исследуем? (одна формулировка.)
*Примеры:* размер рынка; конкуренты в нише; практики по X; потребности пользователей Y; варианты технологий Z.
---
## Q2. Тип исследования
Что из нижеперечисленного (можно смешанное)?
1. **Рынок** — объём, тренды, рост, сегменты
2. **Конкуренты** — игроки, фичи, позиционирование, пробелы
3. **Техническое** — технологии, паттерны, лучшие практики
4. **Пользователи** — боли, поведение, пути
5. **Смешанное**
---
## Q3. Конкретные вопросы ⟳
Перечислите **37** ключевых вопросов, на которые исследование **обязано** ответить.
*Цикл:* для каждого вопроса позже проверить: «получили ли ответ? из какого источника?»
---
## Q4. Ограничения и фокус
- Регион, отрасль, сегмент B2B/B2C
- Стек / экосистема, если техническое
- Бюджет на инструменты / данные
- Срок, к которому нужен ответ
---
## После сбора данных (чек для отчёта)
1. На какие из Q3 мы **ответили**?
2. Какие **источники** (ссылки, интервью, внутренние документы)?
3. Какие **рекомендации** для брифа / PRD?
4. Что осталось **открытым**?
---
*Извлечено из `bmad-v6/commands/research.md` (Part 1).*
@@ -0,0 +1,132 @@
# Продуктовый бриф — вопросы (анализ, фаза 1)
**Источник:** `bmad-v6/commands/product-brief.md` (интервью, 11 разделов).
**Порядок:** сверху вниз. **Уточнения** ⟳ — задавать, пока ответ расплывчатый.
---
## Раздел 1. Краткое резюме
1. В **23 предложениях:** что строим? для кого? почему это важно?
**Уточнения ⟳:**
- Кто **конкретно** будет пользоваться?
- Чем отличается от того, что уже есть?
---
## Раздел 2. Проблема
1. Какую **конкретную** проблему решаем?
**Уточнения ⟳:**
- Пример проблемы **из жизни**?
- Как сейчас с этим **справляются**?
- Что будет, если **не решить**?
**Дополнительно:**
2. Почему **сейчас** правильное время?
3. Какой **ущерб** от промедления?
---
## Раздел 3. Аудитория
1. Кто **основные** пользователи (ежедневно)?
**Уточнения ⟳:** роль, контекст, техническая готовность, текущее поведение, боли.
2. Кто **вторичные** пользователи (реже / опосредованно)?
3. **Три главные** потребности, которые закрывает решение?
---
## Раздел 4. Решение (обзор)
1. В **общих чертах** какое решение предлагаете?
**Уточнения ⟳:**
- **Ключевые** возможности (must-have)?
- Как это **снимает** проблему?
- Почему это **убедительно** для пользователя?
---
## Раздел 5. Бизнес-цели
1. Какие **бизнес-цели** проекта?
*(Подсказка: SMART — конкретно, измеримо, достижимо, релевантно, ограничено по времени.)*
2. Как **измерите** успех? Какие **метрики**?
3. Какая **бизнес-ценность** (выручка, экономия, рост пользователей и т.д.)?
---
## Раздел 6. Границы (scope)
1. Что **входит** в проект / фазу?
**Уточнения ⟳:** что ещё включить? есть ли **технические** обязательные элементы?
2. Что **явно не входит** (чтобы не раздувать ожидания)?
3. Что откладываем на **будущие** фазы?
---
## Раздел 7. Стейкхолдеры ⟳
**Для каждого ключевого человека / роли:**
- Имя / роль?
- Интерес к проекту?
- Уровень влияния: высокий / средний / низкий?
---
## Раздел 8. Ограничения и допущения
1. Какие **ограничения**? (бюджет, сроки, технологии, люди, регуляторика.)
2. Какие **допущения** принимаем? (например: «у пользователей есть смартфон», «API партнёра доступен».)
---
## Раздел 9. Критерии успеха
Помимо метрик: **как поймёте**, что проект удался?
**Уточнения ⟳:** удовлетворённость, внедрение, качество, бизнес-эффект.
---
## Раздел 10. Сроки
1. **Целевая** дата запуска или горизонт?
2. Какие **ключевые вехи** на пути?
---
## Раздел 11. Риски ⟳
**Для каждого риска:**
- В чём риск?
- Вероятность: высокая / средняя / низкая?
- Что делаем для **снижения**?
---
## Перед закрытием созвона по брифу
1. Все ли разделы **закрыты** или есть явные дыры?
2. Кто **владелец** текста брифа после транскрипта?
3. Нужен ли **второй раунд** интервью с другими стейкхолдерами?
---
*Извлечено из `bmad-v6/commands/product-brief.md`.*
@@ -0,0 +1,75 @@
# Кооперация: бизнес-процессы и сценарии (под PRD и BPMN)
**Назначение.** Зафиксировать **глубокое бизнес-описание** кооперативных процессов: шаги, роли, **подписываемые документы**, **эффекты** (в т.ч. в совете и в деньгах), **проводки / движения по учёту** в понятных словах. Это основа для **BPMN** и для PRD (потоки, FR), **без** избыточной техники реализации.
**Участники созвона.** Кроме продукта и предметных экспертов — **архитектор / владелец контуров платформы**: чтобы на каждом шаге свериться с **уже существующими** типами документов, действиями блокчейна/контроллера и правилами учёта. Формулировки остаются **бизнесовыми**; технические идентификаторы (`registry_id`, коды действий) вносим **если известны** — их будете **уточнять итерациями**, без раздувания первого прохода.
**Порядок:** несколько созвонов — карта сценариев → **пошаговая** проработка с шаблоном ниже → согласованность между сценариями → BPMN.
---
## A. Карта процессов (один проход + список)
1. Какие **сквозные сценарии** обязаны быть в первой волне? (имена для BPMN-диаграмм.)
2. Для каждого: **инициатор**, **ключевые роли**, **конечный результат** для кооператива.
3. Какие сценарии **отложены**?
---
## B. Один сценарий — общая рамка
### B1. Название и цель
- Имя сценария (для PRD и пула диаграмм).
- Зачем кооперативу — одно предложение.
### B2. Триггер, завершение, ветвления
- Что **запускает** процесс?
- Что считается **успехом**?
- Какие **ветки** (отмена, спор, отказ, частичное исполнение)?
### B3. Роли и глоссарий
- Словарь: «заявка», «поставщик», «заказчик», **статусы** заявки/заказа — единые имена для всех диаграмм.
- Какие роли **обязаны** быть описаны в BPMN?
---
## C. Вопросы к каждому шагу (чек-лист) ⟳
На каждый шаг ответить **кратко**; неясное пометить **TBD** для следующего раунда с архитектором.
1. **Код и имя шага** — как назовём на BPMN (глагол/состояние)?
2. **Кто исполнитель** — одна ответственная роль?
3. **Какие документы подписываются** в этом шаге (название для людей + код/registry при известности)?
4. **Проводки / учёт:** есть ли движение по счетам или эквивалент в системе? Если да — **в двух-трёх фразах**: чьи обязательства/лимиты меняются? Если нет — явно «Нет».
5. **Эффекты:** что ещё меняется кроме подписи (совет, блокировки, очереди, статусы других объектов, уведомления)?
6. **Статус** ключевой сущности после шага (заявка, заказ, спор…)?
7. **Предусловия:** без чего шаг **недоступен**?
8. **Следующий шаг по умолчанию** и **альтернативы** (ветки BPMN)?
---
## D. Правила и исключения (на сценарий)
- Жёсткие правила (лимиты, сроки, кворум).
- Исключения: кто утверждает, чем фиксируется.
- Что **нельзя** без подписи / без статуса / без документа.
---
## E. Документы и итерации
- Ведите **список типов документов** c «**кодами**», которые всплыли по шагам; он будет **уточняться** — это нормально.
---
## F. BPMN
- Один файл/диаграмма на сценарий (или пул с подпроцессами).
- Swimlanes = роли из B3.
- Шаги = блоки C с кодами для ссылок в PRD.
- Ссылка на черновик: доска / файл.
+96
View File
@@ -0,0 +1,96 @@
# PRD — вопросы (планирование, фаза 2)
**Источник:** `bmad-v6/commands/prd.md`
**Вход:** результаты брифа + при необходимости блок **кооперативных процессов** (`05-cooperation-processes-questions.md`).
**Порядок:** фундамент → FR ⟳ → NFR ⟳ → опционально истории → доп. разделы.
**Эпики:** на созвоне **не выделяем**. Фиксируем **функциональные требования** с бизнес-стороны; **группировку в эпики** (и при необходимости детализацию под кодовую базу) выполняет **агент** после разговора о требованиях.
---
## Часть 1. Фундамент
**Если бриф уже есть:**
1. После брифа — что **изменилось** или что **добавить** перед требованиями?
**Если брифа нет:**
2. Какие **три главные** бизнес-цели проекта?
3. Какие **метрики успеха**?
---
## Часть 2. Функциональные требования (FR) ⟳
**Пояснение для группы:** FR — **что** система делает; приоритеты **Must / Should / Could** (MoSCoW).
**Внешний цикл — по каждой крупной области / домену** (из брифа или процессов):
1. Что система должна делать в области **«[название области]»**?
**Внутренний цикл — по каждому требованию в области:**
2. **Формулировка** (конкретно, проверяемо)?
3. **Приоритет:** Must / Should / Could?
4. **Критерии приёмки** (как проверить готовность) — список пунктов?
5. Зависит ли от **другого FR** (ID)?
**После сбора:** присвоить **FR-001, FR-002, …** последовательно.
*Ориентир объёма по уровню проекта (из v6): Level 2 — 815 FR; Level 3 — 1530; Level 4 — 3050.*
---
## Часть 3. Нефункциональные требования (NFR) ⟳
**Пояснение:** NFR — **как** система работает (качество, ограничения).
**По категориям — задать вопрос «Какие требования к …?» и зафиксировать измеримое:**
1. **Производительность** — время отклика, пропускная способность, одновременные пользователи?
2. **Безопасность** — аутентификация, авторизация, шифрование, комплаенс?
3. **Масштабируемость** — рост нагрузки, объём данных?
4. **Надёжность / доступность** — аптайм, резервирование, бэкапы?
5. **Удобство** — WCAG, браузеры/устройства, языки?
6. **Сопровождаемость** — документация, тесты, стандарты кода?
7. **Совместимость** — интеграции, форматы API?
**По каждому релевантному NFR:**
- Приоритет Must / Should
- **Измеримый** критерий (цифры, пороги)
- **Зачем** это важно бизнесу?
*Ориентир: 512 NFR.*
---
## Часть 4. Пользовательские истории (верхний уровень), опционально
1. Фиксируем ли **черновые** истории сейчас или оставляем на планирование спринта?
**Если да — ⟳** по областям или по связке с FR: по 2–3 истории в формате:
«Как **[тип пользователя]**, я хочу **[цель]**, чтобы **[польза]**.»
---
## Часть 5. Дополнительные разделы
1. **Персоны** (если не в брифе): кто основные типы пользователей?
2. **Ключевые пользовательские потоки (2–3):** самые важные пути — связать с диаграммами из блока кооперации?
3. **Внутренние зависимости:** от каких систем / команд зависим?
4. **Внешние зависимости:** API, партнёры, регуляторика?
5. **Допущения:** что считаем истинным без доказательств?
6. **Вне scope:** подтвердить границы из брифа / уточнить?
7. **Открытые вопросы:** что ещё не решено?
8. **Стейкхолдеры** для согласования PRD?
---
## Часть 6. Перед передачей агенту на сборку PRD
1. Все **Must FR** имеют критерии приёмки?
2. NFR **измеримы** где возможно?
3. Приложены **ссылки на схемы** сценариев кооперации?
---
*Извлечено из `bmad-v6/commands/prd.md` (Parts 16); блок эпиков убран — группировка на стороне агента.*
@@ -0,0 +1,53 @@
# Структурные техники — шпаргалка вопросов
**Назначение:** короткие списки для фасилитатора; подробные циклы см. [`02-brainstorm-questions.md`](02-brainstorm-questions.md).
---
## 5 Why
Повторять: **«Почему?»** → ответ → снова **«Почему?»** (до ~5 раз или до корня).
---
## SCAMPER (один проход по буквам)
1. Что **заменить**?
2. Что **объединить**?
3. Что **адаптировать**?
4. Что **изменить** / увеличить / уменьшить?
5. Какое **иное применение**?
6. Что **убрать**?
7. Что при **обращении** / инверсии?
---
## Starbursting
**Кто? Что? Где? Когда? Почему? Как?** — по каждому слову выписать вопросы к теме.
---
## Обратный мозговой штурм
1. Как **гарантированно убить** инициативу?
2. Обратить ответы в **антириски** и меры.
---
## SWOT
- **S** — сильные стороны
- **W** — слабые стороны
- **O** — возможности
- **T** — угрозы
---
## Шесть шляп
См. [`01-six-thinking-hats-questions.md`](01-six-thinking-hats-questions.md).
---
*Сжатое напоминание по `bmad-v6/commands/brainstorm.md`.*
@@ -0,0 +1,58 @@
# UX — рамка до детальной работы с агентом (опционально)
**Источник:** `bmad-v6/commands/create-ux-design.md` (Part 1).
Имеет смысл **после** того, как в PRD зафиксированы потоки и FR (или параллельно финальному проходу PRD), если продукт **с сильным UI**. Детальные вайрфреймы и спецификации экранов обычно удобнее доверить **агенту** с этим чек-листом как входом.
---
## Q1. Целевые платформы
Для каких платформ проектируем? (можно несколько.)
- [ ] Web (desktop)
- [ ] Web (mobile)
- [ ] Web (tablet)
- [ ] iOS native
- [ ] Android native
- [ ] PWA
---
## Q2. Уровень детализации дизайна
1. **Высокий уровень** — потоки и базовые вайрфреймы
2. **Детальный** — полные вайрфреймы и взаимодействия
3. **Комплексный** — вайрфреймы, взаимодействия, компоненты, дизайн-система
---
## Q3. Доступность
Какой уровень WCAG ориентир?
1. WCAG 2.1 **A** (минимум)
2. WCAG 2.1 **AA** (рекомендуется)
3. WCAG 2.1 **AAA** (максимум)
---
## Q4. Дизайн-система и бренд
Есть ли **готовая** дизайн-система или брендбук (ссылка / файл)? Если нет — зафиксировать «нужна базовая шкала токенов с нуля».
---
## Для потоков (если обсуждаете на созвоне без агента)
По каждому **главному** потоку из PRD:
- **Точка входа** пользователя в поток?
- **Happy path** — шаги по экранам / действиям?
- **Развилки:** если условие X → куда уходим?
- **Ошибки:** что показываем и как **восстановление**?
- **Выходы:** успех / отмена / ошибка — куда ведут?
---
*Извлечено из `bmad-v6/commands/create-ux-design.md` (Parts 1 и структура Part 3).*
+26
View File
@@ -0,0 +1,26 @@
# Вопросники для групповых созвонов (до PRD включительно)
**Зачем.** Вы обсуждаете продукт **в группе** (транскрипты звонков), затем передаёте **сырые ответы** агенту для сборки `product-brief`, `requirements`/PRD и связанных story по правилам **bmad-c9s**. Эти файлы — **только вопросы и порядок**, без инструкций агенту.
**Источник.** Вопросы извлечены и адаптированы из `bmad-v6/commands/` (`product-brief`, `prd`, `brainstorm`, `research`, `create-ux-design`) + метод **шести шляп** из [`../six-thinking-hats-tutorial.md`](../six-thinking-hats-tutorial.md). Добавлен блок **кооперативные бизнес-процессы** под PRD со ссылками на сценарии и диаграммы.
**Что сюда не входит** (остаётся интерактив с агентом): архитектура, tech-spec, dev-story, планирование спринта, детальная работа по кодовой базе.
---
## Рекомендуемый порядок (сверху вниз)
| Шаг | Файл | Когда |
|-----|------|--------|
| 0 | [`01-six-thinking-hats-questions.md`](01-six-thinking-hats-questions.md) | Первая нетехническая синхронизация по теме (можно несколько кругов — см. туториал). |
| 1 | [`02-brainstorm-questions.md`](02-brainstorm-questions.md) | Опционально: идеи, риски, варианты (после или вместо части шляп). |
| 2 | [`03-research-questions.md`](03-research-questions.md) | Опционально: постановка исследования; сами данные рынка/конкурентов собираете вы, не агент на созвоне. |
| 3 | [`04-product-brief-questions.md`](04-product-brief-questions.md) | Продуктовый бриф: видение, проблема, scope, стейкхолдеры, риски. |
| 4 | [`05-cooperation-processes-questions.md`](05-cooperation-processes-questions.md) | **Ключевой контур кооперации:** сценарии, шаги в формате «документы / учёт / эффекты / статус», BPMN; на созвоне — **архитектор** для сверки с платформой; можно несколько встреч. |
| 5 | [`06-prd-questions.md`](06-prd-questions.md) | FR/NFR, потоки, допущения — сборка PRD; **циклы** по областям и требованиям (эпики — на стороне агента). |
| 6 | [`07-structured-techniques-questions.md`](07-structured-techniques-questions.md) | Опционально: SWOT, SCAMPER, starbursting, 5 Why, обратный мозговой штурм. |
| 7 | [`08-ux-scope-optional-questions.md`](08-ux-scope-optional-questions.md) | Опционально: платформы, WCAG, уровень детализации UX **до** передачи агенту на макеты/вайрфреймы. |
**Циклы.** В файлах помечено `⟳` — повторять для каждой сущности (область функций, FR, сценарий, риск и т.д.).
**Передача агенту.** Прикрепите: транскрипции, заполненные ответы под номерами вопросов, указание «собрать по шаблону PRD/бриф из bmad-v6/templates (RU) и канону c9s».
+103 -103
View File
@@ -1,129 +1,129 @@
# System Architecture: {{project_name}}
# Системная архитектура: {{project_name}}
**Date:** {{date}}
**Architect:** {{user_name}}
**Version:** 1.0
**Project Type:** {{project_type}}
**Project Level:** {{project_level}}
**Status:** Draft
**Дата:** {{date}}
**Архитектор:** {{user_name}}
**Версия:** 1.0
**Тип проекта:** {{project_type}}
**Уровень проекта:** {{project_level}}
**Статус:** Черновик
---
## Document Overview
## Обзор документа
This document defines the system architecture for {{project_name}}. It provides the technical blueprint for implementation, addressing all functional and non-functional requirements from the PRD.
Документ описывает системную архитектуру {{project_name}}. Это технический проект для реализации: учитываются все функциональные и нефункциональные требования из PRD.
**Related Documents:**
- Product Requirements Document: {{prd_path}}
- Product Brief: {{product_brief_path}}
**Связанные документы:**
- Документ продуктовых требований (PRD): {{prd_path}}
- Продуктовый бриф: {{product_brief_path}}
---
## Executive Summary
## Краткое резюме
{{executive_summary}}
---
## Architectural Drivers
## Архитектурные драйверы
These requirements heavily influence architectural decisions:
Требования, которые сильнее всего влияют на архитектурные решения:
{{architectural_drivers}}
---
## System Overview
## Обзор системы
### High-Level Architecture
### Архитектура верхнего уровня
{{high_level_architecture}}
### Architecture Diagram
### Диаграмма архитектуры
{{architecture_diagram}}
### Architectural Pattern
### Архитектурный паттерн
**Pattern:** {{architectural_pattern}}
**Паттерн:** {{architectural_pattern}}
**Rationale:** {{pattern_rationale}}
**Обоснование:** {{pattern_rationale}}
---
## Technology Stack
## Стек технологий
### Frontend
### Фронтенд
{{frontend_stack}}
### Backend
### Бэкенд
{{backend_stack}}
### Database
### База данных
{{database_stack}}
### Infrastructure
### Инфраструктура
{{infrastructure_stack}}
### Third-Party Services
### Сторонние сервисы
{{third_party_services}}
### Development & Deployment
### Разработка и развёртывание
{{dev_deployment_stack}}
---
## System Components
## Компоненты системы
{{system_components}}
---
## Data Architecture
## Архитектура данных
### Data Model
### Модель данных
{{data_model}}
### Database Design
### Проектирование БД
{{database_design}}
### Data Flow
### Потоки данных
{{data_flow}}
---
## API Design
## Проектирование API
### API Architecture
### Архитектура API
{{api_architecture}}
### Endpoints
### Конечные точки (endpoints)
{{api_endpoints}}
### Authentication & Authorization
### Аутентификация и авторизация
{{api_auth}}
---
## Non-Functional Requirements Coverage
## Покрытие нефункциональных требований
### NFR-001: {{nfr_001_name}}
**Requirement:** {{nfr_001_requirement}}
**Требование:** {{nfr_001_requirement}}
**Architecture Solution:** {{nfr_001_solution}}
**Архитектурное решение:** {{nfr_001_solution}}
---
@@ -131,209 +131,209 @@ These requirements heavily influence architectural decisions:
---
## Security Architecture
## Архитектура безопасности
### Authentication
### Аутентификация
{{auth_design}}
### Authorization
### Авторизация
{{authz_design}}
### Data Encryption
### Шифрование данных
{{encryption_design}}
### Security Best Practices
### Практики безопасности
{{security_practices}}
---
## Scalability & Performance
## Масштабируемость и производительность
### Scaling Strategy
### Стратегия масштабирования
{{scaling_strategy}}
### Performance Optimization
### Оптимизация производительности
{{performance_optimization}}
### Caching Strategy
### Стратегия кэширования
{{caching_strategy}}
### Load Balancing
### Балансировка нагрузки
{{load_balancing}}
---
## Reliability & Availability
## Надёжность и доступность
### High Availability Design
### Проектирование высокой доступности
{{ha_design}}
### Disaster Recovery
### Аварийное восстановление
{{dr_design}}
### Backup Strategy
### Стратегия резервного копирования
{{backup_strategy}}
### Monitoring & Alerting
### Мониторинг и оповещения
{{monitoring_alerting}}
---
## Integration Architecture
## Архитектура интеграций
### External Integrations
### Внешние интеграции
{{external_integrations}}
### Internal Integrations
### Внутренние интеграции
{{internal_integrations}}
### Message/Event Architecture (if applicable)
### Сообщения / события (если применимо)
{{messaging_architecture}}
---
## Development Architecture
## Архитектура разработки
### Code Organization
### Организация кода
{{code_organization}}
### Module Structure
### Структура модулей
{{module_structure}}
### Testing Strategy
### Стратегия тестирования
{{testing_strategy}}
### CI/CD Pipeline
### Конвейер CI/CD
{{cicd_pipeline}}
---
## Deployment Architecture
## Архитектура развёртывания
### Environments
### Окружения
{{environments}}
### Deployment Strategy
### Стратегия развёртывания
{{deployment_strategy}}
### Infrastructure as Code
### Инфраструктура как код
{{iac}}
---
## Requirements Traceability
## Трассировка требований
### Functional Requirements Coverage
### Покрытие функциональных требований
{{fr_traceability}}
### Non-Functional Requirements Coverage
### Покрытие нефункциональных требований
{{nfr_traceability}}
---
## Trade-offs & Decision Log
## Компромиссы и журнал решений
{{tradeoffs}}
---
## Open Issues & Risks
## Открытые вопросы и риски
{{open_issues}}
---
## Assumptions & Constraints
## Допущения и ограничения
{{assumptions}}
---
## Future Considerations
## На будущее
{{future_considerations}}
---
## Approval & Sign-off
## Согласование и подписи
**Review Status:**
- [ ] Technical Lead
- [ ] Product Owner
- [ ] Security Architect (if applicable)
- [ ] DevOps Lead
**Статус ревью:**
- [ ] Технический лид
- [ ] Владелец продукта (Product Owner)
- [ ] Архитектор безопасности (если применимо)
- [ ] Руководитель DevOps
---
## Revision History
## История изменений
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 1.0 | {{date}} | {{user_name}} | Initial architecture |
| Версия | Дата | Автор | Изменения |
|--------|------|-------|-----------|
| 1.0 | {{date}} | {{user_name}} | Первоначальная архитектура |
---
## Next Steps
## Следующие шаги
### Phase 4: Sprint Planning & Implementation
### Фаза 4: Планирование спринта и реализация
Run `/sprint-planning` to:
- Break epics into detailed user stories
- Estimate story complexity
- Plan sprint iterations
- Begin implementation following this architectural blueprint
Выполните `/sprint-planning`, чтобы:
- разбить эпики на детальные пользовательские истории;
- оценить сложность историй;
- спланировать итерации спринта;
- начать реализацию по этому архитектурному проекту.
**Key Implementation Principles:**
1. Follow component boundaries defined in this document
2. Implement NFR solutions as specified
3. Use technology stack as defined
4. Follow API contracts exactly
5. Adhere to security and performance guidelines
**Ключевые принципы реализации:**
1. Соблюдать границы компонентов, заданные в документе.
2. Реализовывать решения по NFR в соответствии со спецификацией.
3. Использовать согласованный стек технологий.
4. Следовать контрактам API.
5. Соблюдать требования безопасности и производительности.
---
**This document was created using BMAD Method v6 - Phase 3 (Solutioning)**
**Документ создан по методу BMAD v6 — фаза 3 (проектирование решения)**
*To continue: Run `/workflow-status` to see your progress and next recommended workflow.*
*Дальше: выполните `/workflow-status`, чтобы увидеть прогресс и рекомендуемый workflow.*
---
## Appendix A: Technology Evaluation Matrix
## Приложение A: Матрица оценки технологий
{{tech_evaluation_matrix}}
---
## Appendix B: Capacity Planning
## Приложение B: Планирование ёмкости
{{capacity_planning}}
---
## Appendix C: Cost Estimation
## Приложение C: Оценка затрат
{{cost_estimation}}
+70 -70
View File
@@ -1,50 +1,50 @@
# Product Requirements Document: {{project_name}}
# Документ продуктовых требований (PRD): {{project_name}}
**Date:** {{date}}
**Author:** {{user_name}}
**Version:** 1.0
**Project Type:** {{project_type}}
**Project Level:** {{project_level}}
**Status:** Draft
**Дата:** {{date}}
**Автор:** {{user_name}}
**Версия:** 1.0
**Тип проекта:** {{project_type}}
**Уровень проекта:** {{project_level}}
**Статус:** Черновик
---
## Document Overview
## Обзор документа
This Product Requirements Document (PRD) defines the functional and non-functional requirements for {{project_name}}. It serves as the source of truth for what will be built and provides traceability from requirements through implementation.
Этот PRD (Product Requirements Document) определяет функциональные и нефункциональные требования к {{project_name}}. Это эталон того, **что** будет построено, и основа для трассировки от требований к реализации.
**Related Documents:**
- Product Brief: {{product_brief_path}}
**Связанные документы:**
- Продуктовый бриф: {{product_brief_path}}
---
## Executive Summary
## Краткое резюме
{{executive_summary}}
---
## Product Goals
## Цели продукта
### Business Objectives
### Бизнес-цели
{{business_objectives}}
### Success Metrics
### Метрики успеха
{{success_metrics}}
---
## Functional Requirements
## Функциональные требования
Functional Requirements (FRs) define **what** the system does - specific features and behaviors.
Функциональные требования (FR) описывают, **что** делает система — конкретные возможности и поведение.
Each requirement includes:
- **ID**: Unique identifier (FR-001, FR-002, etc.)
- **Priority**: Must Have / Should Have / Could Have / Won't Have (MoSCoW)
- **Description**: What the system should do
- **Acceptance Criteria**: How to verify it's complete
Каждое требование включает:
- **ID**: уникальный идентификатор (FR-001, FR-002 и т.д.)
- **Приоритет**: Must Have / Should Have / Could Have / Won't Have (MoSCoW)
- **Описание**: что система должна делать
- **Критерии приёмки**: как проверить выполнение
---
@@ -52,9 +52,9 @@ Each requirement includes:
---
## Non-Functional Requirements
## Нефункциональные требования
Non-Functional Requirements (NFRs) define **how** the system performs - quality attributes and constraints.
Нефункциональные требования (NFR) описывают, **как** система работает — качественные характеристики и ограничения.
---
@@ -62,11 +62,11 @@ Non-Functional Requirements (NFRs) define **how** the system performs - quality
---
## Epics
## Эпики
Epics are logical groupings of related functionality that will be broken down into user stories during sprint planning (Phase 4).
Эпики — логические группы связанного функционала; на этапе планирования спринта (фаза 4) они дробятся на пользовательские истории.
Each epic maps to multiple functional requirements and will generate 2-10 stories.
Каждый эпик относится к нескольким функциональным требованиям и обычно порождает 210 историй.
---
@@ -74,11 +74,11 @@ Each epic maps to multiple functional requirements and will generate 2-10 storie
---
## User Stories (High-Level)
## Пользовательские истории (верхний уровень)
User stories follow the format: "As a [user type], I want [goal] so that [benefit]."
Формат истории: «Как [тип пользователя], я хочу [цель], чтобы [польза].»
These are preliminary stories. Detailed stories will be created in Phase 4 (Implementation).
Это предварительные истории. Детальные истории создаются на фазе 4 (реализация).
---
@@ -86,108 +86,108 @@ These are preliminary stories. Detailed stories will be created in Phase 4 (Impl
---
## User Personas
## Персоны пользователей
{{user_personas}}
---
## User Flows
## Пользовательские потоки
{{user_flows}}
---
## Dependencies
## Зависимости
### Internal Dependencies
### Внутренние зависимости
{{internal_dependencies}}
### External Dependencies
### Внешние зависимости
{{external_dependencies}}
---
## Assumptions
## Допущения
{{assumptions}}
---
## Out of Scope
## Вне scope
{{out_of_scope}}
---
## Open Questions
## Открытые вопросы
{{open_questions}}
---
## Approval & Sign-off
## Согласование и подписи
### Stakeholders
### Стейкхолдеры
{{stakeholders}}
### Approval Status
### Статус согласования
- [ ] Product Owner
- [ ] Engineering Lead
- [ ] Design Lead
- [ ] QA Lead
- [ ] Владелец продукта (Product Owner)
- [ ] Руководитель разработки (Engineering Lead)
- [ ] Руководитель дизайна (Design Lead)
- [ ] Руководитель QA (QA Lead)
---
## Revision History
## История изменений
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 1.0 | {{date}} | {{user_name}} | Initial PRD |
| Версия | Дата | Автор | Изменения |
|--------|------|-------|-----------|
| 1.0 | {{date}} | {{user_name}} | Первоначальный PRD |
---
## Next Steps
## Следующие шаги
### Phase 3: Architecture
### Фаза 3: Архитектура
Run `/architecture` to create system architecture based on these requirements.
Выполните `/architecture`, чтобы создать системную архитектуру на основе этих требований.
The architecture will address:
- All functional requirements (FRs)
- All non-functional requirements (NFRs)
- Technical stack decisions
- Data models and APIs
- System components
Архитектура должна учесть:
- все функциональные требования (FR);
- все нефункциональные требования (NFR);
- выбор технологического стека;
- модели данных и API;
- компоненты системы.
### Phase 4: Sprint Planning
### Фаза 4: Планирование спринта
After architecture is complete, run `/sprint-planning` to:
- Break epics into detailed user stories
- Estimate story complexity
- Plan sprint iterations
- Begin implementation
После архитектуры выполните `/sprint-planning`, чтобы:
- разбить эпики на детальные пользовательские истории;
- оценить сложность историй;
- спланировать итерации спринта;
- начать реализацию.
---
**This document was created using BMAD Method v6 - Phase 2 (Planning)**
**Документ создан по методу BMAD v6 — фаза 2 (планирование)**
*To continue: Run `/workflow-status` to see your progress and next recommended workflow.*
*Дальше: выполните `/workflow-status`, чтобы увидеть прогресс и рекомендуемый workflow.*
---
## Appendix A: Requirements Traceability Matrix
## Приложение A: Матрица трассировки требований
| Epic ID | Epic Name | Functional Requirements | Story Count (Est.) |
|---------|-----------|-------------------------|-------------------|
| ID эпика | Название эпика | Функциональные требования | Оценка числа историй |
|----------|----------------|---------------------------|----------------------|
{{traceability_matrix}}
---
## Appendix B: Prioritization Details
## Приложение B: Детали приоритизации
{{prioritization_details}}
+42 -42
View File
@@ -1,149 +1,149 @@
# Product Brief: {{project_name}}
# Продуктовый бриф: {{project_name}}
**Date:** {{date}}
**Author:** {{user_name}}
**Version:** 1.0
**Project Type:** {{project_type}}
**Project Level:** {{project_level}}
**Дата:** {{date}}
**Автор:** {{user_name}}
**Версия:** 1.0
**Тип проекта:** {{project_type}}
**Уровень проекта:** {{project_level}}
---
## Executive Summary
## Краткое резюме
{{executive_summary}}
---
## Problem Statement
## Формулировка проблемы
### The Problem
### Проблема
{{problem_statement}}
### Why Now?
### Почему сейчас?
{{why_now}}
### Impact if Unsolved
### Последствия, если не решить
{{impact_if_unsolved}}
---
## Target Audience
## Целевая аудитория
### Primary Users
### Основные пользователи
{{primary_users}}
### Secondary Users
### Вторичные пользователи
{{secondary_users}}
### User Needs
### Потребности пользователей
{{user_needs}}
---
## Solution Overview
## Обзор решения
### Proposed Solution
### Предлагаемое решение
{{proposed_solution}}
### Key Features
### Ключевые возможности
{{key_features}}
### Value Proposition
### Ценностное предложение
{{value_proposition}}
---
## Business Objectives
## Бизнес-цели
### Goals
### Цели
{{business_goals}}
### Success Metrics
### Метрики успеха
{{success_metrics}}
### Business Value
### Бизнес-ценность
{{business_value}}
---
## Scope
## Границы (scope)
### In Scope
### Входит в scope
{{in_scope}}
### Out of Scope
### Не входит в scope
{{out_of_scope}}
### Future Considerations
### На будущее
{{future_considerations}}
---
## Key Stakeholders
## Ключевые стейкхолдеры
{{stakeholders}}
---
## Constraints and Assumptions
## Ограничения и допущения
### Constraints
### Ограничения
{{constraints}}
### Assumptions
### Допущения
{{assumptions}}
---
## Success Criteria
## Критерии успеха
{{success_criteria}}
---
## Timeline and Milestones
## Сроки и вехи
### Target Launch
### Целевой запуск
{{target_launch}}
### Key Milestones
### Ключевые вехи
{{key_milestones}}
---
## Risks and Mitigation
## Риски и меры
{{risks}}
---
## Next Steps
## Следующие шаги
1. Create Product Requirements Document (PRD) - `/prd`
2. Conduct user research (optional) - `/research`
3. Create UX design (if UI-heavy) - `/create-ux-design`
1. Создать документ продуктовых требований (PRD) `/prd`
2. Провести пользовательское исследование (по желанию) `/research`
3. Создать UX-дизайн (если сильный UI) `/create-ux-design`
---
**This document was created using BMAD Method v6 - Phase 1 (Analysis)**
**Документ создан по методу BMAD v6 — фаза 1 (анализ)**
*To continue: Run `/workflow-status` to see your progress and next recommended workflow.*
*Дальше: выполните `/workflow-status`, чтобы увидеть прогресс и рекомендуемый workflow.*
+51 -51
View File
@@ -1,147 +1,147 @@
# Technical Specification: {{project_name}}
# Техническая спецификация: {{project_name}}
**Date:** {{date}}
**Author:** {{user_name}}
**Version:** 1.0
**Project Type:** {{project_type}}
**Project Level:** {{project_level}}
**Status:** Draft
**Дата:** {{date}}
**Автор:** {{user_name}}
**Версия:** 1.0
**Тип проекта:** {{project_type}}
**Уровень проекта:** {{project_level}}
**Статус:** Черновик
---
## Document Overview
## Обзор документа
This Technical Specification provides focused technical planning for {{project_name}}. It is designed for smaller projects (Level 0-1) that need clear requirements without heavyweight PRD overhead.
Эта техническая спецификация задаёт сфокусированное техническое планирование для {{project_name}}. Предназначена для небольших проектов (уровни 01), которым нужны чёткие требования без тяжёлого PRD.
**Related Documents:**
- Product Brief: {{product_brief_path}}
**Связанные документы:**
- Продуктовый бриф: {{product_brief_path}}
---
## Problem & Solution
## Проблема и решение
### Problem Statement
### Формулировка проблемы
{{problem_statement}}
### Proposed Solution
### Предлагаемое решение
{{proposed_solution}}
---
## Requirements
## Требования
### What Needs to Be Built
### Что нужно построить
{{requirements_list}}
### What This Does NOT Include
### Что явно не входит
{{out_of_scope}}
---
## Technical Approach
## Технический подход
### Technology Stack
### Стек технологий
{{tech_stack}}
### Architecture Overview
### Обзор архитектуры
{{architecture_overview}}
### Data Model (if applicable)
### Модель данных (если применимо)
{{data_model}}
### API Design (if applicable)
### Проектирование API (если применимо)
{{api_design}}
---
## Implementation Plan
## План реализации
### Stories
### Истории (stories)
{{stories_list}}
### Development Phases
### Фазы разработки
{{development_phases}}
---
## Acceptance Criteria
## Критерии приёмки
How we'll know it's done:
Как поймём, что готово:
{{acceptance_criteria}}
---
## Non-Functional Requirements
## Нефункциональные требования
### Performance
### Производительность
{{performance_requirements}}
### Security
### Безопасность
{{security_requirements}}
### Other
### Прочее
{{other_nfr}}
---
## Dependencies
## Зависимости
{{dependencies}}
---
## Risks & Mitigation
## Риски и меры
{{risks}}
---
## Timeline
## Сроки
**Target Completion:** {{target_completion}}
**Целевое завершение:** {{target_completion}}
**Milestones:**
**Вехи:**
{{milestones}}
---
## Approval
## Согласование
**Reviewed By:**
- [ ] {{user_name}} (Author)
- [ ] Technical Lead
- [ ] Product Owner
**Проверили:**
- [ ] {{user_name}} (автор)
- [ ] Технический лид
- [ ] Владелец продукта (Product Owner)
---
## Next Steps
## Следующие шаги
### Phase 4: Implementation
### Фаза 4: Реализация
For Level 0 projects (single story):
- Run `/create-story` to create the story
- Run `/dev-story` to implement
Для проектов уровня 0 (одна история):
- Выполните `/create-story`, чтобы создать историю
- Выполните `/dev-story` для реализации
For Level 1 projects (1-10 stories):
- Run `/sprint-planning` to plan your sprint
- Then create and implement stories
Для проектов уровня 1 (110 историй):
- Выполните `/sprint-planning` для планирования спринта
- Затем создайте и реализуйте истории
---
**This document was created using BMAD Method v6 - Phase 2 (Planning)**
**Документ создан по методу BMAD v6 — фаза 2 (планирование)**
*To continue: Run `/workflow-status` to see your progress and next recommended workflow.*
*Дальше: выполните `/workflow-status`, чтобы увидеть прогресс и рекомендуемый workflow.*