你的项目周报里有没有这三个字：「感觉还行」

每次项目周会，技术负责人说"进度基本正常"，项目经理说"风险可控"，老板点点头散会。

但到了交付前两周，突然发现还有40%的功能没测完，预算已经超了15%。

问题出在哪？不是没人干活，不是没花时间，而是从始至终没人用数字回答过一个问题：这个项目到底健不健康？

挣值管理（Earned Value Management, EVM）就是干这个的。它不是什么高深理论，本质上就是引入一个中间变量——“挣值”——让你同时看清成本和进度的真实状态。

可惜大多数人学挣值管理止步于考证阶段：背完公式，考完试，回去继续凭感觉写周报。

本文不想再复述一遍教科书。我们从一个具体场景出发，看看 SPI、CPI、EAC 这些指标怎么在真实项目中用起来。

一个让所有人闭嘴的例子

假设你负责一个系统迁移项目：

现在是第5个月末，你该做检查了。实际情况：

• 完成了 8个模块
• 实际花了 52万元

传统做法怎么看？

“计划5个月花50万，实际花了52万，超支2万，问题不大。”

这是大多数项目经理的判断。但它是错的。

因为你只看了支出，没看产出。你花了52万，但你"挣"了多少？

引入挣值：一个改变一切的中间变量

三个基本参数：

关键就在 EV 这个概念。

你的团队完成了8个模块，每个模块预算5万，所以你"挣"了40万。但你实际花了52万，而计划上你应该"挣"50万。

有了这三个数字，后面的分析就是数学题了。

四个指标：从模糊到精确

成本偏差 CV = EV - AC

CV = 40 - 52 = -12万

负值意味着超支。不是超2万，是超12万。

之前那个"超2万"的判断是怎么来的？是用AC减PV算的——52万 vs 50万。但这两个数字根本不在同一个维度上：50万是"应该完成的计划"，52万是"完成8个模块的实际支出"。拿一个没干完的计划和已经干完的活去比支出，逻辑上就不成立。

挣值的核心贡献就是引入了EV这个"同维度"的变量：你干了多少活（EV），就跟你干这些活花了多少钱（AC）去比。

进度偏差 SV = EV - PV

SV = 40 - 50 = -10万

负值意味着进度落后。按计划你该完成50万的活，但只完成了40万的。

成本绩效指数 CPI = EV / AC

CPI = 40 / 52 = 0.77

你每花1块钱，只产出了0.77元的价值。低于1就是亏的。

进度绩效指数 SPI = EV / PV

SPI = 40 / 50 = 0.80

你的进度只完成了计划的80%。

把四个指标摆在一起：

1
2
3
4

CV = -12万    → 超支12万
SV = -10万    → 落后计划10万的工作量
CPI = 0.77    → 每花1元只产出0.77元
SPI = 0.80    → 进度只完成计划的80%

这才是一个项目在第5个月的真实体检报告。

不是"感觉还行"，也不是"超支2万问题不大"——是成本效率只有77%，进度落后20%，如果不干预，这个项目会严重失控。

EAC：最让人焦虑的那个数字

知道现在的情况还不够，老板最关心的是：照这么下去，最终要花多少钱？

这就是完工估算 EAC（Estimate at Completion）。

EAC 有三种算法，对应三种不同的假设：

假设一：剩下的活按当前效率干

EAC = BAC / CPI = 100 / 0.77 = 129.9万

如果团队继续保持目前"每花1块只产出0.77元"的效率，整个项目要花近130万才能完工。超预算30%。

这是最悲观但也最现实的算法——凭什么你觉得后半段效率会突然变好？

假设二：剩下的活按原计划效率干

EAC = AC + (BAC - EV) = 52 + (100 - 40) = 112万

如果后半段团队能恢复正常效率（CPI回到1.0），那剩余60万的工作量就花60万，总计112万。

这个算法隐含了一个前提：前半段的低效率是特殊情况，后面不会再发生。你需要问自己——这个前提成立吗？

假设三：重新估算剩余工作

EAC = AC + 重新估算的剩余成本

当你发现原有预算假设已经完全不靠谱的时候，就需要把剩余工作重新估一遍。这是最准确但也最耗时的方法。

选哪个？

我的建议是：默认用第一种，除非你有非常明确的理由相信效率会恢复。

临界指数：一个被忽视的判断工具

SPI × CPI 的乘积被称为临界指数（Critical Index），它是一个快速判断项目是否需要紧急干预的指标。

