IT和软件项目的EVM
将挣值管理应用于IT和软件项目，比将其应用于建筑项目更具挑战性，也更加微妙。软件工作是抽象的，需求可能在项目中期发生变化，并且衡量一个功能的“完成百分比”本质上是主观的。然而，只要进行适当的调整，EVM就能为IT项目组合管理以及向非技术利益相关者传达预算和进度状态提供巨大的价值。
核心挑战：衡量软件项目中的挣值
在建筑项目中，你可以衡量物理进度（浇筑了多少立方米，铺设了多少米）。而在软件项目中，你衡量的是不可见的工作。以下是三种最常见的方法：
1. 故事点 (敏捷EVM)
在Scrum或看板环境中，团队使用故事点 (Story Points) 来估算工作量。你可以在此基础上构建EVM：
- BAC = 总故事点数 × 每个故事点的平均成本
- PV = 计划在当前冲刺 (Sprint) 完成的故事点数
- EV = 实际完成的故事点数 × 每个故事点的平均成本
- AC = 该期间的实际团队成本（工资、基础设施、许可证等）
这种方法仅在故事符合团队的“完成定义 (Definition of Done)”时才记为已完成——这可以防止“完成90%”的陷阱。
2. 基于里程碑的EVM (瀑布模型)
对于瀑布式或阶段关卡式项目，为里程碑分配预算权重（例如，需求=15%，设计=20%，开发=40%，测试=20%，部署=5%）。只有当每个里程碑完全完成并被验收时，才计入挣值。
3. 加权工作包法
将软件分解为功能模块（认证、报告、API、用户界面）。估算每个模块的成本和工期。在模块级别跟踪完成情况。这是最传统的EVM方法，适用于固定价格的IT合同。
实际案例：软件开发项目
一个定制CRM开发项目：BAC = $400,000，共8个冲刺（16周）。在第4个冲刺（第8周）时：
- 总故事点数：800。每个故事点的平均成本：$500。
- 计划到第4个冲刺完成的故事点：400。PV = 400 × $500 = $200,000
- 实际完成的故事点：320。EV = 320 × $500 = $160,000
- 实际成本（团队工资+基础设施）：AC = $195,000
CPI = EV ÷ AC = 160,000 ÷ 195,000 = 0.821（成本超支18%）
SPI = EV ÷ PV = 160,000 ÷ 200,000 = 0.800（进度落后20%）
EAC = BAC ÷ CPI = 400,000 ÷ 0.821 = $487,211
VAC = 400,000 − 487,211 = −$87,211
SPI = EV ÷ PV = 160,000 ÷ 200,000 = 0.800（进度落后20%）
EAC = BAC ÷ CPI = 400,000 ÷ 0.821 = $487,211
VAC = 400,000 − 487,211 = −$87,211
EVM与敏捷：常见的反对意见
| 反对意见 | 回应 |
|---|---|
| “敏捷没有固定的范围” | EVM可以处理带有优先级的待办列表——BAC代表商定的发布范围，而不是整个产品待办列表 |
| “每个冲刺的需求都在变” | 使用变更控制流程。批准的范围变更会更新BAC。计划外的变更是需要调查的偏差。 |
| “故事点速度 (Velocity) 更有用” | 速度对团队很有帮助；而EVM则提供了发起人和高管所需的财务视角。 |
| “我们不提前进行估算” | EVM需要一个基准。如果估算尺度一致，即使是相对估算的故事也能构成基准。 |
给IT项目经理的实用建议
- 在冲刺前设定BAC，而不是之后：基准必须稳定，EVM才有意义。
- 对于进行中的故事，只计算0%或100%：避免计算部分进度；这会夸大EV并掩盖进度风险。
- 每周跟踪CPI趋势：软件项目进展迅速。每月的EVM报告可能发现问题太晚。
- 将基础设施/运维与开发的BAC分开：基础设施成本有不同的成本驱动因素，应单独跟踪。
- 在项目集 (Program) 级别使用EVM：如果你有多个敏捷团队，请在项目集级别汇总他们的EV/AC数据，以便向高管报告。