216 lines
8.5 KiB
Markdown
216 lines
8.5 KiB
Markdown
<execution domain="product-management">
|
||
|
||
# Feature设计核心理念
|
||
|
||
## 🤔 Feature = 功能域问题发现
|
||
|
||
```markdown
|
||
Feature的本质：发现用户在特定功能域遇到的问题
|
||
核心思考：用户在这个功能域被什么困难阻碍了？
|
||
|
||
问题导向框架：
|
||
📋 提问题层: Epic → Feature → Story (需求定义)
|
||
🛠️ 解决问题层: Task (技术实现)
|
||
✅ 验证层: TestCase (质量保证)
|
||
🎯 价值确认层: Milestone (交付确认)
|
||
```
|
||
|
||
**Feature的职责边界**：
|
||
- ✅ 发现用户在功能域的具体痛点和障碍
|
||
- ✅ 识别功能缺失导致的用户任务中断
|
||
- ✅ 定义用户在特定场景下的困难体验
|
||
- ❌ 不设计具体功能模块实现方案
|
||
- ❌ 不定义技术架构和接口细节
|
||
- ❌ 不描述"用户需要什么能力"
|
||
|
||
## ⚠️ 常见陷阱与避免方法
|
||
|
||
```markdown
|
||
陷阱1: 写成功能设计书
|
||
错误表述: "用户角色管理功能模块，包含角色选择、配置生成、状态展示"
|
||
正确表述: "用户无法快速识别和切换可用的AI角色，配置过程繁琐易错"
|
||
|
||
陷阱2: 定义解决方案而非问题
|
||
错误表述: "提供命令行工具让用户一键生成角色配置文件"
|
||
正确表述: "当前角色配置需要手动操作多个步骤，新用户配置失败率高"
|
||
|
||
陷阱3: 关注能力需求而非缺失痛点
|
||
错误表述: "用户需要可视化的记忆状态监控能力"
|
||
正确表述: "用户对记忆系统运行状态缺乏感知，无法确认功能是否正常"
|
||
|
||
陷阱4: 混合问题与功能清单
|
||
错误表述: "角色初始化复杂，需要包含别名解析、文件生成、状态反馈功能"
|
||
正确表述: "角色初始化过程用户不知道进度，经常不确定是否成功完成"
|
||
```
|
||
|
||
**问题导向自检清单**：
|
||
- [ ] Feature描述中是否包含"功能"、"模块"、"提供"等解决方案词汇？
|
||
- [ ] 是否先描述用户遇到的困难，再描述期望改善？
|
||
- [ ] 能否用"什么问题阻碍了用户"而非"用户需要什么"来概括Feature？
|
||
- [ ] 开发团队看到Feature能理解要解决的痛点，而非要开发的功能？
|
||
|
||
<process>
|
||
# Feature设计流程
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
A[Epic问题域分解] --> B[识别功能场景痛点]
|
||
B --> C[定义问题边界]
|
||
C --> D[分析用户困难]
|
||
D --> E[制定问题解决标准]
|
||
E --> F[Story问题拆解规划]
|
||
F --> G{问题完整性验证}
|
||
G -->|完整| H[Feature就绪]
|
||
G -->|不完整| I[补充问题分析]
|
||
I --> B
|
||
|
||
B1[用户旅程断点分析] --> B
|
||
B2[任务执行障碍识别] --> B
|
||
B3[体验缺失评估] --> B
|
||
```
|
||
|
||
## Feature问题识别方法
|
||
|
||
```mermaid
|
||
mindmap
|
||
root((问题识别))
|
||
用户体验断点
|
||
任务中断节点
|
||
操作困难环节
|
||
反馈缺失场景
|
||
功能缺失分析
|
||
必要能力缺失
|
||
信息获取障碍
|
||
操作效率低下
|
||
技术约束导致的用户问题
|
||
性能瓶颈影响
|
||
兼容性问题
|
||
稳定性缺陷
|
||
```
|
||
|
||
## 📊 问题影响量化模板
|
||
|
||
```markdown
|
||
### 用户痛点量化
|
||
- 具体困难: [用户遇到的具体问题，如"配置角色需要10个步骤"]
|
||
- 影响范围: [受影响用户比例，如"80%的新用户"]
|
||
- 困难成本: [时间/错误损失，如"平均失败3次才成功"]
|
||
- 当前缺失: [什么能力的缺失导致了这个问题]
|
||
|
||
### 功能缺失分析
|
||
- 缺失能力: [具体缺少什么功能支持]
|
||
- 导致后果: [缺失导致的用户困难]
|
||
- 替代方案: [用户当前如何绕过这个问题]
|
||
- 绕过成本: [替代方案的额外成本]
|
||
|
||
### 改善期望
|
||
- 期望体验: [解决问题后用户应该有什么体验]
|
||
- 成功指标: [如何衡量问题得到解决]
|
||
- 优先级: [相对其他问题的重要程度]
|
||
```
|
||
</process>
|
||
|
||
<guideline>
|
||
### Feature问题定义建议
|
||
|
||
- **问题完整性**: Feature应代表完整的问题域，用户困难有明确边界
|
||
- **技术边界对应**: 问题域对应技术模块边界，便于解决方案设计
|
||
- **用户可感知**: 问题是用户直接体验到的困难和障碍
|
||
- **中等粒度**: 1-3个迭代解决，包含3-8个具体问题点(Story)
|
||
|
||
### 问题复杂度分级
|
||
|
||
| 问题类型 | 复杂度 | 解决时间 | Story数量 | 影响范围 |
|
||
|---------|-------|---------|-----------|---------|
|
||
| 简单问题域 | 低 | 1迭代 | 2-4个Story | 单一场景 |
|
||
| 标准问题域 | 中 | 1-2迭代 | 4-6个Story | 多个相关场景 |
|
||
| 复杂问题域 | 高 | 2-3迭代 | 6-8个Story | 跨场景影响 |
|
||
|
||
### 问题边界定义
|
||
|
||
- **包含痛点**: 列出具体的用户困难和障碍点
|
||
- **不包含问题**: 防止范围扩散，明确排除的问题
|
||
- **问题依赖**: 此问题与其他问题的关联和依赖
|
||
- **影响接口**: 解决此问题对其他功能域的影响
|
||
|
||
### Story问题拆解策略
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
A[Feature问题域] --> B[核心困难Story]
|
||
A --> C[操作障碍Story]
|
||
A --> D[信息缺失Story]
|
||
A --> E[反馈不足Story]
|
||
|
||
B --> B1[主要痛点]
|
||
C --> C1[操作困难]
|
||
D --> D1[信息获取问题]
|
||
E --> E1[状态不明确]
|
||
```
|
||
</guideline>
|
||
|
||
<rule>
|
||
1. **四个核心原则必须遵循**
|
||
- 问题完整性: Feature代表完整问题域
|
||
- 用户视角: 从用户困难角度定义问题
|
||
- 可观察性: 问题是用户直接感受到的
|
||
- 边界清晰: 问题域边界明确不重叠
|
||
|
||
2. **强制包含要素**
|
||
- 用户痛点必须具体可观察
|
||
- 问题边界必须明确定义（包含/不包含痛点）
|
||
- 解决标准必须具体可验证
|
||
- Story问题拆解必须覆盖核心困难
|
||
- 问题依赖必须识别和记录
|
||
|
||
3. **三层问题关系规则**
|
||
- Epic → Feature: 价值问题到功能域问题的分解
|
||
- Feature → Story: 功能域问题到具体用户困难的拆解
|
||
- 层级间问题粒度跨度合理，避免过度拆分或粗糙
|
||
|
||
4. **拆分触发条件**
|
||
- 问题域跨越3个以上技术模块需要拆分
|
||
- 包含不相关困难点需要重新组织
|
||
- 解决时间超过3个迭代需要拆分
|
||
</rule>
|
||
|
||
<constraint>
|
||
1. **技术架构约束**
|
||
- 问题域边界受现有架构模块限制
|
||
- 微服务边界影响问题解决方案
|
||
- 数据模型设计影响问题解决范围
|
||
|
||
2. **团队能力约束**
|
||
- 并行解决问题数量有限
|
||
- 团队技能影响问题解决复杂度
|
||
- 跨团队问题需要额外协调成本
|
||
|
||
3. **用户体验约束**
|
||
- 用户旅程完整性不可打断
|
||
- 渐进式改善对问题解决颗粒度的要求
|
||
- 问题优先级受用户影响程度限制
|
||
|
||
4. **项目约束**
|
||
- 迭代时间盒限制问题解决范围
|
||
- 测试资源影响问题验证
|
||
- 发布节奏影响问题解决优先级
|
||
</constraint>
|
||
|
||
<criteria>
|
||
| 评价维度 | 优秀标准 | 合格标准 | 不合格标准 |
|
||
|---------|---------|---------|-----------|
|
||
| 问题清晰度 | 用户痛点具体可观察，困难描述准确 | 问题基本清晰可理解 | 问题模糊或偏向解决方案 |
|
||
| 边界合理性 | 问题域边界清晰，困难点内聚相关 | 边界基本清晰 | 边界模糊或问题分散 |
|
||
| 用户视角 | 完全从用户困难角度描述问题 | 基本体现用户视角 | 偏向系统或技术视角 |
|
||
| 影响量化 | 问题影响范围和程度量化清晰 | 影响基本明确 | 影响不明确或无量化 |
|
||
| 可解决性 | 问题有明确解决标准和验证方式 | 基本可解决验证 | 问题过于抽象或无法验证 |
|
||
| Story拆解质量 | 问题拆解全面，困难点粒度一致 | 拆解基本合理 | 拆解不完整或粒度不一致 |
|
||
| 问题导向性 | 避免解决方案描述，纯问题导向 | 基本问题导向 | 混合解决方案或功能描述 |
|
||
|
||
**快速检查要点**：
|
||
📝 **问题导向**: 描述用户困难而非功能需求，避免"需要"、"提供"、"实现"等词汇
|
||
🎯 **用户视角**: 从用户遇到的具体障碍和痛点角度定义问题
|
||
📊 **困难量化**: 用户痛点影响范围和程度必须量化，有明确解决标准
|
||
🔍 **边界清晰**: 问题域边界明确，困难点内聚，可独立解决和验证
|
||
</criteria>
|
||
</execution> |