去年冬天一个机房改造项目的周例会上，甲方负责人指着大屏上那句"总体完成度 82%"问我：这个 82% 是怎么算出来的，剩下的 18% 还要再花多少钱。项目经理答不上来，因为那个 82% 是几个小组长各自拍脑袋报数后取的平均值。当天下午我把他拉进小会议室，用半小时把挣值管理里最基础的 PV、EV、AC 三个数重新捋了一遍，再套上 SPI、CPI 两个指数，那场对话的画风立刻就变了——不再是"完成了多少"，而是"按计划该完成多少、实际挣回了多少价值、为此花掉了多少成本"。这三个问题一旦能各自用钱说清楚，项目的真实处境就藏不住了。

挣值管理（Earned Value Management）这套方法本身不新，公式也就那么七八个，但它是我见过的"公式最简单、落地最困难"的管理工具之一。PV（计划价值）、EV（挣值）、AC（实际成本）三个输入一旦口径不统一，后面算出来的 SV、CV、SPI、CPI 全都是精致的废话；而只要口径立住了，EAC、ETC、VAC、TCPI 这些往前看的预测指标就能真正指导决策。这篇内容我打算分两条线写：一条是把它当管理工具用在系统集成类项目上，怎么定基准、怎么计量、怎么采集、怎么纠偏；另一条是把考试里反复出现的计算题口径和陷阱单独拎出来拆一遍。不管你是刚接手项目台账的新人，还是考过一轮又忘了公式的老手，看完应该都能把这张表在自己项目上跑起来。

1. 三个"钱袋子"先摸清：PV、EV、AC 各自的计量口径

挣值管理的所有争论，九成以上不是发生在公式层面，而是发生在"这个数到底算不算"的层面。我在复盘会上见过太多次这样的场面：两个人拿着同一份周报，一个说成本超支，一个说成本可控，吵到最后发现一个人算 AC 时把已签合同未到货的采购预付款算进去了，另一个人没算。所以别急着背公式，先把三个钱袋子的边界画清楚。

1.1 用一个装修场景把三兄弟摆到台面上

假设你请人装修一套 100 平的房子，合同价 30 万，工期 3 个月。第一个月月底你去现场看：按施工计划，这个月应该做完水电改造加一半瓦工，这部分工作量折算下来值 10 万；实际现场只把水电做完了，验收确认的完成量折算下来值 6 万；而你已经付出去的材料款和人工费加起来 9 万。

• PV = 10 万，全称 Planned Value，中文叫计划价值，也有资料写 BCWS（计划工作预算成本）。它回答的是"到今天为止，按原计划我应该干出多少价值"。
• EV = 6 万，Earned Value，挣值，也叫 BCWP（已完成工作预算成本）。它回答的是"到今天为止，我实际上干出了多少价值"，注意它用的是预算单价折算，不是实际花的钱。
• AC = 9 万，Actual Cost，实际成本，也叫 ACWP。它回答的是"为了干出上面这些活，我实际付出去了多少钱"。

三个数摆在一起，故事就出来了：进度上你该挣 10 万只挣了 6 万，落后；成本上你挣了 6 万却花了 9 万，超支。这两个结论都不需要任何高深分析，只要三个数的口径是对的。而现实中绝大多数项目的周报，只报"完成度 82%"这种没有任何计量基准的数字，本质上等于什么都没报。

我在实际项目里给三个数各配了一句话，团队里新来的人一听就懂：PV 是"应该"，EV 是"干成了"，AC 是"花掉了"。凡是和这三个词对不上的数据，一律退回重报。

1.2 PV 不是把总预算除以工期，而是从成本基准里"切"出来的

新手最容易犯的错，是把 BAC（完工预算）按工期平均分摊。800 万的项目 20 周，就认为每周 PV 是 40 万，第 10 周末 PV 就是 400 万。这个算法在某些人力密集型项目上勉强能用，但放到系统集成项目上会严重失真，因为这类项目的成本分布天然是阶梯状的。

一个典型的中型集成项目，钱是这样花的：前期设计咨询占比很小，第 3 到第 7 周硬件设备集中到货，这一段 AC 和 PV 会同时陡增；中间机房施工和软件开发并行，成本相对平缓；最后联调和试运行阶段，人力投入反而会出现一个小高峰。整条 PV 曲线应该是前缓、中陡、后翘的 S 形，而不是一条斜直线。

