需求变更流程
面向客户与项目双方。
开发开始后，任何对已确认范围的增加、删除 或实质性修改，都按变更处理——避免「顺手改一下」造成工期与质量失控。
1. 什么算需求变更
算变更
- 增加功能、页面、接口、报表、角色权限
- 修改已确认的业务规则、状态机、计算口径
- 修改已确认的接口字段/兼容性（破坏性）
- 要求支持额外环境、额外对接系统
- 明显扩大数据量级或性能指标（超出原假设）
- 验收时新增的「必须现在做」且不在原清单中的项
一般不算变更（但仍建议记一笔）
- 修复违反原验收标准的缺陷
- 文案/提示的纠错（不改规则）
- 原范围内的澄清（不扩大行为）
- 双方已书面预留的配置项调整（在约定幅度内）
有争议时：先冻结开发争议点，书面判定是否变更，再继续。
2. 变更总流程（默认）
提出变更 → 影响评估 → 方案与报价/工期 → 书面确认 → 调整计划 → 开发与验收
| 步骤 | 谁做 | 产出 |
|---|---|---|
| 1. 提出 | 需求方 | 变更说明（模板见下） |
| 2. 澄清 | 双方 | 补齐规则与场景 |
| 3. 影响评估 | 我方为主 | 工期、成本、风险、对已做部分影响 |
| 4. 决策 | 需求责任人 | 做 / 不做 / 放到二期 |
| 5. 书面确认 | 双方 | 变更单或邮件确认 |
| 6. 执行 | 我方 | 排期、实现、自测 |
| 7. 验收 | 需求方 | 按变更项或更新后的清单验收 |
未完成第 5 步书面确认前，不进入开发主线。
3. 如何提出变更（模板）
## 变更标题
## 1. 背景
- 为什么要改：
- 不改的影响：
## 2. 变更内容
- 现状（已确认范围/当前行为）：
- 期望（改完后的行为）：
- 涉及角色/系统/数据：
## 3. 优先级与时间
- 优先级：P0 / P1 / P2
- 是否有硬窗口：
## 4. 验收标准（怎么算改完）
-
## 5. 提出人
- 姓名/角色/日期：
提交渠道：项目约定 的工单、邮件或文档；重要变更避免只留在即时聊天里。
4. 影响评估我们会说明什么
评估回复通常包括：
| 项 | 说明 |
|---|---|
| 工作量/工期 | 人天或日历影响；是否影响里程碑日期 |
| 费用 | 是否超出原合同；如何计（按合同约定） |
| 技术风险 | 数据迁移、兼容、性能、安全等 |
| 对已交付部分 | 是否要回归、是否影响已验收模块 |
| 建议 | 现在做 / 二期 / 换更小方案 |
你有权要求解释依据；我们也有权在信息不足时先要澄清再评估。
5. 确认方式
以下任一可作为「书面确认」（项目可约定其一）：
- 变更单双方签字/盖章
- 邮件明确回复「同意按评估执行」
- 工单状态流转至「已批准」并 @ 责任人
仅表情回复、口头「那就改吧」——默认不作为正式批准（紧急情况见第 7 节）。
确认后应更新：
- 范围说明（做/不做）
- 里程碑计划
- 验收清单
6. 变更与验收的关系
- 变更项应有自己的验收标准
- 原范围已通过部分，不因新变更自动重开全部验收
- 变更引入的缺陷按 如何验收 分级处理
7. 紧急变更
仅当同时满足：
- 不立刻改会造成严重业务损失或安全/合规风险
- 需求责任人可即时决策
则可以：
- 口头/电话授权先做最小止血改动
- 24 小时内补变更单与影响说明
- 补确认后再扩大改动范围
紧急通道不用于「突然想加的普通功能」。
8. 拒绝或延期变更
在下列情况我们可能建议不做或延期：
- 与安全/合规冲突
- 严重破坏可维护性且无合理工期
- 与已确认架构假设根本冲突，需单独立项
- 信息不足以评估，且无法在合理时间内补齐
说明理由与可选替代路径（缩小范围、二期、换方案）。
9. 标准化 API 等固定范围服务
对 RESTful API 开发服务 等范围与报价已标准化的服务：
- 超出服务说明的改动按该服务页的变更/个性规则执行
- 与本文冲突时，以该服务页与合同条款为准