干过集成项目的人都有一个共同的痛：老板或甲方问“这个项目现在到底怎么样”，你要是只回答“还在推进”“进度正常”，对方心里大概率是不信的，你也知道自己是在含糊。真正能把话说清楚的状态应该是什么样的？是你能直接甩出一句话——“按计划这个月该干完 50 万的活，实际干完了 40 万，花了 48 万，进度落后两成，成本超了八个点，照这个势头走完全程要 120 万，超预算 20 万”。这句话背后的那套算法，就是挣值管理。PV、EV、AC、SV、CV、SPI、CPI 这七个字母，是系统集成项目管理工程师这类资格认证里的必考内容，也是实际项目里最能救命的一套度量工具。它的价值不在于考试拿分，而在于把“进度”和“成本”这两件平时各说各话的事情，塞进同一个坐标系里做比较。这篇内容适合三类人看：正在准备这类资格认证、被公式绕晕的同行；刚接手集成项目、想知道怎么向管理层汇报的 PM；以及做了几年项目、一直在用感觉判断进度、想换一套硬指标的技术负责人。下面我不打算按教材顺序念公式，而是按我自己在项目里用它的顺序，把这套东西拆开讲清楚。

1. 挣值管理到底解决什么问题——先把思路拆开

1.1 传统“看两张报表”为什么会失灵

绝大多数团队汇报项目状态时，手里其实有两张互不相干的表。一张是进度表，写着“需求调研完成 100%，开发完成 60%，联调未开始”；另一张是财务表，写着“累计支出 48 万，预算 100 万，剩余 52 万”。这两张表单独看都没毛病，问题出在它们没法互相验证。开发完成 60% 是按什么口径算的？是代码行数、功能点数，还是负责人拍脑袋估的？累计支出 48 万对应的到底是哪些活干完了？没人说得清。

于是就会出现一种特别典型的场面：财务说钱还剩一半多，别慌；技术负责人说活才干了一小半，得加人。两边都没撒谎，但拼在一起就是矛盾的。更麻烦的是，这种矛盾往往要到项目后期才爆出来——等你发现钱花完了活还没干完，能做的只剩下砍范围或者申请追加预算，主动权已经完全丢了。

挣值管理干的第一件事，就是把这两张表强行焊在一起。它要求你把所有的“活”都折算成钱，形成一个统一的度量单位。干完了多少活，就等于“挣”到了多少钱。这个转换看起来只是个换算，实际上是整个方法的地基。

1.2 三个基准量：PV、EV、AC 各自站在什么位置

理解挣值管理，先要理解三个量分别代表三种完全不同的视角，很多人算错就是因为把它们混成一锅。

PV（Planned Value，计划值）站在“计划”的视角。它回答的问题是：截至今天这个检查点，按原定基线，我们本来应该完成多少价值的工作？注意关键词是“截至今天”，PV 是一个累计量，不是本月量。项目总预算叫 BAC（完工预算），如果工期 10 个月、预算平均分布，那第 5 个月末的 PV 就是 50% 的 BAC。

EV（Earned Value，挣值）站在“实际完成”的视角。它回答：截至今天，我们真正完成了多少价值的工作？这个“价值”不是市场售价，而是这些工作在原预算里值多少钱。换句话说，EV 是把“完工百分比”乘上对应工作的预算得来的。它是整套方法里最主观、最容易注水的一个数，后面我会专门讲怎么防注水。

AC（Actual Cost，实际成本）站在“花钱”的视角。它回答：截至今天，为了完成这些工作，我们实际花掉了多少钱？注意 AC 只统计已经发生的支出，不统计承诺但未支付的。

三个量摆在一起，就有了两两比较的可能：EV 和 PV 比，看的是进度；EV 和 AC 比，看的是成本。这里有个容易被忽略的细节——两次比较的基准都是 EV。为什么不是 PV 和 AC 直接比？因为 PV 和 AC 之间没有任何业务含义，一个说“该干多少”，一个说“花了多少”，比出来的数字解释不了任何事情。只有 EV 这个“实际干成的量”同时出现在两个式子里，比较才有意义。