正确的做法是自下而上滚出来的：

1. 先把项目拆到控制账户（Control Account）层级，每个控制账户对应 WBS 上的一个可管理单元，有唯一责任人、独立预算、可测量的产出物。
2. 每个控制账户内部再把预算分配到具体的进度活动上，形成"某活动在某时间段内计划消耗多少预算"。
3. 按时间轴把所有活动的预算累加，就得到这条 PV 曲线。

打个比方，PV 就像给项目排的一张"预算消耗时刻表"。它不是平均数，而是排班表——哪天该上多少人、该进多少货，对应那天就该消耗多少预算。

提示：PV 一旦随基准确定下来就应该是冻结的。除了走正式变更流程调整 BAC 并重新基线化，任何时候都不要因为"这个月实际情况特殊"而去手工修 PV。PV 一动，SPI 就失去了全部意义。

1.3 EV 的计量规则，决定了整套体系可不可信

如果说 PV 是排班表，那 EV 就是考勤加产量记录，而这里恰恰是挣值管理最容易掺水的地方。常见的 EV 计量规则有四种，各有适用场景：

我在项目上见过最离谱的一次，是一个联调工作包连续六周报"完成度 90%"。第六周的时候我让负责人把剩下的工作列出来，列了 47 项，其中 12 项是阻塞状态。所谓 90%，只是因为他觉得"大框架搭好了"。

对付主观百分比，我的经验是三条：

• 把工作包拆小。任何超过两周（或 80 工时）的工作包都必须继续拆，拆到能在一次周报周期内明确判定"完成/未完成"为止。这是 0/100 法能用的前提。
• 用可验证的客观量替代百分比。软件开发不要报"完成 70%"，改报"32 个功能点中 21 个通过单元测试、14 个通过集成测试"；机房施工不要报"完成一半"，改报"86 个信息点中 63 个完成端接并测试合格"；联调阶段报"用例通过率"。计量单位一变，数字立刻就诚实了。
• 完成度只在验收节点上跳变。允许中间过程不涨 EV，但要求每个控制账户至少每两周有一个可验收的交付物。如果某个账户连续两周 EV 不动，那本身就是需要干预的信号。

这里有个容易被忽略的道理：EV 用的是预算单价折算，不是实际成本折算。也就是说，一个工作包的预算是 20 万，哪怕你实际花了 35 万才干完，它完成后计入的 EV 也只有 20 万。这一点决定了 CV = EV - AC 才能反映真实的成本偏差——如果 EV 按实际成本算，CV 永远等于 0，整套体系就废了。

1.4 AC 的口径最容易和财务口径打架

AC 是三个数里唯一需要和财务部门打交道的，也最容易出岔子。我总结下来有四个必须提前约定的口径问题：

第一，权责发生制还是收付实现制。硬件设备到货验收了但款项下个月才付，这笔钱算不算本期的 AC？按项目管理的逻辑必须算——活儿已经干完了，成本已经发生了，只是钱还没出门。如果按财务付款流水来算 AC，就会出现"EV 涨了 AC 没涨"的假节约，CPI 虚高得离谱。这条必须在项目启动时就写进成本管理计划。

第二，是否含税、是否含分摊。设备采购 100 万含税还是不含税，差 13 个点，直接决定 CPI 是 0.95 还是 1.07。管理费、场地费、公共资源摊销要不要按比例分摊进各控制账户，也要说清楚。我的做法是：成本基准里统一用含税口径，公共分摊单独设一个控制账户，不摊到执行账户里，这样执行层的 CPI 才干净。

第三，人力成本怎么折算。内部人力不是不花钱，而是要按标准费率（人天单价 × 实际投入人天）折算，否则自己人干得越多，CPI 反而越好看，完全违背直觉。工时数据从工时系统里出，不要让人自己回忆"这个月大概投了多少天"。

第四，承诺成本（Commitment）要不要计入。已经下发的采购订单但设备还没到，这笔钱在账上还没发生，我的处理是不计入 AC，但在风险台账里单独跟踪，因为它迟早要变成 AC，提前知道能避免"最后一个月突然爆表"。

