【摘要】
项目第二个月，客户 IT 主管在周会上说："报表里加一个设备编号字段，很简单吧？"
按本专栏的报价原则，这个字段在 Fab 环境下的完整变更是 8 万元。很多人第一反应是"抢钱"——一个字段能要多少钱？这篇就把这 8 万一层一层摊开：变更的真实成本从来不在"改"这个动作上，而在涟漪上。看完你就明白，为什么直接答应"加个字段很快"的 FDE，项目都会死在第四个月。
【核心要点】
- 变更成本的主体不是"改代码"，是涟漪：一个字段在 Fab 系统里平均波及十层
- 直接成本可以当着客户的面算，算完报价就不是态度问题而是数学问题
- 免费、悄悄做、打折做——三种"善意处理"都会让变更失去控制
- 变更记录不是留证据甩锅，是唯一能让你在验收时说清"范围为什么长这么大"的东西
- 真正的功夫在合同：变更流程写进合同附件，报价时才有依据
---
一、一个字段的十层涟漪
先看这个"设备编号字段"到底要动多少东西。
| 层 | 改什么 | 工时 | 说明 |
|---|---|---|---|
| 1 | 界面 | 8h | 输入框、校验提示、列表列 |
| 2 | 数据库 | 4h | 加字段、索引、长度约束 |
| 3 | 采集链路 | 24h | EAP 上报报文加字段、设备侧联调——这项经常被忘 |
| 4 | 历史数据 | 16h | 存量数据这个字段填什么？补录还是留空？留空的查询行为要定义 |
| 5 | 权限 | 8h | 谁能改这个字段？改动要不要审批？ |
| 6 | 审计日志 | 8h | 改动留痕，Fab 质量体系通常强制 |
| 7 | 对外接口 | 16h | 下游三个系统（MES/ERP/报表库）接口全要加字段、回归测试 |
| 8 | 报表与看板 | 12h | 四张报表按这个字段重新分组汇总 |
| 9 | 测试 | 32h | 全链路回归，不是单点测 |
| 10 | 文档与培训 | 8h | 用户手册、操作视频、变更公告 |
合计 136 小时。按两人月 5.5 万的交付成本口径，再加 20% 的项目管理与风险摊销，就是 8 万的来源。没有一个数字是编的，每个都能摊给客户看。
这里的关键认知：第 3 层（采集链路）和第 7 层（对外接口）占了工时的大头，而它们恰恰是客户看不见的。客户说"加个字段"时想的是第 1 层，8 个小时的事。你的成本在冰面以下。
二、三句最贵的话
第一句："行，这个我顺手做了。"
免费变更的代价不是这一次的 136 小时，是先例。客户学到的是：提需求不要钱。第二次他会提五个字段，第三次是十次小变更。到第四个月，你的排期全部是变更，原定范围反而没人推——项目由此失控。免费帮助和商业自杀，很多时候是同一个动作。
第二句："行，不过这次先不给钱，下次一起算。"
比免费更糟。下次一起算意味着这次没有变更单、没有签字、没有范围基线更新。到结算时客户看到的账单上突然多出十几条"上次说好的"，他不记得，也不认。你要是为收这笔钱打官司，连证据都没有。
第三句："这次少收点，收个成本价。"
打折变更同样是失控：客户学到的不是"这次便宜了"，而是"他的报价有水分"。以后所有的报价都会被打折预期，包括那些本来就不挣钱的。
三种处理共享同一个错误：把变更决策变成了关系决策。而变更管理的全部要点，恰恰是把它变回数学决策。
三、当着客户的面把账算出来
报价 8 万被骂"抢钱"，是因为这个数字是直接抛出来的。正确的做法是把摊算过程做成会议现场动作：
- 客户提出加字段。
- 你当场打开影响分析清单（十层，就是上面那张表），逐层过："界面这边 8 小时；但你们设备上报的报文要加这个字段，EAP 联调 24 小时，这部分要你们设备科配合三天……"
- 过到"历史数据"时停下来问："存量 40 万条记录，这个字段是留空还是补录？补录的话你们工艺部要抽两个人干一周。"
- 过完，把工时合计亮出来："合计 136 小时，按合同附件三的费率，报价 8 万。"
这个流程走完，通常出现三种结果：
- 客户撤回："那算了，不加也行。"——说明它本来就不痛，皆大欢喜。
- 客户砍范围："采集那边先不动，只在报表层加。"——太好了，范围缩小，这是变更管理最好的 outcome。
- 客户认价："确实需要，走变更单。"——8 万入了账，范围基线更新。
注意第三种结果里你拿到了什么：不止是钱，还有客户对自己需求的再次确认。付过钱的变更，验收时客户会认真看；免费的变更，客户根本不记得自己要过什么。
四、变更单的最小字段集
变更单不需要走 OA 那种十级审批，但下面七个字段一个不能少：
| 字段 | 为什么必须有 |
|---|---|
| 变更编号 | 后续所有文档引用它 |
| 描述（做什么） | 一句话说清，防止"你当时说的不是这个" |
| 影响分析（十层过一遍的结果） | 报价的依据，也是撤回的台阶 |
| 工时与报价 | 数字要能对上影响分析 |
| 对排期的影响 | "本项目上线日期顺延两周"——这句比报价更让客户认真 |
| 双方签字 | 电子签即可，微信确认截图也聊胜于无 |
| 状态（提请/评估/接受/拒绝/完成） | 月度复盘时用 |
其中"对排期的影响"这一栏，很多 FDE 不敢填——怕客户不满。但变更的真实代价本来就有时间成分，藏起来等于你在替客户承担他的决策成本。填上去，客户会自己权衡：要么加钱，要么这个变更真的不急。
五、变更记录的真正用途
很多人把变更记录当成防扯皮的证据，这低估了它。它有三个更有价值的用途：
1. 验收时的范围说明书。验收会上客户说"这个功能怎么没做"，你翻开变更记录："这条当时评估过，你们选择不做，签字在这里。"一句话，十分钟结束争议。没有变更记录，同样的争议要吵一整天，还可能升级到双方老板。
2. 版本规划的输入。把所有被拒、被推迟的变更列一张清单，就是 V2 的现成需求池——而且都是客户真实提过的，不是你猜的。
3. 报价体系的校准。三个月后复盘：当初报 8 万的变更实际花了 110 小时，说明费率或影响系数要修。变更记录越全，你的报价越准——这是 FDE 从"被甲方拿捏"变成"专业对话"的底层能力。
六、功夫在合同
以上所有动作的前提，是合同里有变更条款。至少三条：
- 变更流程：书面提出 → 影响分析 → 报价 → 双方签字 → 实施。口头需求一律回一句"走一下变更流程"。
- 费率表：人天单价写进附件。没有费率表，每次变更报价都是一次谈判，谈十次崩三次。
- 排期联动：变更接受后交付日期自动顺延。这条不加，你就等于承诺"又加钱又提前"，不可能做到。
如果合同已经签了、里面没有这些条款怎么办？从下一次变更开始补：做一份《变更管理说明》发给客户对接人，请他确认。多数客户会配合——因为这套流程保护的不只是你，也保护他对接人自己（他向上汇报时也需要变更记录说明范围为什么变了）。
七、可复用点
- 变更成本在涟漪不在动作：一个字段十层波及，大头在客户看不见的采集链路和对外接口。
- 免费、记账、打折，三种善意处理都会让变更失控。把变更从关系决策变回数学决策。
- 当着客户的面摊影响分析：撤回、砍范围、认价——三个结果都比"硬扛或硬收"好。
- 变更单七字段：编号、描述、影响分析、报价、排期影响、签字、状态。排期影响那栏别藏。
- 变更记录是验收说明书、V2 需求池、报价校准器三合一。
- 变更流程、费率表、排期联动，这三条要写进合同。没有就趁下次变更补。
下一篇讲怎么拒绝不合理需求——卷 0 导读里预告过的一篇：客户的需求既不违法也不亏钱，但会把你拖进泥潭，这时候怎么说不。