1.3 为什么非要用“钱”做统一度量单位

这是新人最常问的问题：为什么不能直接用“完成的功能点数量”或者“代码行数”来衡量进度？非要用钱这么俗的东西？

原因很实际。一个集成项目里，工作内容的异质性太强了。机房改造花了 20 万，需求调研花了 5 万，两者的工作性质、耗时、人力投入完全不可比。你说“机房改造完成了 60%，需求调研完成了 100%”，这两个百分比没法相加，也没法判断整体到了哪一步。但如果把它们都折算成预算金额，机房改造的 60% 就是 12 万，需求调研的 100% 就是 5 万，加起来 17 万，这就成了一个可以比较、可以累加、可以和总预算 100 万对照的数字。

钱是这个项目里唯一的“通用语言”。它把不同专业、不同工种、不同阶段的活，翻译成了同一个维度上的刻度。这就是为什么挣值管理一定要基于成本基线来算，而不是基于工作量。理解了这一层，后面所有公式其实都是自然推论。

注意：用钱做统一度量单位有个前提——预算分解必须细到可以对应到具体可交付成果。如果预算只是一坨总数，EV 根本算不出来。这也是为什么 WBS 分解质量直接决定挣值管理能不能用。

2. 七个核心指标逐个拆解与计算口径

2.1 PV：看着最简单，其实最容易埋雷

PV 的计算公式本身没什么可说的：PV = 计划完工比例 × 该部分工作的预算。真正的问题在于“计划”这两个字。

很多项目的进度计划是用甘特图画出来的，横道图上标着每个任务的起止日期，但从来没有把预算金额分配到时间轴上。这种情况下你根本算不出某个检查点的 PV，因为计划里只有“什么时候做什么”，没有“什么时候该值多少钱”。

正确做法是做成本基线：把每个 WBS 工作包的预算，按计划工期分摊到每个月。分摊方式可以是平均分摊，也可以按计划投入的人力和资源曲线分摊。分摊完之后，每个月的 PV 就是这个月所有工作包应完成金额之和，累计起来就是截至该月的 PV。

这里有个实操细节值得说：PV 一旦基线确定，就不应该随便改。除非发生了正式的范围变更并且走了变更流程重新审批基线，否则即使项目实际延期了，PV 也还是按原来的计划算。很多人一延期就把计划往后推，PV 跟着改，结果 SPI 永远等于 1，指标彻底失效——这是自己骗自己。

2.2 EV：整套方法的命门，也是最容易注水的地方

EV = 完工百分比 × 该工作的预算（BAC 部分）。公式一行就写完了，但它决定了整套方法的可信度。

问题出在“完工百分比”怎么定。我见过太多团队在这里做手脚：开发任务计划 20 天，干了 15 天，负责人报“完成了 75%”。这个 75% 是怎么来的？按时间投入估的。这就完全跑偏了——投入了 75% 的时间，不代表产出了 75% 的价值。可能在最后 25% 的调试上还要再花一倍时间。

更靠谱的做法是把任务拆到足够小，然后用明确的度量规则。行业里常见的几种：

我个人的偏好是：能拆细就拆细，拆到两周以内，然后用 0/100 法。虽然完工前 EV 是 0 会让中期报表难看，但它的好处是绝对不会骗人。实在拆不开的长任务，就用里程碑法，把任务切成几个有实物交付的节点，每个节点对应一个预算比例，比如需求确认 20%、设计评审 30%、编码完成 30%、测试通过 20%，节点没过就不给钱。

实操心得：报 EV 的时候必须附带证据。代码任务看提交记录和评审记录，硬件任务看到货单和验收单，文档任务看评审签字。没有证据的百分比，一律按 0 处理。这条规矩一开始会得罪人，但坚持两个月之后，报量数据会干净得让你惊讶。

