外包项目做到一半，需求变了——这几乎是必然的。真正的问题不是"变不变"，而是变了之后谁来评估、谁来确认、费用怎么调。没有变更机制的项目，会陷入两种结局：要么开发方无限免费加班，要么甲方被反复加价。本文讲清变更机制怎么建。
第一步：先把"范围"钉死
变更的前提是有个基准。建议以《需求规格说明书》或《工作说明书（SOW）》作为合同附件，明确：
- 功能清单
- 页面清单
- 集成清单
- 不包含项
"不包含项"最容易被忽略，也最重要。例如第三方系统改造、硬件采购、内容制作、运营推广，如果不写清"不含"，后期就会被默认"含"。
需求版本号要固定：每次确认后给版本编号，避免"我们说的不是这版"。
第二步：建立四步变更流程
``` 提出 → 评估工作量 → 双方书面确认（变更单）→ 调整工期与费用 ```
四步缺一不可。其中"书面"是关键：口头约定在争议时几乎无法举证。变更单要记录：变更内容、影响范围、工作量评估、工期与费用调整、双方确认签字。
第三步：区分三类"变化"
不是所有变化都叫"需求变更"。建议分类处理：
| 类型 | 说明 | 处理方式 |
|---|---|---|
| 缺陷 | 与已确认需求不符 | 开发方免费修复 |
| 变更 | 对已确认需求的调整 | 走变更单，评估费用 |
| 新增 | 原范围之外的新需求 | 走变更单，另行报价 |
分类清晰，双方对"该不该加钱"就有了共同的判断依据。
第四步：把机制写进合同
- □ 需求文档作为附件，标注版本号
- □ 明确列出"不包含项"
- □ 变更四步流程与变更单模板
- □ 缺陷 / 变更 / 新增的判定标准
- □ 变更对工期与费用的调整规则
什么是"需求冻结"，什么时候该冻
需求冻结，指在某个时间点之后停止接收新需求，进入开发与测试阶段。它不是"不许改"，而是给项目一个稳定的执行窗口。
建议的做法是分阶段冻结：原型确认后冻结主流程，开发中期冻结交互细节，测试阶段只接受缺陷修复。没有冻结的项目，会一直在"改需求—返工—再改"的循环里打转，最终谁都疲惫。
如果确实需要在冻结后变更，就走变更流程，并同步调整工期与费用——这比"默默改掉"要诚实得多。
变更单要记哪几项
一份合格的变更单，至少包含：变更内容描述、影响范围、工作量评估、工期与费用调整、双方确认。记录得越具体，事后越不容易扯皮。
需求文档要写到什么颗粒度
写得太粗（"做一个会员系统"），开发方可以自由发挥，最终结果未必是你想要的；写得太细（每个按钮的位置都写死），又会让项目僵化、变更频繁。
一个实用的参考是：写到"能被验收"的颗粒度。
- 功能层面：有哪些角色、能做哪些操作、边界情况怎么处理；
- 数据层面：有哪些字段、字段的含义与约束；
- 交互层面：主流程是什么、异常怎么提示。
交互细节可以留到设计阶段确认，功能与数据边界必须在需求阶段定死。 这条分界线划对了，需求文档就不会成为"越改越多"的源头。
需求变不可怕，可怕的是没有机制。把范围钉死、把流程写清、把三类变化分开处理，项目就不会在"改来改去"中失控。