注意：AC 的数据源必须唯一。我见过一个项目，工程部按报量算一套成本，财务按付款算一套，两边月底对账能对一整天。正确做法是指定一个主数据源（通常是财务的项目辅助核算账），工时费用按规则折算后并入，其余口径一律作废。

2. SV、CV、SPI、CPI：四个数字对应的四种项目状态和处置动作

三个输入数立住之后，四个派生指标就是纯算术了。但我在带新人的时候发现，公式谁都会背，真正难的是看到 SV = -40 万、SPI = 0.9 之后，知道下一步该干什么。这一节重点讲"读懂"，而不是"算出"。

2.1 偏差是绝对量，绩效指数是相对量，两者的用途完全不同

四个公式先摆出来，用"应该、干成了、花掉了"三个词一套就记住了：

偏差（SV、CV）的价值在于绝对量级。CV = -40 万，说明你这个项目实打实多花了 40 万，这个数字可以直接拿去做资金计划、去跟老板汇报。但偏差不能横向比较——一个 800 万的项目 SV = -40 万和一个 200 万的项目 SV = -40 万，严重程度差着量级。

绩效指数（SPI、CPI）的价值在于可比性。CPI = 0.9 意味着"每花 1 块钱只挣回 9 毛"，这个比率可以跨项目、跨部门、跨时间横向比，也可以做趋势分析。所以对外汇报用指数，对内决策用偏差，两者搭配着看。

有个细节必须提醒：符号约定不要混用。主流体系（包括国内这门资格考试）都是 EV − PV、EV − AC，正值代表好。但我确实见过一些老资料用 PV − EV，那样正值代表落后，一不小心就会把结论说反。团队内部统一一套，写在模板表头里。

另外说一句大白话：SV 和 CV 的"单位是钱"这件事，容易让人误以为 SV 反映的是成本问题。不是的，SV 反映的是进度问题，只是用钱做了度量单位。这一点在向非专业领导汇报时特别容易被曲解，我一般会补一句"这是我们少完成的工作量折算成的预算值"，避免对方理解成"我们少赚了这些钱"。

2.2 四个指标的两两组合，对应四种截然不同的处置逻辑

单独看 SV 或单独看 CV 都容易误判，四个数放在一起看才有意义。下面这张表是我自己在项目上用的判断矩阵：

第二种组合（SPI > 1 但 CPI < 1）是我在系统集成项目里见得最多的一种，也是最容易被管理层误读的一种。周报上 SPI = 1.1，领导一看"进度提前，很好"，实际上 CPI = 0.85，项目正在用超支换进度。这种情况如果不干预，等进度红利耗尽，剩下的就是纯亏损。

第三种组合（SPI < 1 但 CPI > 1）看着像好消息，其实往往是资源投入不足造成的。花钱是省了，但进度欠的债迟早要还，而且往往要在最后阶段用加班和赶工的方式还，那时候的 CPI 会断崖式下跌。我在一个项目上见过 CPI 连续三个月 1.12，第四个月直接掉到 0.87，就是因为前期把测试人力砍了，最后集中补测。

第四种组合没什么好说的，立刻进入问题处置流程。但要注意，双落后的时候不要急着让团队"努力一点"，先分清是估算错了还是执行错了，这两者的应对方式完全不同。

2.3 一次完整的手算演练：800 万、20 周的项目做到一半

拿一个具体项目走一遍，数字我尽量取得好算一点。

某系统集成项目，总预算 BAC = 800 万元，计划工期 20 周。第 10 周末做绩效检查，数据如下：按计划应完成的工作预算为 PV = 400 万元；实际已完成工作按预算单价折算 EV = 360 万元；截至当期实际发生成本 AC = 400 万元。

先算四个基础指标：

• SV = EV − PV = 360 − 400 =−40 万元，进度落后，落后的工作量相当于 40 万预算。
• CV = EV − AC = 360 − 400 =−40 万元，成本超支 40 万。
• SPI = EV ÷ PV = 360 ÷ 400 =0.90，进度效率是计划的 90%。
• CPI = EV ÷ AC = 360 ÷ 400 =0.90，成本效率是预算的 90%。

这组数字很"标准"：进度和成本同步落后 10%，说明大概率不是一个偶发问题，而是系统性的效率偏低或者估算偏差。如果 SV = −40 而 CV = 0，那更可能是资源到位晚了；现在两个都差，得往人力效率、返工率、供应商履约这几个方向查。

