questions for calls
This commit is contained in:
@@ -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. Выбор техник (фасилитатор объявляет)
|
||||
|
||||
Под задачу выбрать **2–3** из списка:
|
||||
|
||||
- Исследование проблемы: **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. Конкретные вопросы ⟳
|
||||
|
||||
Перечислите **3–7** ключевых вопросов, на которые исследование **обязано** ответить.
|
||||
|
||||
*Цикл:* для каждого вопроса позже проверить: «получили ли ответ? из какого источника?»
|
||||
|
||||
---
|
||||
|
||||
## 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. В **2–3 предложениях:** что строим? для кого? почему это важно?
|
||||
|
||||
**Уточнения ⟳:**
|
||||
- Кто **конкретно** будет пользоваться?
|
||||
- Чем отличается от того, что уже есть?
|
||||
|
||||
---
|
||||
|
||||
## Раздел 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.
|
||||
- Ссылка на черновик: доска / файл.
|
||||
|
||||
@@ -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 — 8–15 FR; Level 3 — 15–30; Level 4 — 30–50.*
|
||||
|
||||
---
|
||||
|
||||
## Часть 3. Нефункциональные требования (NFR) ⟳
|
||||
|
||||
**Пояснение:** NFR — **как** система работает (качество, ограничения).
|
||||
|
||||
**По категориям — задать вопрос «Какие требования к …?» и зафиксировать измеримое:**
|
||||
|
||||
1. **Производительность** — время отклика, пропускная способность, одновременные пользователи?
|
||||
2. **Безопасность** — аутентификация, авторизация, шифрование, комплаенс?
|
||||
3. **Масштабируемость** — рост нагрузки, объём данных?
|
||||
4. **Надёжность / доступность** — аптайм, резервирование, бэкапы?
|
||||
5. **Удобство** — WCAG, браузеры/устройства, языки?
|
||||
6. **Сопровождаемость** — документация, тесты, стандарты кода?
|
||||
7. **Совместимость** — интеграции, форматы API?
|
||||
|
||||
**По каждому релевантному NFR:**
|
||||
- Приоритет Must / Should
|
||||
- **Измеримый** критерий (цифры, пороги)
|
||||
- **Зачем** это важно бизнесу?
|
||||
|
||||
*Ориентир: 5–12 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 1–6); блок эпиков убран — группировка на стороне агента.*
|
||||
@@ -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).*
|
||||
@@ -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
@@ -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
@@ -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.
|
||||
Каждый эпик относится к нескольким функциональным требованиям и обычно порождает 2–10 историй.
|
||||
|
||||
---
|
||||
|
||||
@@ -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}}
|
||||
|
||||
@@ -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.*
|
||||
|
||||
@@ -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}}. Предназначена для небольших проектов (уровни 0–1), которым нужны чёткие требования без тяжёлого 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 (1–10 историй):
|
||||
- Выполните `/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.*
|
||||
|
||||
Reference in New Issue
Block a user