去年冬天一个机房改造项目的周例会上甲方负责人指着大屏上那句总体完成度 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 形而不是一条斜直线。正确的做法是自下而上滚出来的先把项目拆到控制账户Control Account层级每个控制账户对应 WBS 上的一个可管理单元有唯一责任人、独立预算、可测量的产出物。每个控制账户内部再把预算分配到具体的进度活动上形成某活动在某时间段内计划消耗多少预算。按时间轴把所有活动的预算累加就得到这条 PV 曲线。打个比方PV 就像给项目排的一张预算消耗时刻表。它不是平均数而是排班表——哪天该上多少人、该进多少货对应那天就该消耗多少预算。提示PV 一旦随基准确定下来就应该是冻结的。除了走正式变更流程调整 BAC 并重新基线化任何时候都不要因为这个月实际情况特殊而去手工修 PV。PV 一动SPI 就失去了全部意义。1.3 EV 的计量规则决定了整套体系可不可信如果说 PV 是排班表那 EV 就是考勤加产量记录而这里恰恰是挣值管理最容易掺水的地方。常见的 EV 计量规则有四种各有适用场景计量方法规则适用工作类型主要风险0/100 法未完成计 0全部完成才计 100%硬件到货验收、单项测试、文档交付长周期任务期间 EV 长期为 0曲线失真50/50 法开工即计 50%完工再计 50%周期短、颗粒度小的工作包开工即虚增掩盖真实进度20/80 法开工计 20%完工计 80%中等周期的实施类工作同上虚增幅度小一些百分比完成法按主观评估的完成比例折算软件开发、方案设计等难以量化的脑力工作主观性极强90% 完成综合症我在项目上见过最离谱的一次是一个联调工作包连续六周报完成度 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 进度偏差EV − PV货币进度上少挣或多挣了多少价值0 进度提前0 落后CV 成本偏差EV − AC货币成本上节约或超支了多少0 节约0 超支SPI 进度绩效指数EV ÷ PV无量纲每计划 1 元的活实际干出了多少1 提前1 落后CPI 成本绩效指数EV ÷ AC无量纲每花 1 元挣回了多少价值1 节约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 都容易误判四个数放在一起看才有意义。下面这张表是我自己在项目上用的判断矩阵SVCVSPICPI状态判断典型成因处置方向0011进度提前、成本节约估算偏保守、效率高于预期警惕虚假繁荣核查 EV 是否虚高、是否有工作被跳过0011进度快、成本超支抢工、加班、高价外购、返工检查是否用钱买进度评估抢工是否对准关键路径0011进度慢、成本节约人力投入不足、低价资源替代警惕省出来的进度债评估后期集中投入的可行性0011双落后需求蔓延、变更失控、估算严重偏低立即启动根因分析考虑重定基线或调整范围第二种组合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 AC 重新估算的剩余工作成本不相信历史效率重新逐项估算项目发生重大变更、前期估算严重失真最准最费时非典型偏差法EAC AC (BAC − EV)偏差是偶发的剩余工作按原预算效率完成一次性事件导致超支已纠正乐观典型偏差法EAC BAC ÷ CPI当前成本效率会持续到项目结束系统性的效率问题最常用考虑进度的综合法EAC AC (BAC − EV) ÷ (CPI × SPI)成本与进度效率同时持续进度严重落后且需赶工最悲观我个人的取用习惯是这样日常滚动预测用典型偏差法因为它最保守也最稳定一旦识别出明确的一次性事件比如某个供应商涨价一次性影响后续已换供应商就把这部分从偏差里剔出去用非典型偏差法重算只有在项目出现重大范围变更、原估算基本作废的时候才动用自下而上重估这个动作很重一个中型项目做一次要花两三天。用上一节的例子接着算典型偏差法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 计量规则套所有类型的工作。系统集成项目的四类工作性质差异太大必须分类处理。工作类型推荐计量方法具体计量依据采集频率硬件采购0/100 法 里程碑合同签订计 0到货验收合格计 100%大额可分到货 70%、验收 30%按到货批次软件开发里程碑 客观指标功能点通过单元测试、集成测试的数量 ÷ 总数每周现场施工实物量法机柜上架数、信息点端接并测试合格数、线缆敷设米数每周系统联调用例通过率通过的测试用例数 ÷ 总用例数阻塞用例单独列每周培训验收0/100 法培训完成并签到、文档交付并签收按节点重点说硬件采购这一块因为它占预算最大、也最容易失真。很多人图省事设备一发货就报 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 拆到控制账户问题立刻显形控制账户预算占比SPICPI是否关键路径硬件采购48%1.000.92是机房施工13%0.850.95是软件开发22%1.420.78部分系统联调12%0.601.05是培训验收5%未开始—是整体 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.05CPI 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.05CPI 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 六个高频陷阱逐条对照检查陷阱类型具体表现规避方法时间点错位用全部预算当作 PV没按检查时点折算PV 一定是截至检查时点的计划价值不是 BAC单位不统一题干里预算用万元AC 用元或者人天与货币混用动笔前先把所有数字换算成同一单位写在草稿纸最上方正负号搞反算完 SV −40 却又写进度提前 40 万记住正值代表好SV0 提前CV0 节约EAC 公式选错题干明说偏差将持续还用了非典型偏差法抓关键词持续一贯将继续→ 典型偏差法一次性已纠正→ 非典型偏差法TCPI 分母混淆题目给了 EAC仍然用 BAC − AC 作分母分母看目标要在原预算内完工用 BAC − AC要在 EAC 内完工用 EAC − AC忘记 ETC让求还需要多少成本直接答了 EAC还需要 EAC − AC两回事还有一个特别典型的坑问按当前进度项目还需要多少时间。这类题的标准做法是计划总工期 ÷ 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 三个数每周对上一次对到你能毫不犹豫地说出它们的来源为止。等这三个数干净了后面那一整套预测体系自然就转起来了。
