业务篇 · 04 · 需求变更管理
本章目标
让变更可控、可追溯、可计价，而不是"产品拍脑袋、开发背锅、测试重做"。
一、为什么需求变更会失控
1.1 常见灾难场景
| 场景 | 后果 |
|---|---|
| "这个功能能不能微调一下？" | 开发悄悄改，测试不知道 |
| "之前说的那个去掉" | 没记录，下次有人问起想不起来 |
| "改一下而已，很小的改动" | 实际改动涉及 5 个模块 |
| "上线前一天加一个需求" | 测试被压缩、Bug 激增 |
| "老板临时提了个要求" | 流程被绕过 |
1.2 变更管理的核心原则
- 所有变更都要书面化（不接受口头变更）
- 所有变更都要评估影响（不接受"小改动"的借口）
- 所有变更都要经过决策（不接受单方面决定）
- 所有变更都要通知下游（不接受"你自己没关注"）
- 变更要有窗口期（不接受上线前一天变更）
二、变更请求的标准流程
提出变更 ──► 登记 ──► 影响评估 ──► 决策会议 ──►
├─► 批准 ──► 执行 ──► 通知下游
├─► 延后 ──► 进下版本 backlog
└─► 驳回 ──► 归档
2.1 变更请求单（CR - Change Request）
# 变更请求 CR-2026-0042
## 基本信息
| 项目 | 值 |
|------|-----|
| CR ID | CR-2026-0042 |
| 提交人 | 张三（产品） |
| 提交日期 | 2026-04-15 |
| 关联版本 | v1.2.0（正在测试） |
| 紧急程度 | P1 |
| 变更类型 | 新增 / 修改 / 删除 |
## 变更内容
### 变更前（现状）
[描述现在是什么样]
### 变更后（目标）
[描述改成什么样]
### 变更原因
[为什么要改，不改会怎样]
## 影响评估
### 影响的 PRD 章节
- REQ-012 批量导出
- REQ-015 订单详情
### 影响的代码模块
- 待开发评估
### 影响的测试用例
- 待测试评估（预估 20+ 条）
### 影响的文档
- 用户手册第 3 章
- 接口文档 /api/order/export
### 工期影响
- 待开发评估（预估 3-5 天）
### 风险
- 已测试完成的模块需要回归
- 数据库 schema 可能需要迁移
## 决策
- [ ] 批准 — 本版本执行
- [ ] 批准 — 推迟到 v1.3
- [ ] 驳回 — 原因：____
### 参与决策人
- 产品负责人：______
- 技术负责人：______
- 测试负责人：______
- 项目经理：______
## 执行记录
- 开发完成：______
- 测试完成：______
- 上线确认：______
2.2 影响评估的深度
轻度变更（文字表述/UI 微调）：产品自己评估。
中度变更（业务逻辑小调整）：
- 开发评估 1-2 小时
- 测试评估影响面
- 项目经理确认排期
重度变更（新增/删除功能、架构调整）：
- 召开专项评审会
- 开发架构师参与
- 可能需要延期发布
三、变更窗口期
3.1 不同阶段的变更代价
需求阶段 设计阶段 开发阶段 测试阶段 上线前 上线后
│ │ │ │ │ │
1x 代价 3x 10x 30x 100x ???
结论：越晚变更代价越高，指数级增长。
3.2 版本冻结期（推荐）
版本周期 (2 周):
第 1-3 天: 需求评审 ← 变更免费
第 4-5 天: 设计评审 ← 小变更可接受
第 6-10 天: 开发 ← 需要 CR 流程
第 11-13 天: 测试 ← 原则上冻结，紧急变更需高级审批
第 14 天: 上线前 24h ← 彻底冻结，只接受 P0 热修
四、紧急变更（Hotfix）
4.1 什么情况可以紧急变更
只有这些情况：
- 线上故障必须修
- 法律法规要求
- 安全漏洞
- 数据丢失风险
不属于紧急的：
- ❌ "这个功能也顺便加一下"
- ❌ "老板说要改"
- ❌ "客户反馈要快"（要走正常流程）
4.2 紧急变更的简化流程
发现问题 ──► 上报 ──► 评估 ──► 决策 ──► 执行 ──► 事后补流程
（1小时内） （2小时内） （24小时内补齐文档）
关键：事后必须补齐 CR 文档，否则下次复盘没证据。
五、变更沟通机制
5.1 变更通知模板
📢 变更通知 - CR-2026-0042
【变更内容】
批量导出订单从 10,000 条上限改为 50,000 条
【影响范围】
- 后端: order-service/export.ts
- 前端: 订单列表页的导出按钮提示
- 测试: 用例 TC-042 ~ TC-048 需重测
【执行人】
开发: 李四
测试: 王五
【预计完成时间】
2026-04-18 18:00
【需要你配合的事项】
@测试团队: 回归 TC-042 ~ TC-048
@运维: 关注导出接口的 CPU/内存波动
--- 产品部 张三
5.2 通知渠道
| 渠道 | 用于 |
|---|---|
| 邮件 | 正式记录，归档用 |
| 企业微信/Slack 群 | 快速同步，所有相关人 |
| Issue/MR 评论 | 代码层面的同步 |
| 项目管理工具（Jira/Tapd） | 状态跟踪 |
最佳实践：三者并行，互为备份。
六、变更的数据看板
6.1 需要跟踪的指标
| 指标 | 目标 | 意义 |
|---|---|---|
| 版本内变更次数 | ≤ 3 次 | 过多说明需求不稳定 |
| 紧急变更占比 | ≤ 10% | 过高说明计划不充分 |
| 变更导致的延期天数 | ≤ 2 天 | 过多说明变更管理失控 |
| 变更驳回率 | 30-50% | 过低说明把关不严 |
| 变更平均处理时长 | ≤ 2 天 | 过长说明流程低效 |
6.2 月度复盘
## 2026-04 月度变更复盘
**总变更数**: 23
- 批准立即执行: 8
- 批准延后: 12
- 驳回: 3
**按版本分布**: v1.2 (15), v1.3 (8)
**按来源**:
- 产品主动: 10
- 客户反馈: 8
- 开发发现: 3
- 运维要求: 2
**问题**:
- v1.2 第 2 周变更 6 次，导致测试延期 3 天
- "老板临时要求"占了 4 次，需要加强管控
**改进措施**:
- 引入"变更冻结期"
- 老板类需求走产品负责人代传
七、配套资源
- 01 PRD 编写规范
- 测试篇 · 提测门禁（变更会影响提测达标）
- 开发篇 · 分支策略（变更与分支管理）