2.3 AC：口径不统一，全盘皆输

AC 看起来是三个量里最客观的——花了多少钱，账上有数。但实际上，集成项目的 AC 是最容易出岔子的。

第一个坑是内部人力成本算不算。很多公司只把对外支付的采购款、外包费计入 AC，自己员工的人力成本不进项目账。这样做出来的 CPI 会严重失真：项目用了大量内部人力，这些成本没进 AC，CPI 看起来永远是大于 1 的“优秀”。如果公司实行内部人力结算（按人天单价内部计价），那就必须把这块计入 AC，否则指标没有任何意义。

第二个坑是时间切面不一致。AC 必须和 EV 在同一个时间点截取。比如每月 25 日盘点，那 EV 报的是截至 25 日的完工量，AC 也必须是截至 25 日的支出。但实际情况是，分包商的发票往往滞后一个月才到，采购款可能预付了 30%，这些时间差都会让 AC 失真。处理办法是计提：发票没到但服务已经发生的，按合同金额估算入账，让 AC 尽量贴近“已发生的成本”而不是“已付款的金额”。

第三个坑是口径混用。预算里含不含税？含不含差旅？人力单价用的是成本价还是对外报价？这些必须在项目启动时写进核算规则里，全项目统一执行。我见过一个项目，PV 用的是不含税预算，AC 用的是含税实付，结果 CPI 莫名其妙地一直低于 1，查了半个月才发现是税的问题。

2.4 SV 与 CV：两个绝对偏差，差值的业务含义比数字本身重要

有了三个基准量，两个偏差就很好算了：

• SV（进度偏差）= EV − PV
• CV（成本偏差）= EV − AC

SV 大于 0 表示进度提前，小于 0 表示落后；CV 大于 0 表示成本节约，小于 0 表示超支。注意这两个式子里，被减数都是 EV，减数分别是 PV 和 AC。这个顺序千万别记反，考试里挂在这上面的不在少数。

但实际工作中，光看正负号远远不够。偏差的大小要和项目规模对照着看。一个 1000 万的项目，SV = −10 万，看起来是个大数字，实际上只落后了 1%，可能只是统计口径误差。而一个 100 万的项目，SV = −10 万就是落后 10%，需要立刻干预。所以偏差值更适合用来做趋势跟踪：这周的 SV 是 −5 万，上周是 −3 万，上上周是 −1 万——恶化速度比绝对值更值得警惕。

还有一个常被忽略的点：SV 是负的，不代表所有工作包都落后。汇总层的 SV 会把各种情况平均掉。有的包超前进度，有的包严重落后，加总起来可能只是轻微负值，看起来很安全，实际上风险最大的那个包已经在悬崖边上了。所以 SV 和 CV 一定要拆到 WBS 工作包层级去看，汇总数字只能用来向上汇报，不能用来做决策。

2.5 SPI 与 CPI：为什么指数比差值更好用

• SPI（进度绩效指数）= EV ÷ PV
• CPI（成本绩效指数）= EV ÷ AC

这两个指数的好处是归一化。SV = −10 万，你得知道项目总预算是多少才能判断严重程度；而 SPI = 0.8，直接告诉你“只干了计划的八成”，跟项目规模无关，横向比较也很方便——A 项目 SPI 0.95，B 项目 SPI 0.7，谁的进度风险大一眼就看出来。

判断标准很简单：大于 1 是好事，等于 1 是符合计划，小于 1 是出问题。但这里有几个陷阱必须提醒。

第一个陷阱：SPI 和 CPI 在项目极早期不稳定。项目开工第一个月，PV 可能只有总预算的 5%，EV 稍微有点统计误差，SPI 就能从 0.6 跳到 1.2。这时候拿它去做判断，纯属自己吓自己。我的建议是：项目前 20% 的工期里，指数只做参考，主要看趋势；进入中期（20%~80%）后，指数才具备预测价值。

