192 lines
7.1 KiB
Markdown
192 lines
7.1 KiB
Markdown
<execution domain="product-management">
|
||
|
||
# Epic设计核心理念
|
||
|
||
## 🤔 Epic = 价值主题问题
|
||
|
||
```markdown
|
||
Epic的本质：提出价值主题层面的问题
|
||
核心思考：我们如何为用户创造这个价值域？
|
||
|
||
问题导向框架：
|
||
📋 提问题层: Epic → Feature → Story (需求定义)
|
||
🛠️ 解决问题层: Task (技术实现)
|
||
✅ 验证层: TestCase (质量保证)
|
||
🎯 价值确认层: Milestone (交付确认)
|
||
```
|
||
|
||
**Epic的职责边界**：
|
||
- ✅ 提出战略价值问题和商业假设
|
||
- ✅ 定义用户价值期望和成功标准
|
||
- ✅ 识别市场机会和用户痛点
|
||
- ❌ 不解决具体技术实现问题
|
||
- ❌ 不定义详细功能设计方案
|
||
|
||
## ⚠️ 常见陷阱与避免方法
|
||
|
||
```markdown
|
||
陷阱1: 写成技术方案书
|
||
错误表述: "构建基于NPM的模块化架构，包含CLI工具和JSON API"
|
||
正确表述: "降低AI助手角色加载的复杂度，提升开发者使用效率"
|
||
|
||
陷阱2: 混合问题与解决方案
|
||
错误表述: "通过命令行工具实现快速角色配置以提升用户体验"
|
||
正确表述: "当前角色配置流程复杂，需要简化用户获取AI能力的路径"
|
||
|
||
陷阱3: 功能需求清单化
|
||
错误表述: "包含角色系统、快速初始化、内存可视化三个功能"
|
||
正确表述: "AI助手获取专业能力的门槛过高，影响普通用户采用"
|
||
```
|
||
|
||
**问题导向自检清单**：
|
||
- [ ] Epic描述中是否包含"如何"、"通过"、"实现"等解决方案词汇？
|
||
- [ ] 是否先描述用户痛点，再提出价值假设？
|
||
- [ ] 能否用"什么问题"而非"什么功能"来概括Epic？
|
||
- [ ] 利益相关者看到Epic能理解问题，而非实现方式？
|
||
|
||
<process>
|
||
# Epic设计流程
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
A[识别价值主题] --> B[定义Epic范围]
|
||
B --> C[设计Epic结构]
|
||
C --> D[制定验收标准]
|
||
D --> E[评估大小与依赖]
|
||
E --> F{质量检查}
|
||
F -->|通过| G[Epic就绪]
|
||
F -->|不通过| H[优化调整]
|
||
H --> B
|
||
|
||
A1[用户价值分析] --> A
|
||
A2[商业目标对齐] --> A
|
||
A3[技术价值识别] --> A
|
||
```
|
||
|
||
## 价值识别方法
|
||
|
||
```mermaid
|
||
mindmap
|
||
root((Epic价值))
|
||
用户价值
|
||
用户旅程痛点
|
||
核心使用场景
|
||
体验提升目标
|
||
商业价值
|
||
收入影响
|
||
成本优化
|
||
竞争优势
|
||
技术价值
|
||
架构改进
|
||
技术债还清
|
||
开发效率
|
||
```
|
||
|
||
## 📊 价值量化模板
|
||
|
||
```markdown
|
||
### 用户价值量化
|
||
- 当前痛点: [具体描述用户遇到的问题]
|
||
- 影响用户: [数量/类型，如"80%的新用户"、"所有开发者"]
|
||
- 痛点成本: [时间/金钱损失，如"每次配置10分钟"、"60%放弃率"]
|
||
- 期望改善: [具体目标，如"降低到30秒"、"提升到95%成功率"]
|
||
|
||
### 商业价值量化
|
||
- 市场机会: [市场规模/竞争优势，如"AI开发者工具市场增长30%"]
|
||
- 收入影响: [具体数字，如"预期提升用户转化20%"]
|
||
- 成本节约: [具体节约，如"减少支持成本50%"]
|
||
- 风险缓解: [避免的损失，如"防止用户流失到竞品"]
|
||
|
||
### 技术价值量化
|
||
- 效率提升: [具体指标，如"开发效率提升3倍"]
|
||
- 维护成本: [降低程度，如"技术债务减少40%"]
|
||
- 扩展能力: [支撑能力，如"支持10倍用户增长"]
|
||
```
|
||
</process>
|
||
|
||
<guideline>
|
||
### Epic定义建议
|
||
|
||
- **标题命名**: 使用"问题+影响"格式，如"用户角色获取流程复杂度过高"，避免"构建XX"、"实现XX"等解决方案用词
|
||
- **价值先行**: 每个Epic必须先定义用户价值，再描述功能
|
||
- **边界明确**: 用包含/不包含列表明确Epic范围
|
||
- **分阶段交付**: 大Epic按MVP→增强→完善分阶段
|
||
|
||
**命名对比示例**：
|
||
```markdown
|
||
❌ 解决方案导向: "构建NPM包管理系统"
|
||
✅ 问题导向: "AI助手能力获取复杂度阻碍用户采用"
|
||
|
||
❌ 功能导向: "开发角色快速配置功能"
|
||
✅ 价值导向: "新用户角色配置门槛影响产品推广"
|
||
```
|
||
|
||
### 大小控制指南
|
||
|
||
| Epic类型 | 建议大小 | 完成周期 | Feature数量 |
|
||
|---------|---------|---------|------------|
|
||
| 小型Epic | 20-40 SP | 2-3迭代 | 2-4个 |
|
||
| 中型Epic | 40-80 SP | 3-5迭代 | 4-8个 |
|
||
| 大型Epic | 80-120 SP | 5-6迭代 | 8-12个 |
|
||
|
||
### 验收标准设计
|
||
|
||
- **功能完整性**: 可测试的功能检查点
|
||
- **质量标准**: 性能、安全、可用性指标
|
||
- **商业指标**: 可量化的业务成功指标
|
||
</guideline>
|
||
|
||
<rule>
|
||
1. **INVEST原则必须遵循**
|
||
- Independent: Epic间依赖最小化
|
||
- Negotiable: 范围可协商调整
|
||
- Valuable: 有明确用户价值
|
||
- Estimable: 可进行工作量估算
|
||
- Small: 不超过6个迭代
|
||
- Testable: 有明确验收标准
|
||
|
||
2. **强制包含要素**
|
||
- 用户价值和商业价值必须明确
|
||
- 验收标准必须可测试和量化
|
||
- 依赖关系必须识别和记录
|
||
- 风险必须评估和应对
|
||
|
||
3. **范围控制规则**
|
||
- 单个Epic不超过120 Story Points
|
||
- 超过6迭代的必须拆分
|
||
- 不相关功能不得组合在同一Epic
|
||
</rule>
|
||
|
||
<constraint>
|
||
1. **团队能力约束**
|
||
- Epic大小受团队速度限制
|
||
- 技术复杂度受团队技能约束
|
||
- 并行开发Epic数量有限
|
||
|
||
2. **业务约束**
|
||
- 必须与产品路线图对齐
|
||
- 受预算和时间窗口限制
|
||
- 合规和安全要求约束
|
||
|
||
3. **技术约束**
|
||
- 现有架构和技术债务影响
|
||
- 第三方集成依赖限制
|
||
- 性能和扩展性要求约束
|
||
</constraint>
|
||
|
||
<criteria>
|
||
| 评价维度 | 优秀标准 | 合格标准 | 不合格标准 |
|
||
|---------|---------|---------|-----------|
|
||
| 价值清晰度 | 用户价值和商业价值都明确量化 | 价值描述清晰但部分未量化 | 价值模糊或无法说清 |
|
||
| 范围合理性 | 边界清晰，大小适中，内聚性强 | 边界基本清晰，大小可控 | 范围模糊或过大过小 |
|
||
| 验收标准 | 标准具体可测，覆盖功能质量业务 | 标准基本明确可测试 | 标准模糊或不可测 |
|
||
| 依赖管理 | 依赖最小化，风险已识别应对 | 依赖已识别，风险可控 | 依赖复杂或风险未评估 |
|
||
| INVEST符合度 | 完全符合INVEST原则 | 基本符合，个别项有改进空间 | 不符合多个INVEST原则 |
|
||
|
||
**快速检查要点**：
|
||
📝 **问题导向**: 标题描述问题而非解决方案，避免"构建"、"开发"等技术词汇
|
||
💰 **价值量化**: 用户价值和商业价值必须量化，有清晰成功指标
|
||
🎯 **范围边界**: 包含/不包含列表清晰，单一问题域，6个迭代内完成
|
||
📊 **可执行性**: 验收标准具体可测，可拆分为独立Feature，风险已识别
|
||
</criteria>
|
||
</execution> |