临界指数 = SPI × CPI = 0.80 × 0.77 = 0.616

判断标准：

0.616落在"需要关注"区间。还没到"推倒重来"的地步，但必须在本月内拿出纠偏方案。

落地：研发项目怎么用起来

挣值管理在建筑工程、军工项目中是标配，但在软件研发项目里一直"水土不服"。核心原因是软件项目的工作量不好量化。

你不能像数砖头一样数代码行数。但你可以做以下几件事来让挣值分析落地。

1. WBS 拆到可度量的颗粒度

把项目拆成工作包（Work Package），每个工作包有明确的完成标准和预算。

别拆成"后端开发"这种大颗粒。拆成：

1
2
3
4
5
6
7
8
9

用户模块
├── 注册接口（0.5人天）
├── 登录接口（0.5人天）
├── 权限校验（1人天）
└── 用户列表（1人天）
订单模块
├── 创建订单（2人天）
├── 支付回调（1.5人天）
└── ...

每个子项有预算（人天），有完成标准（接口联调通过/测试通过/上线完成）。

2. 完成度用0/100或50/50，别用百分比

很多人喜欢说"这个功能完成了70%"。问题是70%是谁估的？凭什么不是65%或80%？

推荐用简单的规则：

• 0/100法：没完成就是0，完成了就是100。简单粗暴，但杜绝了"完成了99%“的自欺欺人。
• 50/50法：开始做就算50%，完成算100%。适合周期较短的工作包。

3. 每周（或每个Sprint）算一次挣值

不用搞复杂的工具，一个Excel就行：

1
2
3
4
5
6
7
8
9

工作包         预算(人天)  状态     EV
注册接口         0.5       完成     0.5
登录接口         0.5       完成     0.5
权限校验         1.0       未完成   0
用户列表         1.0       未完成   0
创建订单         2.0       完成     2.0
支付回调         1.5       未完成   0
...
合计             50        -        28

然后：

• PV = 按计划应该完成的工作包预算之和
• EV = 已完成工作包的预算之和（用0/100法）
• AC = 实际投入的人天

三个数字一出来，SPI、CPI、EAC全都能算。

4. 画一张挣值曲线图

把每个检查点的 PV、EV、AC 画成折线图。

三条线的关系一目了然：

• EV 和 PV 贴在一起 → 进度正常
• EV 和 AC 贴在一起 → 成本正常
• 三条线越拉越开 → 项目在失控

这比任何文字描述都有说服力。下次开周会，把这张图往PPT上一放，不需要解释"感觉还行"还是"风险可控”——数据自己会说话。

几个常见的坑

“我们的项目太小了，用不着挣值”

项目越小越应该用。5个人的项目超支20%你可能浑然不觉，但50万预算的项目超支10万就是实打实的亏损。挣值分析的计算量不大，关键是养成习惯。

“敏捷项目不适合挣值”

敏捷项目也可以用挣值。把Sprint的Story Point当作"预算定额"，每个Sprint结束后统计完成的Story Point总数就是EV。很多敏捷工具（JIRA、Azure DevOps）的燃尽图本质上就是简化版的挣值曲线。

“CPI低于1就一定要加班赶进度”

不一定。CPI低说明成本效率差，但原因可能是：

• 人员技能不匹配（需要培训或换人）
• 需求频繁变更（需要冻结范围）
• 技术债务拖慢开发速度（需要安排重构Sprint）

加班是最简单但最不可持续的纠偏方式。先找到根因，再决定对策。

一套可以拿去用的周报模板

最后给一个挣值驱动的周报结构：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

## 项目周报 - 第X周

### 进度快照
| 指标 | 数值 | 状态 |
|------|------|------|
| PV   | xx万 | 计划完成 |
| EV   | xx万 | 实际完成 |
| AC   | xx万 | 实际花费 |
| SPI  | x.xx | 🟢/🟡/🔴 |
| CPI  | x.xx | 🟢/🟡/🔴 |
| EAC  | xx万 | 预计完工成本 |

### 偏差分析
- 进度偏差原因：...
- 成本偏差原因：...

### 纠偏措施
- 本周采取的措施：...
- 下周计划：...

### 挣值曲线
[插入PV/EV/AC趋势图]

把这套模板用起来，你的项目周报会从"一切正常"的废话，变成真正能驱动决策的工具。

挣值管理不是什么高深的东西。它就是一个习惯——每周花30分钟，算三个数字，画一张图。这30分钟可能帮你省下的，是项目失控后几个月的救火时间。