第二个陷阱：项目末期指数会自然回归 1。因为 EV 越来越接近 BAC，而 PV 在项目结束时也等于 BAC，所以 SPI 必然趋近 1；同时如果成本已经花得差不多，CPI 也会趋近 1。有些团队到了项目末期看到指数“好转”，就以为管理见效了，其实是数学规律。真正该关心的是项目中期指数最低的那个点，那才是真实水平。

第三个陷阱：指数不能简单平均。多个项目或者多个工作包的 SPI，不能取算术平均。假设一个包 SPI = 2（严重超前），另一个包 SPI = 0.5（严重落后），算术平均是 1.25，看起来一片大好，实际上汇总后的 EV/PV 可能远小于 1。正确做法是先把 EV、PV 分别加总，再相除。

2.6 一张表把七个指标串起来

为了不让公式散落在脑子里，我习惯用下面这张表做速查：

记住一个口诀：EV 永远是分子或被减数。七个指标里有六个都用到了 EV，它是整套体系的轴心。至于 AC 只出现在成本相关的三个式子里，PV 只出现在进度相关的三个式子里，记住这个归类就不会乱。

3. 从七个指标延伸到预测：EAC、ETC、VAC、TCPI

3.1 为什么光看偏差不够，必须做预测

SV = −10 万，这个信息告诉你的只是“现在已经落后了”。但老板真正想知道的不是这个，而是“照这样下去，最后会怎么样？还来不来得及？要花多少钱？”

挣值管理真正值钱的地方，就是从已发生的偏差推导完工预测。这部分在教材里往往被压缩成几个公式，实际用起来才是核心。

3.2 BAC 与 EAC：两个“总预算”的区别

BAC（完工预算）是项目启动时批准的原始总预算，是 PV 曲线的终点，也是固定不动的基准。

EAC（完工估算）是“按目前情况推测，项目最终要花多少钱”。它是一个动态量，每次盘点都该重算一次。

EAC 的算法不止一种，选哪种取决于你对“当前偏差会不会持续”的判断，这个判断是整个预测环节的关键：

第一种：假设剩余工作将按原预算效率完成（非典型偏差）

EAC = AC + (BAC − EV)

这个算法的含义是：已经花掉的钱就是花掉了，但剩下的活还能按原计划效率干完。适用的场景是——当前的偏差是一次性的、已经纠正的、不会再发生的。比如某批次设备因为临时调货多花了钱，后续不会再出现，这种情况用这个算法合理。

第二种：假设剩余工作将按当前效率继续（典型偏差）

EAC = BAC ÷ CPI

这个算法的含义是：你现在的成本效率水平会一直保持下去。这是最常用、也最保守的一种算法。为什么？因为项目的成本效率通常有惯性——如果团队效率、供应商价格、管理方式没变，那效率大概率也不会突然变好。管理层最喜欢用第一种算法自我安慰，但从业者心里要清楚，没有实质改进动作的情况下，第二种更接近现实。

第三种：进度和成本同时影响

EAC = AC + (BAC − EV) ÷ (CPI × SPI)

这个算法考虑到一个现实：进度落后往往会推高成本（加班、赶工、资源价格上浮），两者是联动的。当项目既超支又延期时，这个算法给出的数字最悲观，通常也最接近真相。

第四种：自下而上重新估算

把剩余工作重新拆一遍，让每个负责人报 ETC，然后 EAC = AC + ETC。这个最准，但最费时。一般用在项目已经严重偏离、前三种算法都不太可信的时候。

实操心得：汇报的时候不要只给一个 EAC 数字，要给三种算法的结果和你的判断。比如“最乐观 108 万，按当前效率 120 万，考虑进度成本联动 138 万，我倾向按 120 万报风险敞口”。给出区间和倾向性判断，比给一个精确的假数字更有说服力。

3.3 ETC 与 VAC：剩余工作与最终差额