这里补一句实操经验：算出指标只是开始，拆到控制账户才是干活。整体 CPI = 0.9 是个平均数，可能掩盖了一个 CPI = 0.6 的硬件采购账户和一个 CPI = 1.05 的软件开发账户。平均数最擅长的事情就是掩盖问题。我要求所有项目的绩效报告至少下钻到控制账户一级，超过三个账户亮红灯才升级到项目级分析。

3. 往前看：EAC、ETC、VAC、TCPI 决定这个项目还救不救得回来

SV、CV、SPI、CPI 都是"向后看"，告诉你已经发生了什么。管理层真正关心的是"最后会怎么样"。这就轮到完工估算体系上场了，而这里面最容易出错的地方，是选错 EAC 的计算公式。

3.1 四种 EAC 算法，选哪个取决于偏差的性质

EAC（完工估算）有四种主流算法，很多人背不下来是因为没搞清它们的适用前提。核心判断只有一个问题：当前的偏差是偶发的，还是系统性的、会一直持续下去的？

我个人的取用习惯是这样：日常滚动预测用典型偏差法，因为它最保守也最稳定；一旦识别出明确的一次性事件（比如某个供应商涨价一次性影响，后续已换供应商），就把这部分从偏差里剔出去，用非典型偏差法重算；只有在项目出现重大范围变更、原估算基本作废的时候，才动用自下而上重估，这个动作很重，一个中型项目做一次要花两三天。

用上一节的例子接着算：

• 典型偏差法：EAC = BAC ÷ CPI = 800 ÷ 0.9 =888.9 万元，预计超支 88.9 万。
• 非典型偏差法：EAC = AC + (BAC − EV) = 400 + (800 − 360) =840 万元，预计超支 40 万。
• 两者差了近 49 万，这个差额就是"你相不相信团队能把效率拉回来"的价钱。跟老板汇报的时候，两个数都给，把假设讲清楚，比自己拍一个数靠谱得多。

配套的还有三个衍生指标：

• ETC（完工尚需估算）= EAC − AC，典型偏差法下是 888.9 − 400 = 488.9 万元，这是你接下来还需要申请的资金。
• VAC（完工偏差）= BAC − EAC= 800 − 888.9 =−88.9 万元，负数代表预计超支。
• TCPI（完工尚需绩效指数），下面单独说。

3.2 TCPI 是"最后通牒的量化"，比 EAC 更能让人清醒

TCPI 的计算有两套：

• 基于原预算：TCPI = (BAC − EV) ÷ (BAC − AC)
• 基于完工估算：TCPI = (BAC − EV) ÷ (EAC − AC)

它的含义是：为了在剩余预算内完工，剩下的每一块钱必须干出多少价值。用上一节的数算：TCPI = (800 − 360) ÷ (800 − 400) = 440 ÷ 400 =1.10。

这个 1.10 是什么意思？意思是团队此前一直以 0.90 的效率在干活，现在必须立刻把效率提到 1.10，才能在原预算内收尾。也就是说，效率要提升 22%，而且要立刻、全面、无过渡期地提升。这才是这个指标真正的杀伤力所在——它把"我们后面加把劲"这种空话，变成了一个可以当场反驳的数字。

我一般给管理层看这样的判据：

• TCPI ≤ 1.0：剩余预算有富余，正常推进即可。
• 1.0 < TCPI ≤ 1.1：需要明显改进，但努努力可能做到，重点抓返工和浪费。
• 1.1 < TCPI ≤ 1.2：基本要靠非常手段（压缩范围、更换低价方案、申请追加预算）。
• TCPI > 1.2：从概率上讲已经不可能在原预算内完工，别再自我安慰，直接谈追加预算或缩减范围。

3.3 另一个例子：SPI 看着漂亮，TCPI 已经在报警

再看一个更典型的项目。某项目 BAC = 1000 万元，计划 24 周，第 12 周检查：PV = 600 万，EV = 690 万，AC = 780 万。

