研发团队落地挣值管理，核心是把范围、预算和进度统一到同一条可核对的基线上：先按可交付成果拆分工作包并估算预算，形成按周期的预算分布；执行中按同一口径记录实际成本与已完成工作的预算价值，再计算偏差和绩效指标，用固定节奏的复盘把偏差转成具体调整动作。研发工作存在需求变更和探索性任务，不必一开始追求全量精确，可先选一个周期稳定、可度量的项目试点，把口径、责任人和复盘机制跑通后再扩展。ONES可以在预算基线、周期数据归集和偏差复盘中承载这些管理动作。
要点总览（TL;DR）
- 先统一PV、EV、AC的口径并写入口径约定文档，明确取数来源、统计周期、完成度判定规则和责任人，再动手建基线。
- 预算基线按工作包拆分、汇总到控制账户、按统计周期分布，各周期预算之和等于总预算，基线变更走审批并保留版本。
- 每个周期末按固定动作归集AC、确认EV、取当期PV，计算CV、SV、CPI、SPI，并在约定时点发布计算表。
- 用RACI明确项目经理、技术负责人、成本口径负责人和团队成员的职责，做到谁产生数据谁负责准确性。
- 连续两个周期通过基线与口径、数据归集、偏差转动作、闭环记录四类检查，再考虑向同类项目复制。
先定口径：研发项目里PV、EV、AC分别对应什么
挣值管理的三个基础量必须先在团队内定义清楚，否则后续计算出来的偏差无法比较，也无法解释。研发场景下常见的分歧是：预算按人天还是按金额计、完成度按任务数量还是按可交付成果判断、实际成本是否包含内部人力折算。这些分歧要在动手建基线之前解决。
三个量的含义与相互关系如下：
- PV（计划价值）：截至某个统计时点，按基线计划应该完成的工作所对应的预算金额。它来自预算基线的时间分布，是事前确定的比较基准。
- EV（挣值）：截至该时点，实际已完成工作按基线预算折算出的价值。它衡量“做完了多少”，计量对象是工作包或可交付成果，而非投入了多少人天。
- AC（实际成本）：截至该时点，为完成这些工作实际发生的成本。它衡量“花了多少”。
三者关系可以概括为：PV是计划应完成的价值，EV是实际完成的价值，AC是实际消耗的成本。EV与PV比较得到进度偏差，EV与AC比较得到成本偏差。研发团队要特别注意，EV的确认必须绑定可交付成果的完成状态，避免用“任务已关闭”代替“成果已交付”。
研发场景下的计量对象建议落在工作包层级。工作包是WBS中最底层的可管理单元，应有明确的完成标准和负责人。对于探索性任务（如技术预研），可以设置里程碑式的完成标准，例如“方案评审通过”计为50%、“原型验证通过”计为100%，把主观判断转化为可核对的节点。
预算分布按周期切分的方法：先确定统计周期（研发团队常用双周或月度），再把每个工作包的预算按计划投入节奏分摊到各周期。分摊依据可以是计划工时比例、里程碑节点或资源投入计划，同一项目内保持一种方法即可。
口径约定需要写进项目预算与挣值管理说明文档，至少包含：三个量的取数来源、统计周期、完成度判定规则、成本归集范围、更新频率和责任人。下表可作为口径约定表的模板：
| 项目 | PV | EV | AC |
|---|---|---|---|
| 取数来源 | 预算基线按周期分布表 | 工作包完成状态与完成度判定记录 | 成本归集台账（人力折算、采购、外包等） |
| 计量对象 | 工作包/可交付成果 | 工作包/可交付成果 | 工作包/控制账户 |
| 更新频率 | 基线批准后固定，变更走审批 | 每统计周期末 | 每统计周期末 |
| 责任人 | 项目经理 | 技术负责人确认，项目经理汇总 | 成本口径负责人 |
建立预算基线：从工作包拆分到按周期分布
预算基线是后续所有偏差比较的参照物，它的质量直接决定挣值管理是否可信。建立基线分四步：拆分工作包、估算并汇总预算、按周期分布、确定变更规则。
工作包拆分粒度与完成标准。拆分到“一个人或一个小组在一个统计周期内可以完成并验收”的程度比较合适。每个工作包要写清交付物、验收标准和负责人。粒度过粗会导致完成度难以判断，过细会增加管理成本。研发项目中，需求分析、架构设计、模块开发、联调测试、上线准备都可以作为工作包层级。
预算估算与汇总到控制账户。对每个工作包估算预算，估算方法可以用类比估算、参数估算或自下而上汇总。工作包预算向上汇总到控制账户，控制账户是项目经理进行成本和进度管理的责任节点。汇总时要检查总额是否与项目批准预算一致，不一致则调整估算或范围。
按周期分布形成基线。把每个工作包的预算按计划投入节奏分摊到各统计周期，形成“周期—工作包—预算”的分布表。所有周期的预算之和应等于项目总预算。这张表就是PV的计算依据，基线批准后冻结。
基线变更的审批与记录。研发项目需求变更频繁，基线不可能一成不变。要规定变更触发条件（如范围增减、里程碑调整、预算调整超过一定比例）、审批人（项目经理与项目发起人）和记录方式（变更单包含变更原因、影响的工作包、调整后的周期分布）。变更批准后更新基线版本，历史版本保留可追溯。
下表是带周期分布的预算基线表结构示例（演示数据）：
| 工作包 | 负责人 | 总预算（元） | 第1周期 | 第2周期 | 第3周期 | 第4周期 |
|---|---|---|---|---|---|---|
| 需求与方案设计 | 技术负责人 | 40,000 | 30,000 | 10,000 | — | — |
| 核心模块开发 | 开发组长 | 120,000 | 20,000 | 40,000 | 40,000 | 20,000 |
| 联调与测试 | 测试负责人 | 60,000 | — | 10,000 | 25,000 | 25,000 |
| 上线准备 | 项目经理 | 20,000 | — | — | 5,000 | 15,000 |
| 合计 | — | 240,000 | 50,000 | 60,000 | 70,000 | 60,000 |
基线表批准后，项目经理在项目管理工具中把工作包与计划周期、预算字段关联起来，后续统计周期直接从工作项状态和预算字段取数，减少手工汇总误差。
执行期的数据采集与挣值计算步骤
每个统计周期结束时，按固定动作完成一次数据采集和计算，输出单周期挣值计算表。步骤和完成标志如下。
第一步：归集周期内实际成本（AC）。成本口径负责人从成本台账中归集本周期发生的成本，包括人力折算、采购、外包和差旅等已约定范围。人力折算按团队约定的单价乘以实际投入工时计算。完成标志是每个工作包都有对应的AC数值，无遗漏工作包。
第二步：确认已完成工作的预算价值（EV）。技术负责人和项目经理依据工作包完成标准，逐项确认本周期末的完成状态和完成度，乘以该工作包的预算得到EV。完成度判定要引用可核对的证据，如评审记录、测试报告、演示验收。完成标志是EV确认表经技术负责人签字。
第三步：从基线取当期PV。项目经理从预算基线分布表中取出本周期累计应完成的预算值。完成标志是PV数值与基线版本一致。
第四步：计算偏差与绩效指标。公式如下：
- 成本偏差 CV = EV − AC，为正表示成本节约，为负表示成本超支。
- 进度偏差 SV = EV − PV，为正表示进度提前，为负表示进度滞后。
- 成本绩效指数 CPI = EV ÷ AC，大于1表示成本效率好。
- 进度绩效指数 SPI = EV ÷ PV，大于1表示进度快于计划。
完成标志是单周期挣值计算表填写完整，数值经过复核。下表为计算表模板（演示数据）：
| 工作包 | PV | EV | AC | CV | SV | CPI | SPI |
|---|---|---|---|---|---|---|---|
| 需求与方案设计 | 40,000 | 40,000 | 42,000 | −2,000 | 0 | 0.95 | 1.00 |
| 核心模块开发 | 60,000 | 50,000 | 55,000 | −5,000 | −10,000 | 0.91 | 0.83 |
| 联调与测试 | 10,000 | 8,000 | 7,000 | 1,000 | −2,000 | 1.14 | 0.80 |
| 合计 | 110,000 | 98,000 | 104,000 | −6,000 | −12,000 | 0.94 | 0.89 |
数据采集的责任人与时点。成本数据由成本口径负责人在周期结束后两个工作日内提供；完成状态由技术负责人在周期最后一天确认；项目经理在周期结束后三个工作日内完成汇总计算并发布。时点固定后写入口径约定文档，形成节奏。
角色分工与交付物：谁填数、谁审核、谁决策
挣值管理跑不起来，常见原因是数据没人负责或责任重叠。用RACI方式明确每个环节的角色，可以避免“都以为别人会填”。
| 活动/交付物 | 项目经理 | 技术负责人 | 成本口径负责人 | 团队成员 | 项目发起人 |
|---|---|---|---|---|---|
| 口径约定文档 | R | C | C | I | A |
| 工作包拆分与完成标准 | A | R | I | C | I |
| 预算基线与周期分布 | R | C | C | I | A |
| 基线变更审批 | R | C | I | I | A |
| 实际成本归集（AC） | A | I | R | C | I |
| 完成状态确认（EV） | A | R | I | C | I |
| 单周期挣值计算表 | R | C | C | I | I |
| 偏差复盘与调整动作 | R | R | C | C | A |
说明：R为负责执行，A为最终批准，C为被咨询，I为被通知。
各角色的输入与输出：项目经理输入项目范围与批准预算，输出基线、计算表和复盘记录；技术负责人输入工作包完成证据，输出EV确认结果；成本口径负责人输入成本台账，输出AC数据；团队成员输入任务进展和工时记录，输出完成状态依据；项目发起人输入预算授权，输出基线批准和重大变更决策。
评审与签核节点设在两处：基线批准时由项目发起人签核，周期计算表发布前由项目经理和技术负责人联合复核。数据质量的责任归属原则是“谁产生数据谁负责准确性，项目经理对汇总结果负责”。发现数据错误时，追溯到源头角色修正，并在下个周期复盘时说明原因。
在工具层面，ONES的项目计划与工作项状态可以承载工作包拆分和完成状态记录，预算字段与周期分布可以在项目视图中维护，报表能力用于汇总各周期的PV、EV、AC并生成偏差视图，让角色分工落到具体的工作项和文档上。
一个研发项目的落地示例：从基线到一次偏差复盘
以下示例为演示情景，用于说明流程，数据为虚构。
示例项目范围与基线设定。某研发团队开发一个内部管理系统的两个核心模块，项目周期8周，按双周划分为4个统计周期，总预算240,000元。工作包拆分为需求与方案设计、核心模块开发、联调与测试、上线准备四个，预算分布如S2表格所示。基线在第1周期开始前批准，版本V1.0。
第2周期末的数据与计算。截至第2周期末，累计PV为110,000元。技术负责人确认：需求与方案设计全部完成，EV为40,000元；核心模块开发完成约一半，EV为50,000元；联调与测试尚未正式开始，EV为8,000元（部分测试用例设计完成）。成本口径负责人归集AC为104,000元。计算结果：CV = 98,000 − 104,000 = −6,000元，SV = 98,000 − 110,000 = −12,000元，CPI = 0.94，SPI = 0.89。
偏差原因分析与调整动作。复盘会上，团队识别出两个原因：核心模块开发中一个接口方案返工，导致该工作包进度滞后且多投入了人力；联调与测试的前置准备比计划启动晚。对应调整动作：接口方案由技术负责人组织一次专项评审，冻结方案后不再变更；从第3周期起为联调与测试增加一名测试人员，压缩后续测试周期；核心模块开发剩余部分调整任务分配，把两个低风险子任务并行推进。调整动作写入下周期计划，明确责任人和完成时点。
复盘结论回写计划。由于范围和总预算未变，基线不整体变更，但第3、4周期的预算分布按调整后的资源投入重新分摊，形成基线V1.1并记录变更原因。复盘记录归档，作为下个周期比较的起点。第3周期末再次计算，CPI回升至0.97，SPI回升至0.93，说明调整动作产生了效果。
这个示例说明，偏差复盘的价值在于把数字转成可执行的动作，并让动作在下一个周期被验证。复盘记录应包含：偏差数值、原因、调整动作、责任人、验证时点。
落地完成检查：判断机制是否真正跑通
机制是否跑通，不看文档写得多完整，而看四个维度是否稳定运转。以下检查清单可逐项核对，任一项不通过即视为阻断项，需要先修复再扩展。
| 检查维度 | 检查项 | 通过标准 |
|---|---|---|
| 基线与口径 | 口径约定文档是否批准并发布 | 三个量的取数来源、周期、责任人明确，团队已知晓 |
| 基线与口径 | 预算基线是否批准且按周期分布 | 各周期预算之和等于总预算，基线版本可追溯 |
| 基线与口径 | 基线变更是否走审批并记录 | 每次变更都有变更单和版本号 |
| 数据归集 | AC是否按周期准时归集 | 连续两个周期在约定时点前完成，无遗漏工作包 |
| 数据归集 | EV是否有可核对证据 | 完成度判定引用评审、测试或验收记录 |
| 数据归集 | 计算表是否按时发布并复核 | 周期结束后三个工作日内发布，有复核记录 |
| 偏差转动作 | 偏差是否在复盘会上分析 | 每个显著偏差都有原因说明 |
| 偏差转动作 | 调整动作是否明确责任人和时点 | 动作进入下周期计划，可被跟踪 |
| 偏差转动作 | 调整效果是否在下周期验证 | 复盘记录中有验证结果 |
| 闭环记录 | 复盘记录是否归档 | 可按项目、周期检索 |
| 闭环记录 | 基线与实际数据是否可追溯 | 任一历史周期的PV、EV、AC可还原 |
阻断项包括：口径未统一导致同一指标出现两种算法；连续周期AC缺失或延迟超过一周；偏差分析后没有形成任何调整动作；复盘记录缺失导致无法追溯。出现阻断项时，先暂停扩展范围，集中修复该环节，再恢复常规节奏。
当上述检查项连续两个周期全部通过，可以认为挣值管理机制在该项目上跑通，再考虑向同类项目复制。复制时保留口径约定和检查清单，按项目特点调整工作包拆分和统计周期即可。
常见问题
研发任务存在探索性，完成度难以量化，EV怎么确认才不至于变成拍脑袋？
把探索性任务的完成标准从“做了多少”改成“通过了什么节点”。例如技术预研可以约定：方案评审通过计50%，原型验证通过计100%，每个节点都对应可核对的评审记录或验证报告。EV确认时引用这些证据，而不是由负责人凭感觉给百分比。
如果某个工作包在周期内确实无法判断完成度，宁可先按上一个已确认节点计量，把不确定性留到复盘会上讨论，也不要在计算表里填一个没有依据的数字。口径约定文档中应写明这类任务的处理规则。
需求变更频繁时，预算基线是不是要频繁重做？
不必每次变更都整体重做基线。先判断变更是否影响范围、里程碑或预算总额：只影响个别工作包的内部安排时，在当期计划中调整即可；影响范围或总预算时，走基线变更审批，更新周期分布并生成新版本号，历史版本保留可追溯。
关键是变更要有触发条件和审批人，变更单写清原因、影响的工作包和调整后的周期分布。这样基线始终是当前有效的比较基准，同时历史数据可还原。
团队规模小、没有专职成本人员，AC由谁归集比较现实？
可以由项目经理兼任成本口径负责人，但要把归集范围和单价规则提前写进口径约定文档，避免每次临时判断。人力折算按团队约定的单价乘以实际投入工时计算，采购、外包等外部支出按实际发生额记录。
需要留意的是，兼任不等于可以省略复核。周期计算表发布前仍应有一名不直接填数的人做一次核对，重点检查是否有工作包漏记AC、单价是否用错。规模扩大后再考虑把成本归集职责独立出来。
CPI和SPI出现偏差后，什么情况下需要调整基线，什么情况下只调整执行计划？
判断依据是偏差的成因是否改变了原定的范围、里程碑或预算总额。如果只是执行效率问题，例如返工导致某工作包多投入人力，通过调整任务分配、增加资源或压缩后续周期来纠正，基线保持不变，只更新执行计划。
如果偏差来自范围增减或关键里程碑整体后移，原基线已不能作为比较基准，就应走变更审批更新基线。无论哪种情况，复盘记录都要写明偏差数值、原因、调整动作、责任人和验证时点，并在下个周期核对调整是否生效。
挣值管理跑通后，向其他研发项目复制时哪些内容需要重新设计？
口径约定和检查清单可以直接沿用，工作包拆分和统计周期需要按项目特点重新设计。周期长短取决于项目的交付节奏，工作包粒度取决于任务的可分解程度和团队规模。
复制时建议先在新项目上跑一个完整周期，核对数据能否按时归集、完成度是否有证据支撑，再决定是否扩大范围。不同项目的预算规模差异较大时，偏差的绝对值和绩效指数的解读方式也要在复盘会上说明清楚。