ETC（完工尚需估算）= EAC − AC，意思是“从现在到结束，还需要再花多少钱”。这个数对现金流管理特别关键——很多项目 EAC 算得很漂亮，但没算 ETC，结果中途现金流断了。

VAC（完工偏差）= BAC − EAC，意思是“最终会超支还是节约”。VAC 为正说明有结余，为负说明会超支。这个数直接决定了你要不要提前申请预算调整。我一般会在项目中期就把 VAC 报给财务，让他们心里有数，而不是等到超支发生了才去解释。

3.4 TCPI：给团队一个现实的“体检报告”

TCPI（完工尚需绩效指数）是我个人觉得最有价值、但教材讲得最少的一个指标。

基于 BAC 的算法：TCPI = (BAC − EV) ÷ (BAC − AC)

它的含义是：在剩余预算内完成剩余工作，未来的成本效率必须达到多少。

举个例子：BAC = 100 万，EV = 40 万，AC = 48 万。现在剩余工作价值 60 万，剩余预算只有 52 万，TCPI = 60 ÷ 52 ≈ 1.15。意思是：接下来每一块钱的支出，必须干出 1.15 块钱的活，才能不超总预算。而现在实际的 CPI 只有 0.83。

一个 0.83 的效率，要突然跳到 1.15，中间差了将近 40%。这个差距意味着什么？意味着如果不做实质改变（缩范围、换供应商、优化方案），按原预算完工基本不可能。TCPI 就是用来戳破幻想的那个指标。

判断标准：TCPI 大于 1 且明显高于当前 CPI，说明按原预算完工已不现实，必须启动变更或缩范围；TCPI 小于等于 1，说明还有机会，但需要维持甚至提升效率。

如果已经决定追加预算到 EAC，那就用基于 EAC 的算法：TCPI = (BAC − EV) ÷ (EAC − AC)，用来判断追加后的预算是否现实。

4. 完整算例：一个集成项目走到第五个月

4.1 场景设定与 WBS 分解

光讲公式没感觉，走一遍完整数据。假设一个系统集成项目，总预算 BAC = 100 万，计划工期 10 个月。WBS 拆成五个工作包，预算分配如下：

现在是第 5 个月末，做一次挣值盘点。

4.2 逐项计算与汇总

各工作包的数据（单位：万元）：

几个数字的来源说明一下。1.2 机房改造计划第 3 个月完工，到第 5 个月末 PV 应该是全额 24 万？不对——这里要看基线怎么排的。如果第 3 个月就该完工，那到 5 月末 PV 应当是 24。但上表写的是 10，说明这个包的基线在变更后被调整过，或者原本就计划分批交付。为了演示清晰，这里假设 1.2 的实际基线是在第 1~5 月分摊 20 万，另外 4 万留给后续扩容，所以 5 月末 PV = 10 万。这类“预算分配到时间轴”的细节必须在基线里写清楚，否则 PV 会算得五花八门。

汇总层的结果：PV = 50，EV = 40，AC = 48，于是 SV = −10，CV = −8，SPI = 0.80，CPI ≈ 0.833。

4.3 结果解读：拆开看才知道问题在哪

如果只看汇总，结论是“进度落后 20%，成本超支 8 万”，然后呢？没法下手。拆到工作包层级，故事就清楚了。

硬件采购：SV = 0，进度完全达标；CV = −3，超支 3 万。这个超支大概率是价格因素（汇率、临时调货、加急运费），属于一次性偏差，后续不会持续。处理方式是和采购确认超支原因，如果是市场因素，走变更流程调整这个包的预算，别让它一直拖着整个项目的 CPI。

机房改造：SPI = 0.60，是全项目进度最差的包之一。这个包通常是外包给施工方的，进度落后八成是施工方人力不足或者现场条件不具备。CV = −1 说明还小有超支，属于“又慢又费钱”，必须立刻约谈施工方，看是加人还是调整工序。