• SV = 690 − 600 =+90 万元，进度提前。
• CV = 690 − 780 =−90 万元，成本超支。
• SPI = 690 ÷ 600 =1.15，进度效率是计划的 115%。
• CPI = 690 ÷ 780 =0.885，成本效率只有预算的 88.5%。
• 典型偏差法 EAC = 1000 ÷ 0.885 =1130 万元，预计超支 130 万。
• TCPI（基于 BAC）= (1000 − 690) ÷ (1000 − 780) = 310 ÷ 220 =1.41。

1.41 这个数字意味着什么？意味着剩下的每一块钱必须干出 1.41 元的活，而团队此前的能力是 0.885。这不是"加把劲"能解决的量级，这是必须坐下来重新谈范围的量级。

这个例子我在分享会上讲过好几次，每次讲完都有人问："那 SPI 高到底是不是好事？"我的回答是：SPI 高只是说明干得快，快不等于好，快也可能是烧钱烧出来的。四个指标必须一起看，尤其要看 CPI 和 TCPI 有没有背离。

还有一个必须知道的规律：CPI 越到项目末期越"好看"，这是假象。因为随着项目推进，AC 这个分母越来越大，后期新增的偏差对 CPI 的影响越来越小，指标会自然地向 1 收敛。所以千万不要看到项目最后两个月 CPI 从 0.88 涨到 0.95 就以为管理水平提升了，那只是数学规律。真正的判断要看趋势图上的斜率，而不是末期绝对值。

4. 搬到系统集成项目现场：测量基准和采集节奏怎么定

理论部分到这里就完整了，接下来是最难的部分——把公式套到真实的系统集成项目上。这类项目的典型特征是：硬件采购占比大、软硬件交叉、现场施工和软件开发并行、变更频繁、多方参与。每一条都在给挣值管理添麻烦。

4.1 控制账户的划分粒度，决定了这套体系能不能跑起来

挣值的最小核算单元是控制账户，它必须同时满足三个条件：有唯一责任人、有独立预算、有可验证的产出。系统集成项目我通常会切出这样几个控制账户：

• 总体设计与方案确认：产出物是设计方案、图纸、技术协议，通常占总预算 3%~5%。
• 硬件设备采购：产出物是设备到货并验收合格，通常占 40%~55%，是成本的大头。
• 机房及弱电施工：产出物是机柜上架、走线、端接、点位测试合格，通常占 10%~15%。
• 软件开发与配置：产出物是功能点通过测试，通常占 15%~25%。
• 系统联调与试运行：产出物是联调用例通过、连续稳定运行 N 天。
• 培训与验收交付：产出物是培训记录、竣工文档、验收报告。

划分的时候有两个坑我踩过。

第一个坑是切太细。有次我把机房施工切成 30 多个控制账户，每个只有几万块，结果每周收集数据的时间比干活还长，两个月后团队集体抵制。后来我总结的经验是：单个控制账户的预算不要低于总预算的 2%，周期不要短于两周，低于这个量级就合并到上级账户里，用里程碑法统一计量。

第二个坑是切太粗。把"软件开发"整个当一个控制账户，几百万的预算挂在一个账户上，中间十周 EV 完全不动，SPI 一直是 0，管理层看着心慌。正确做法是拆成 3 到 5 个可独立验收的模块，每个模块有自己的测试通过标准。

4.2 硬件、软件、施工、联调，四类工作要四套计量方法

这是我在实战中体会最深的一点：不要试图用一套 EV 计量规则套所有类型的工作。系统集成项目的四类工作性质差异太大，必须分类处理。

重点说硬件采购这一块，因为它占预算最大、也最容易失真。很多人图省事，设备一发货就报 100% 完成，结果设备在运输途中损坏返厂，EV 已经计进去了，退不回来。我的规矩是以"到货并验收合格"为计量点，运输途中一律不计。对于金额特别大的单笔采购（比如核心交换机、存储阵列），可以拆成"到货签收 70% + 加电测试合格 30%"两段，避免长期零 EV。

软件开发的计量是最需要下功夫的。我在一个项目上推过一个规则，效果不错：每个功能点必须同时满足"代码提交并通过评审"和"对应测试用例通过"两个条件才计入 EV，只写不完测的一律不计。这个规则刚推下去的时候，开发组的 EV 普遍下降了两三成，SPI 全线飘红，项目经理压力很大。但三个月后大家发现，这个口径下的 SPI 是可信的，报上去的数字和最终验收时的实际进度几乎吻合，反而省掉了后期大量的返工和扯皮。

