挣值管理不只是考证公式：用 SPI/CPI/EAC 真正量化研发项目健康度

Sun, 05 Jul 2026 12:00:00 +0800

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

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

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

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

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

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

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

一个让所有人闭嘴的例子

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

项目	数值
总模块数	20个
总预算	100万元
计划工期	10个月
每月计划完成	2个模块
每模块预算	5万元

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

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

传统做法怎么看？

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

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

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

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

三个基本参数：

参数	全称	含义	本例数值
PV (BCWS)	计划价值	按计划应该完成的工作对应的预算	50万（5个月×10万/月）
EV (BCWP)	挣值	实际完成的工作按预算定额算出来的价值	40万（8个模块×5万/模块）
AC (ACWP)	实际成本	实际花了多少钱	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%。

把四个指标摆在一起：

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 + 重新估算的剩余成本

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

选哪个？

场景	推荐算法	本例EAC
当前效率会延续（最常见）	BAC / CPI	129.9万
前半段是特殊情况	AC + (BAC - EV)	112万
原预算假设已失效	AC + 重估剩余	需重新评估

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

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

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

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

判断标准：

临界指数	项目状态	建议动作
> 0.8	基本健康	常规监控
0.4 ~ 0.8	需要关注	分析根因，制定纠偏计划
< 0.4	严重预警	项目可能需要重新评估和规划

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

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

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

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

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

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

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

用户模块
├── 注册接口（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就行：

工作包         预算(人天)  状态     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）

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

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

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

## 项目周报 - 第X周

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

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

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

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

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

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

EAC on 文艺技术笔记