应用开发：SPI = 0.50，CPI = 0.62，这是全项目最危险的地方。开发进度只到计划的一半，成本却已经花了计划的八成。这个组合说明什么？说明投入的人力不少，但产出效率极低——可能是需求反复变更、技术方案卡壳、或者团队能力不匹配。这里必须做根因分析，光加人没用，加了人只会让 CPI 更难看。

集成联调：PV = 2，EV = 0，AC = 1.5。活还没开始干，钱先花了 1.5 万。这通常是测试环境搭建、联调准备的前置投入。本身不算异常，但要盯住——如果第 7 个月联调正式开始时，这 1.5 万没有被合理归集，EV 会算不准。

有了这个拆解，行动清单就出来了：硬件走变更调预算，机房约谈施工方，开发做根因分析并考虑缩范围或换方案，联调盯紧前置投入的归集。这比“进度落后、成本超支”这种汇报有用一百倍。

4.4 预测：走到终点会是什么样

按三种算法算 EAC：

• 非典型偏差：EAC = 48 + (100 − 40) = 108 万
• 典型偏差：EAC = 100 ÷ 0.833 ≈ 120 万
• 进度成本联动：EAC = 48 + 60 ÷ (0.833 × 0.80) = 48 + 90 = 138 万

ETC（按典型偏差）= 120 − 48 = 72 万，也就是剩下 5 个月还要再花 72 万，平均每月 14.4 万，而前 5 个月平均每月只花了 9.6 万。这个现金流缺口必须提前跟财务打招呼。

VAC = 100 − 120 = −20 万，超支 20 万。

TCPI = (100 − 40) ÷ (100 − 48) = 60 ÷ 52 ≈ 1.154。当前 CPI 是 0.833，要跳到 1.154，提升幅度 38%。这个数字摆出来，任何有经验的 PM 都会承认：按原预算完工不现实，必须动范围或者动预算。

5. 落地实施：怎么让这套东西在项目里真正跑起来

5.1 度量规则要先定，不能边干边议

挣值管理落地失败的头号原因，不是公式算错，而是度量规则没定清楚，导致每个人报的 EV 口径不一样。

项目启动会上就应该把这几件事定下来：每个 WBS 工作包用哪种度量方法（0/100、里程碑法还是百分比法）；百分比法需要什么证据支撑；谁有权确认完工比例；盘点周期是周还是月。这些规则一旦定下来，写进项目管理计划，全项目统一执行，中途不轻易改。

我见过一个项目，开发组按功能点报进度，测试组按用例执行率报进度，实施组按人天报进度，三套口径汇总出来的 EV，谁也解释不了。返工重定规则花了整整两周，等于白白损失了半个月的进度。

5.2 数据采集的节奏和责任人

挣值盘点是件体力活，必须固定节奏、固定责任人，否则很容易变成“想起来才算一次”。

我一般这样安排：每周五下午，各工作包负责人提交本周完工量和证据；每周一上午，项目经理汇总 EV，财务或项目助理同步 AC；每月末做一次完整盘点，出正式报告。周度盘点只算总量不做详细分析，月度盘点才拆到工作包层级做偏差分析。

AC 的采集要特别注意同步。财务的账期和项目的盘点周期往往对不上，解决办法是让项目助理维护一份“项目支出台账”，把已付款、已发生未付款、已承诺未发生三类分开记录，每周更新。月末盘点时，AC 取“已付款 + 已发生未付款”，已承诺未发生的单独列示作为风险提示。

注意：不要让一个人同时负责报 EV 和审 EV。自己报自己审，注水是必然的。至少要有一道交叉验证——技术负责人报量，项目经理审核，关键节点还要有第三方（质量或 PMO）抽查。

5.3 和变更控制的联动，这是最容易被忽略的一环

挣值管理有一套隐含假设：PV 的基线是稳定的。但集成项目的范围变更太频繁了，如果变更了却不更新基线，PV 就会失真。