4.3 数据采集：周采集、月对账，三方数据必须能对上

挣值管理的失败，八成败在数据采集上。我的做法是建立一套"周采集、月对账"的节奏，并且强制要求三方数据能对上：

• 进度数据来自各控制账户责任人的周报，格式固定，只允许填客观计量值（数量、用例数、验收单号），不允许填"完成百分比"。
• 工时数据来自工时系统，按人天 × 标准费率折算成人力成本。
• 财务数据来自项目辅助核算账，按权责发生制归集。

每月月结时，这三份数据要做一次交叉核对。核对的不是数字是否相等（它们本来就不该相等），而是差异能否解释。比如本月 AC 比上月增加 80 万，其中 60 万是硬件到货，那 EV 上应该能看到对应的采购账户从 0 跳到 100%；如果 AC 涨了而 EV 没动，要么是设备没验收，要么是计量规则执行出了问题，必须查清。

提示：变更对基线的影响必须当天处理。范围变更一旦批准，BAC、PV 曲线、控制账户预算三样东西要同步更新。我在项目上见过最典型的失控案例，是三个变更都已经实施完了，BAC 还是最初那个数，导致 EV 虚高、SPI 虚高，等到验收时才发现预算根本不够。变更不重定基线，挣值管理就是自欺欺人。

5. 一个 SPI = 1.15 却差点亏钱的项目，我是怎么一层层查出问题的

前面讲的都是方法和规则，这一节讲一个真实的排查过程。我把当时的排查链路完整写出来，因为这个过程比任何结论都有参考价值——挣值管理真正的作用不是给出答案，而是给出该往哪里查的线索。

5.1 异常信号：两个指数背离，且背离在扩大

项目背景：某公司的信息系统集成项目，BAC = 1000 万元，工期 24 周，我在第 12 周接手做绩效复盘。当时周报上的数字是 SPI = 1.15、CPI = 0.885，管理层普遍认为"进度不错，成本略超，可控"。我看了三周的滚动数据后发现，这不是"略超"，因为 CPI 连续三周在 0.88 附近横盘，而 SPI 从 1.05 涨到了 1.15。两个指数反向扩大，是典型的"用钱买进度"信号。

我列了一个排查清单，按这个顺序往下走：先看是不是真实的效率提升，再看 EV 有没有虚高，再看 AC 有没有漏记，最后看关键路径。

5.2 第一层：拆到控制账户，发现 SPI 高在了错的地方

把整体的 SPI = 1.15 拆到控制账户，问题立刻显形：

整体 SPI 之所以好看，全靠软件开发那一个账户撑着，而它偏偏只有一部分在关键路径上。真正卡住交付的两个账户——机房施工 SPI = 0.85、系统联调 SPI = 0.60——全在关键路径上。也就是说，项目实际上是在关键路径落后、非关键路径抢跑的状态，这种结构下的 SPI = 1.15 完全是个幻觉。

这一层排查给我的教训是：挣值指标天生是"路径盲"的。它只知道干出了多少价值，不知道这些价值是不是落在关键路径上。所以挣值必须和关键路径分析配合使用，只看 SPI 判断进度，等同于开车只看油表不看路。

5.3 第二层：查 EV 的计量口径，发现"完成"的标准被偷换了

软件开发账户 SPI = 1.42，这个数字太漂亮了，漂亮到必须怀疑。我把这个账户下五个模块的报量记录调出来，逐个核对，发现了三处问题：

第一处，有两个模块报的是"功能开发完成 90%"，而这个项目两个月前刚推行过"测试通过才计入 EV"的规则。我追问原因，开发组长的解释是"测试环境还没搭好，先按开发进度报一下"。这就是典型的规则被绕过。

第二处，有一个模块把"接口文档写完"也算作完成度的一部分，而接口文档在这个控制账户的预算分解里根本没占权重，等于凭空多算了 8 万 EV。

第三处，有两个低优先级模块提前开工并报量，但它们不在关键路径上，也不在本期交付范围内，属于"干了不该现在干的活"。这在挣值体系里是最隐蔽的一种失真——EV 是真的，活是真干完了，只是干的不是当下最该干的活，从项目整体看，这是资源错配。

