zhaoxuya520 变更控制（Change Control）
参考来源：PMBOK Change Control、Agile Change Management
适用场景
- 项目执行中产品经理临时加需求
- 上游工作流的产物变化
- 外部约束变化（法规、资源、时间）
- 技术方案需要调整
核心原则
1. 变更必经评估
不能"先改了再说"
即使是"小变更"也要评估
2. 变更影响要全面评估
不只是"多花多少时间"
还要考虑：风险、依赖、已交付物的影响
3. 变更决策要记录
接受/拒绝/延期 + 原因
未来复盘时能追溯
4. 变更要通知相关方
已交接的下游工作流必须收到通知
变更评估流程
1. 接收变更请求
↓
2. 描述变更内容
- 变更什么（具体到任务/功能/字段）
- 为什么变（业务原因）
- 紧急程度
↓
3. 评估影响范围
- 影响哪些任务？
- 影响哪些工作流？
- 影响哪些已交付物？
↓
4. 评估对工期的影响
- 增加多少工时
- 是否影响关键路径
- 是否需要延期
↓
5. 评估对风险的影响
- 引入哪些新风险
- 缓解原有风险
- 风险等级变化
↓
6. 决策（接受/拒绝/延期）
↓
7. 如果接受：
- 更新计划
- 通知相关工作流
- 记录决策
↓
8. 如果拒绝：
- 记录原因
- 反馈给请求方
- 提供替代方案（如有）
↓
9. 如果延期：
- 加入下期 backlog
- 记录原因
变更分类
微变更（M-Change）
- 范围：影响单个任务
- 工时：< 30min 增加
- 决策：项目经理可直接决定
- 流程：简化评估即可
例：
- 调整一个错误码的文案
- 增加一个表单的校验规则
标准变更（S-Change）
- 范围：影响 1~3 个任务
- 工时：30min ~ 2h 增加
- 决策：项目经理评估后决定
- 流程：完整评估流程
例：
- 增加一个用户故事
- 调整 API 字段
重大变更（M+ Change）
- 范围：影响 4+ 个任务或多个工作流
- 工时：> 2h 增加
- 决策：需要产品经理 + 项目经理共同决定
- 流程：完整评估 + 风险审查 + 利益相关方确认
例：
- 增加新功能模块
- 重构核心流程
- 改变技术架构
变更影响评估模板
## 变更评估：[变更标题]
### 变更基本信息
- **变更编号**：CR-001
- **请求方**：product-manager / 客户 / 外部约束
- **请求时间**：YYYY-MM-DD HH:MM
- **紧急程度**：紧急 / 高 / 中 / 低
### 变更描述
**变更内容**：
[具体到任务/功能/字段]
**变更原因**：
[业务原因或外部约束]
### 影响评估
#### 任务影响
| 任务 ID | 影响类型 | 影响描述 |
|---------|---------|---------|
| T4 | 修改 | 增加 3 个字段 |
| T5 | 新增 | 新增校验逻辑 |
| T7 | 修改 | 测试用例需要更新 |
#### 工作流影响
| 工作流 | 影响 | 需要的工作 |
|--------|------|----------|
| api-designer | 修改契约 | +15min |
| backend | 实现新字段 | +30min |
| frontend | 更新表单 | +20min |
| qa | 补充测试 | +15min |
#### 工期影响
- 总增加工时：80min
- 是否影响关键路径：是 / 否
- 整体延期：从 +160min 到 +200min
#### 风险影响
- 新增风险：
- R6: 新字段可能与现有数据冲突
- 加剧已有风险：
- R3 (QA 测试发现 Bug) 概率提升
### 决策
**决策**：✅ 接受 / ❌ 拒绝 / ⏰ 延期到下期
**决策人**：[项目经理 / 产品经理]
**决策理由**：
[为什么这样决策]
### 接受后的行动
- [ ] 更新 PRD
- [ ] 更新 API 契约
- [ ] 通知 backend / frontend / qa
- [ ] 调整里程碑时间点
- [ ] 更新风险清单
### 通知清单
- [ ] product-manager
- [ ] api-designer
- [ ] backend-engineer
- [ ] frontend-engineer
- [ ] qa-engineer
变更决策矩阵
价值（业务/用户）
低 中 高
┌─────┬─────┬─────┐
高 │ 拒 │ 延 │ 评估 │
成 ├─────┼─────┼─────┤
本 中 │ 拒 │ 评估│ 接受 │
├─────┼─────┼─────┤
低 │ 延 │ 接受│ 接受 │
└─────┴─────┴─────┘
成本 = 工期 + 风险 + 复杂度
价值 = 业务影响 + 用户价值 + 紧急程度
工作流程
1. 收到变更请求
↓
2. 分类（微/标准/重大）
↓
3. 评估影响（用模板）
↓
4. 应用决策矩阵
↓
5. 决策（接受/拒绝/延期）
↓
6. 记录决策（写入变更日志）
↓
7. 通知所有相关方
↓
8. 更新计划/PRD/API 契约等
↓
9. 调整后续任务的依赖关系
质量自检
□ 变更内容是否具体（不是"优化一下"）
□ 是否评估了所有受影响的任务
□ 是否评估了所有受影响的工作流
□ 是否评估了风险变化
□ 决策是否有记录（不是口头说说）
□ 是否通知了所有相关方
□ 是否更新了已交付物（PRD/API/...）
常见坑
- "小变更"不评估——一个字段改动可能影响 5 个工作流
- 变更评估不全面——只看工时，忽略风险和已交付物
- 决策不记录——后来扯皮"为什么改了"
- 通知不到位——下游工作流不知道变更，照旧执行
- 频繁接受变更——项目失控，永远做不完
- 拒绝变更不解释——失去信任
- 延期的变更不跟踪——永远延期，最后忘了
配套模板
templates/change-control-template.md— 变更请求 + 影响评估 + 变更日志模板
与其他 skill 的协作
上游：
product-manager → 提交变更请求
平行：
risk-management → 评估变更带来的风险
handoff-protocol → 变更后重新交接
下游：
wbs-decomposition → 更新任务列表
critical-path → 重新计算关键路径
progress-tracking → 追踪变更后的执行