举个典型场景：客户临时追加了一个子系统，工作量增加 15 万，团队加班干完了。这时候如果基线没更新，PV 还是原来的 100 万，EV 却因为多干了活变成了 115 万（假设全部完成），SPI 显示 1.15，一片大好。但实际上团队是被迫增加了工作量，成本也相应上升，AC 可能到了 125 万，CPI 是 0.92。真实的绩效是超支的，报表上却看不出问题。

正确做法是：每一次批准的范围变更，都要同步更新 BAC、PV 曲线和成本基线，并且留下版本记录。变更后的新基线要重新发布给所有干系人，让大家对着同一个版本算指标。没有这一步，挣值管理就是空中楼阁。

6. 常见问题与排查实录

6.1 EV 虚高的四种典型表现

EV 注水是这套方法最大的敌人，而且往往不是故意的，是认知偏差。我总结了几种高频表现：

第一种，把投入当产出。任务计划 20 天，干了 15 天，报 75%。这是最常见的错误，本质是把“花了多少时间”等同于“完成了多少价值”。识别方法很简单：看有没有可验证的中间交付物。没有交付物，一律不认。

第二种，把“快完成了”当成“完成了”。开发任务报 90%，然后这个 90% 保持了三周不动。这种情况说明最后 10% 的难度被严重低估，实际可能只完成了 70%。识别方法：跟踪 EV 的增长曲线，如果某个包的 EV 长期停滞在某个百分比，就要怀疑。

第三种，末位冲刺式补报。前几周 EV 几乎不动，最后一周突然从 30% 跳到 100%。如果交付物确实完整，那没问题；如果是为了赶盘点节点硬报的，就是注水。识别方法：抽查交付物的完成质量。

第四种，把准备工作算进完成度。环境搭好了、文档框架写好了，就报 30%。准备工作确实是工作，但它在总预算里的占比通常很小，不该占那么大权重。

6.2 常见问题速查表

6.3 几个踩过的坑，都是真金白银换的

坑一：指标好看就放松了现场管理。有个项目中期 SPI 一直维持在 1.05 左右，管理层很放心，结果第 8 个月联调阶段突然崩盘，原因是前面几个包都是按“代码写完”报的完成，实际联调时发现接口对不上，返工量巨大。教训是：EV 的度量必须包含“可集成”这个标准，写完不等于完成，通过联调才算。集成类项目的度量规则，一定要把集成验证纳入完工定义。

坑二：把 SPI 当成真实进度。SPI 是用成本口径算的进度，它衡量的是“值多少钱的活干完了”，不是“关键路径走到哪了”。一个项目可能 SPI = 1.1，但关键路径上的某个设备到货延迟了两周，整体交付照样延期。所以 SPI 必须和关键路径分析结合看，两者不一致时，以关键路径为准。

坑三：多个项目简单汇总。同时管三个项目，各自 SPI 是 0.9、1.2、0.7，取平均 0.93 汇报，这个数字没有任何意义。因为三个项目的预算规模不同，权重不同。正确做法是按预算加权，或者干脆分别汇报。汇总指标只在你需要向上给一个总数时用，做决策必须回到单个项目。

坑四：忘了挣值管理不衡量质量和范围。EV 报 100%，但交付物质量不合格，返工成本会全部落在后续阶段，这时候 EV 是完全失真的。所以在挣值盘点的同时，必须同步看质量指标（缺陷密度、一次通过率）和范围指标（变更数量、需求覆盖率）。三张表一起看，才能形成完整判断。

最后分享一个我在实际项目里养成的习惯：每次月度盘点，除了算指标，我都会单独写一段“这个月最让我不安的一个数字”。有时候是某个包的 CPI 掉到了 0.6，有时候是 TCPI 跳到了 1.3，有时候是 AC 里突然出现一笔说不清来源的支出。这段话不写进正式报告，只留给自己看，用来对抗“报表一片祥和”的自我麻痹。做了几年下来，真正出问题的项目，往往在指标还很漂亮的时候，就已经在那段话里露出苗头了。