三处加起来，虚高的 EV 大约 62 万元。把 62 万从 EV 里扣掉，重算：EV = 690 − 62 = 628 万，SPI = 628 ÷ 600 = 1.05，CPI = 628 ÷ 780 =0.805。真相开始浮出来了。

5.4 第三层：查 AC 的完整性，发现承诺成本没进台账

CPI 从 0.885 掉到 0.805 之后，我又回头查了 AC 这一侧，看看是不是还有漏记。翻采购台账的时候发现，有三笔已经签了合同、设备已下单但未到货的采购，合计约 95 万元，完全没有体现在 AC 里。

按权责发生制的严格定义，这三笔是承诺成本，尚未发生实际支出，不计入 AC 是可以接受的。但问题在于，对应的 EV 也还没计（硬件采购用的是 0/100 法，到货验收才计），所以短期看两边都不动，指标不受影响。可一旦设备到货，AC 会在某一周突然增加 95 万，而对应的 EV 也要到验收时才计，那一周的 CPI 会出现一次剧烈波动。

这个发现的意义不在当期指标，而在于它解释了为什么这个项目的 CPI 会呈现"阶梯式下坠"：每个月硬件到货那一周，AC 突增而 EV 滞后，CPI 就被砸下去一次，然后又缓慢回升。如果不了解这个机制，很容易把正常的计量时滞当成管理问题去处理。

5.5 第四层：查变更，发现三项已实施未走流程

最后一层查的是变更。这一查不要紧，发现有三项范围变更都已经实施完毕，涉及金额约 55 万元，但变更申请还在走流程，BAC 依然是 1000 万。

这意味着所有基于 BAC 的预测都偏乐观。把变更批下来之后，BAC 应该调整为 1055 万元。重新算一遍全套指标：

• 修正后 EV = 628 万，AC = 780 万，PV = 600 万。
• SV = +28 万，CV = −152 万。
• SPI = 1.05，CPI = 0.805。
• 典型偏差法 EAC = BAC ÷ CPI = 1055 ÷ 0.805 =1310.6 万元，预计超支 255 万。
• TCPI（基于 BAC）= (1055 − 628) ÷ (1055 − 780) = 427 ÷ 275 =1.55。

1.55 这个数字出来的时候，会议室安静了。这不是"略超，可控"，这是需要在两周内做出结构性决策的量级。

5.6 修正之后做了什么

后续的处置动作分四条线同时推，我按重要性排了序：

第一条，把关键路径的资源拉回来。系统联调 SPI = 0.60 是最大的风险源，从非关键路径的软件开发组抽调 4 名骨干支援联调，同时把两个低优先级模块的开工时间往后推了三周。这个动作短期会让软件开发的 SPI 掉下来，但项目整体的关键路径被救回来了。

第二条，把 EV 的计量规则重新钉死。出台了三条硬规矩：只认测试通过的功能点；只认已分配预算的工作（不在预算分解里的工作一律不计 EV）；非关键路径的提前完成不计入当期 EV，单独在报告里注明。第三条当时争议最大，但我坚持下来了，因为它防的正是"抢跑了不该跑的路"。

第三条，变更当天补签。三项已实施未走流程的变更在两周内完成审批，BAC 调整为 1055 万，PV 曲线同步重新基线化。这件事之后，我在项目上立了一条规矩：任何变更在实施前一天必须完成预算调整，否则不予实施。

第四条，重新谈范围。拿着 TCPI = 1.55 这个数字，我陪项目经理去和客户做了一轮范围梳理，把三个可以放到二期的功能挪出去，砍掉约 70 万预算。同时申请追加了部分预算。最终项目以略超预算 4% 的结果收尾，相比最初预测的 25% 超支，算是救回来了。

整个排查过程用了一周多，但我最大的体会不是"挣值管理很有用"，而是——挣值管理的价值 80% 在于它的过程强制性：它逼着你去核对每一个数字的来源，而这个核对过程本身就能发现大量问题。如果这个项目没有这套体系，那 62 万虚高的 EV、95 万未入账的承诺成本、55 万未走流程的变更，可能要等到验收结算那天才被发现，那时候什么都晚了。

6. 考试里的挣值题：几个反复出现的口径陷阱

写这一节，是因为我身边有不少人栽在计算题上，而且栽的方式出奇地一致——不是不会算，是算错了口径。公式本身没什么难度，难的是题干里那些没说透的假设。

