变更控制（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/...）

常见坑

1. "小变更"不评估——一个字段改动可能影响 5 个工作流
2. 变更评估不全面——只看工时，忽略风险和已交付物
3. 决策不记录——后来扯皮"为什么改了"
4. 通知不到位——下游工作流不知道变更，照旧执行
5. 频繁接受变更——项目失控，永远做不完
6. 拒绝变更不解释——失去信任
7. 延期的变更不跟踪——永远延期，最后忘了

配套模板

• templates/change-control-template.md — 变更请求 + 影响评估 + 变更日志模板

与其他 skill 的协作

上游：
  product-manager → 提交变更请求

平行：
  risk-management → 评估变更带来的风险
  handoff-protocol → 变更后重新交接

下游：
  wbs-decomposition → 更新任务列表
  critical-path → 重新计算关键路径
  progress-tracking → 追踪变更后的执行