6.1 别背公式，用一句话推出来

我在带人的时候从不让人背那七个公式，只让记住一句话：PV 是"该挣的"，EV 是"挣到的"，AC 是"花掉的"。

• 进度偏差 SV：挣到的 − 该挣的 = EV − PV。
• 成本偏差 CV：挣到的 − 花掉的 = EV − AC。
• 进度指数 SPI：挣到的 ÷ 该挣的 = EV ÷ PV。
• 成本指数 CPI：挣到的 ÷ 花掉的 = EV ÷ AC。

预测类指标也能顺推出来。EAC 的问法是"按现在这个花钱效率，全部干完要花多少"，那自然就是总预算 ÷ 花钱效率 = BAC ÷ CPI。ETC 是"还差多少"，自然就是 EAC − AC。VAC 是"最后会差多少"，自然就是 BAC − EAC。TCPI 是"剩下的钱要多能打才够用"，那自然是"剩下的活 ÷ 剩下的钱"。

凡是能自己推出来的公式，考场上就不存在"想不起来"这回事。

6.2 六个高频陷阱，逐条对照检查

还有一个特别典型的坑：问"按当前进度，项目还需要多少时间"。这类题的标准做法是"计划总工期 ÷ SPI"，但要清楚这是一个非常粗糙的线性外推假设，它假定剩余工作和已完成工作的效率一致。考试里这么算没问题，实际项目里这么算会出大错，因为进度不是线性的，最后阶段的联调、验收往往比前面任何阶段都更耗时间。

6.3 我在做题时会走的五步流程

拿到任何一道挣值题，不管题干多长，我会在草稿纸上固定走这五步，熟练之后基本不会漏条件：

第一步，画一张四格表。表头写 BAC、PV、EV、AC，然后把题干里所有数字往里填。填不进去的空格，先放着，通常后面能推出来。这一步能解决 80% 的"信息遗漏"问题。

第二步，把单位统一。万元、元、人天、周，全部换算成同一个单位，写在表的上方。这一步看着琐碎，但每年都有人栽在这里。

第三步，算四个基础指标。SV、CV、SPI、CPI，一步一步写，别跳步。写出来之后用直觉校验一下：SPI = 0.7 和 CPI = 1.3 同时出现，就该想一想是不是算错了。

第四步，判偏差性质。看题干里有没有"持续""已经采取纠正措施"这类描述，据此决定用哪个 EAC 公式。

第五步，算预测指标。EAC、ETC、VAC、TCPI，按顺序算。如果题目只要其中一个，其余的也可以顺手写在草稿上，很多题目后面的小问会用到。

还有一个很实用的检查技巧：算完之后看 EAC 和 BAC 的关系。如果 CPI < 1 而算出来的 EAC 小于 BAC，那一定是哪里搞反了；如果 SPI > 1 却算出"进度落后"，同理。这种自洽性检查能拦下大部分低级错误。

6.4 别把考试逻辑当成项目逻辑

最后说一个我反复提醒身边人的点：考试里的挣值题有一个隐含假设，就是数据是干净、准确、口径统一的。而真实项目里，最花时间的恰恰是把这三个数弄干净。所以两者要分开准备：

• 应付考试，重点是公式推导、单位换算、公式选择、结果自洽。
• 应付项目，重点是控制账户划分、EV 计量规则、AC 数据源、变更基线管理、以及跟关键路径的联动分析。

把考试那套直接搬到项目上，最常见的表现是：每周认认真真算出 SPI 和 CPI，画一张漂亮的趋势图，然后没人看，也没人拿它做决策。因为底层数据不可信，图再漂亮也是装饰。

我个人在实际操作中的体会是：挣值管理不值钱的部分是计算，值钱的部分是它逼着你每周去核对一次"计划该干到什么程度、实际干出了什么、为这个花了多少钱"这三件事。我在几个项目上坚持过每周只花二十分钟对这三个数，效果比做一整套复杂的绩效报告要好得多。真要给一个落地建议，那就是从最小的动作开始——先别急着算 EAC 和 TCPI，先把 PV、EV、AC 三个数每周对上一次，对到你能毫不犹豫地说出它们的来源为止。等这三个数干净了，后面那一整套预测体系自然就转起来了。