研发承诺兑现率统计最容易失真的地方，是承诺范围和承诺时点没有固定下来：范围随需求调整而扩大，时点随计划更新而后移，最后用变更后的计划去对照结果，兑现率看起来不错，却无法反映真实的交付稳定性。本文围绕一条可复算的规则展开：先冻结承诺基线，再定义延期、降范围、取消三类变更的记录与计分方式，最后用双口径分别呈现兑现结果和变更情况。文中示例为演示情景，用于说明计算过程。
要点总览（TL;DR）
- 统计规则先固定三件事：承诺范围（哪些工作项算承诺）、承诺时点（以哪个时间点的承诺为基准）、变更判定（延期、降范围、取消如何记录并计分）。
- 以承诺基线为唯一统计对象：在承诺时点冻结范围与完成日期清单，后续调整作为基线变更留痕，兑现率始终按基线口径计算。
- 承诺范围采用纳入与排除清单界定，纳入已排期需求、对外交付里程碑和清单内关键技术任务，排除探索性任务、未排期需求和未走变更流程的临时插入事项。
- 延期、降范围、取消三类变更分别判定与计分，宽限期和折算方式在基线冻结时提前约定，所有周期统一适用。
- 兑现率与变更披露双口径并列呈现，读者能判断兑现结果来自交付稳定还是范围调整，规则上线前用已结束周期回放试算。
统计规则的核心框架：一条基线、三类变更、两个口径
承诺兑现率统计规则可以拆成三个部件：承诺基线、变更分类、双口径披露。三者缺一，规则就会在变更频繁时失去解释力。建议把“承诺基线”作为唯一统计对象：在约定的承诺时点，冻结一份包含工作项范围与承诺完成日期的清单，后续所有调整都作为对这份基线的变更留痕，兑现率始终按基线口径计算。
承诺基线的作用是提供可复算的对照物。没有基线，兑现率只能拿“最后一次计划”与“实际结果”比较，计划每改一次，分母和分子都跟着变，统计结果无法跨周期比较。基线冻结后，范围、日期、责任人都有明确版本，任何人复核时都能还原当时的承诺内容。
变更按对承诺的影响方式归为三类，判定标准互斥：
- 延期：范围不变，承诺完成日期晚于基线日期。
- 降范围：完成日期不变或提前，但交付内容少于基线清单。
- 取消：基线中的工作项整体不再交付，包括主动取消与因外部条件被动取消。
同一工作项在一个统计周期内可能先延期再降范围，记录时按发生顺序逐条登记，计分以最终状态为准，变更次数按条数累计。这样既保留过程信息，也避免重复计分。
双口径指两个并列的输出：兑现率按基线口径计算，回答“当初承诺的东西兑现了多少”；变更情况按变更口径单独披露，回答“过程中调整了多少、调整成什么类型”。两个数字分开呈现，读者既能看结果，也能看过程稳定性。统计周期建议与承诺周期一致，例如按迭代、按版本或按月；统计对象层级建议固定到“承诺清单”一级，避免同一工作项在需求、任务多个层级重复计入。
承诺范围如何界定：纳入与排除清单
承诺范围界定要回答一个问题：哪些工作项在承诺时点被明确列入交付清单。判断标准建议采用“已排期、有明确交付物、有承诺完成日期”三条同时满足，而不是按工作项类型一刀切。以下清单可作为起点，团队按自身交付形态调整后固化。
| 类别 | 典型工作项 | 是否纳入 | 判断依据 |
|---|---|---|---|
| 已排期需求 | 已分配到具体版本或迭代、有验收标准的需求 | 纳入 | 范围与日期在承诺时点可被稳定引用 |
| 对外交付里程碑 | 对客户、合作方或上级承诺的版本节点 | 纳入 | 存在外部可感知的交付约定 |
| 承诺清单内的技术任务 | 为支撑上述需求必须完成的关键技术工作 | 纳入 | 在承诺清单中单独列明，不隐藏在需求下 |
| 探索性任务 | 技术预研、方案验证、可行性试验 | 排除 | 结果不确定，无法在承诺时点确定交付物 |
| 未排期需求 | 进入需求池但未分配版本或迭代 | 排除 | 没有承诺完成日期 |
| 临时插入事项 | 承诺时点之后新增、未走范围变更流程的事项 | 排除 | 未进入承诺清单，单独统计为插入工作量 |
承诺范围的冻结发生在承诺时点，冻结后清单进入只读状态，新增或删减必须走范围变更流程。解冻只在两种条件下发生：统计周期结束、基线归档；或承诺确认方批准整体重排并生成新基线。新基线生成后，旧基线保留，统计时明确使用哪一版，避免同一周期出现两套口径。
范围变更需要记录以下字段，缺一项都会导致后续无法复核：变更类型（新增、删减、替换）、变更前内容、变更后内容、变更原因、提出人、审批人、审批时间、生效基线版本。字段不必多，但要保证任何人拿到记录都能还原“承诺时是什么、后来改了什么、谁批准的”。
承诺时点如何界定：冻结、变更与统计截止
承诺时点的选择依据只有一条：该时点之后，范围和完成日期是否可以被稳定引用。时点太早，方案尚未收敛，承诺内容会频繁返工；时点太晚，执行已过半，承诺失去约束意义。常见候选方案及适用条件如下。
| 候选时点 | 适用场景 | 优点 | 需注意的条件 |
|---|---|---|---|
| 迭代计划会结束 | 以迭代为承诺周期的团队 | 范围与任务拆分已确认，颗粒度细 | 计划会结论需当场形成清单并留痕 |
| 版本排期评审通过 | 以版本发布为承诺周期 | 跨团队依赖已对齐，对外口径统一 | 评审后到开发启动之间仍需冻结动作 |
| 对外承诺确认 | 存在客户或合作方交付约定 | 与外部约定直接对应，约束力强 | 内部排期需同步冻结，避免内外两张清单 |
基线冻结的操作建议固定为四步：第一步，承诺提出方提交清单，包含工作项、交付物、承诺完成日期、责任人；第二步，承诺确认方逐项核对范围与日期，确认无遗漏、无重复；第三步，系统或文档中将清单标记为基线版本并记录冻结时间；第四步，冻结后的清单对执行团队可见，后续调整只能通过变更流程。完成标志是基线版本号生成、冻结时间可查、清单内容只读。
变更发生时点按审批通过时间记录，生效规则为“审批通过即生效，下一统计快照起体现”。统计截止时点建议与统计周期结束日一致，并在截止时对基线清单、变更记录、工作项实际状态做一次数据快照。快照的作用是保证事后复算结果一致，避免因工作项后续被修改而导致历史统计变化。若统计周期内发生整体重排，需在快照中标注使用的基线版本。
延期、降范围、取消如何记录并纳入兑现判断
三类变更的判定要解决两个问题：什么情况算这类变更，以及这类变更在兑现率中如何计分。建议按工作项逐条判定，计分以基线工作项为最小单位，部分兑现按比例折算。
| 变更类型 | 判定标准 | 计分方式 | 记录要求 |
|---|---|---|---|
| 延期 | 范围不变，实际完成日期晚于基线日期；可设宽限期，宽限期内完成按按期计 | 宽限期内完成计为兑现；超出宽限期计为未按期兑现，延期天数单独统计 | 记录基线日期、实际日期、延期原因、审批人 |
| 降范围 | 交付内容少于基线清单，日期不变或提前 | 按交付项数或约定权重折算部分兑现；整体交付视为未完全兑现 | 记录删减项、折算依据、确认人 |
| 取消 | 基线工作项整体不再交付 | 主动取消计为未兑现；因外部条件被动取消单独归类披露，是否计入分母由团队在规则中预先约定 | 记录取消类型、原因、审批人、发生时间 |
宽限期建议按承诺周期长度设定，例如一个迭代内允许若干工作日，具体天数由团队在规则中写明，所有工作项统一适用，不逐项协商。降范围的折算方式需要提前约定：按项数折算简单透明，适合交付物颗粒度均匀的清单；按权重折算更贴近业务价值，但权重需在基线冻结时一并确定，事后不调整。
主动取消与被动取消的区分标准是“取消决定由谁发起、是否可归因于团队可控范围”。团队主动缩减投入属于主动取消；因外部依赖缺失、需求方撤回而取消属于被动取消。两类都记录，披露时分列，避免把外部原因和内部决策混在一个数字里。变更记录的责任人为承诺提出方，审批人为承诺确认方，统计核算人只读取记录、不修改记录。
披露方式建议按变更类型分列：延期数量与平均延期天数、降范围涉及的工作项数与折算兑现比例、主动取消数与被动取消数。兑现率与变更披露并列呈现，读者可以判断“兑现率高是因为交付稳定，还是因为范围被大幅调低”。
角色分工与各环节交付物
规则能否执行，取决于每个环节是否有人负责、有产物可查。建议设置五类角色，规模较小的团队可以一人兼多角，但职责要分开写明。
| 角色 | 关键动作 | 交付物 | 时间节点 |
|---|---|---|---|
| 承诺提出方（通常是研发负责人或项目负责人） | 编制承诺清单，提出范围与日期 | 承诺清单草案 | 承诺时点前 |
| 承诺确认方（产品负责人或交付负责人） | 核对范围完整性、日期合理性，批准基线 | 已确认的承诺基线 | 承诺时点 |
| 基线冻结责任人（项目管理角色） | 执行冻结动作，维护基线版本 | 基线版本记录、冻结时间 | 承诺确认后即时 |
| 变更审批人（承诺确认方或其授权人） | 审批延期、降范围、取消申请 | 变更记录单 | 变更发生时 |
| 统计核算人（项目管理或度量角色） | 按基线口径计算兑现率，汇总变更披露 | 统计报表、数据快照 | 统计周期结束后 |
承诺提出方与确认方分离，是为了让范围与日期经过一次独立核对；冻结责任人与变更审批人分离，是为了避免“自己改自己批”。统计核算人不参与变更审批，只按记录计算，保证数字可复算。各角色的交付物建议统一存放在同一处，与工作项关联，便于统计时直接取数。
在工具承载上，ONES 的项目与工作项管理可以承载承诺清单的建立、基线版本的标记以及变更记录的关联，使冻结时间、变更审批和统计取数在同一处留痕。规则设计阶段先把字段和流程定清楚，再决定用哪些工具字段承载，能减少后期口径调整的成本。
一个变更频繁团队的示例：从基线到兑现率
以下为演示情景，数据仅用于说明计算过程，不代表真实团队。某团队以版本为承诺周期，承诺时点定在版本排期评审通过当日，基线清单共 20 个工作项，承诺完成日期为版本发布日。
基线冻结后，周期内发生三类变更各一例：工作项 A 范围不变，实际完成日期晚于基线日期 6 个工作日，超出 3 个工作日宽限期，记为延期；工作项 B 原计划交付三项功能，实际交付两项，按项数折算兑现 2/3，记为降范围；工作项 C 因需求方撤回而取消，记为被动取消，按规则不计入分母，单独披露。
| 口径 | 计算方式 | 结果 |
|---|---|---|
| 基线口径兑现率 | 分母为基线 20 项减去被动取消 1 项，共 19 项；分子为按期完成 17 项加降范围折算 2/3 项 | 约 92.1% |
| 变更披露 | 延期 1 项，平均延期 6 个工作日；降范围 1 项，折算兑现 2/3；主动取消 0 项，被动取消 1 项 | 按类型分列 |
这个示例体现两个取舍：被动取消是否计入分母，必须在规则中预先约定，示例选择不计入，理由是取消决定不由团队发起；降范围按项数折算，前提是基线冻结时已约定折算方式。若团队希望更严格，可以把被动取消也计入分母，兑现率会相应下降，但口径同样可复算。关键不是选哪个数字，而是同一规则在所有周期一致适用。
规则上线前的完成检查
规则发布前，建议由统计核算人组织一次试算，用最近一个已结束周期回放整套流程，逐项核对以下检查项。全部通过再正式启用，未通过的项目明确责任人和修正时间。
- 承诺范围清单覆盖主要交付类型，纳入与排除标准有书面说明，排除项在统计时不被误计入。
- 承诺时点已选定并写入规则，基线冻结动作可操作、冻结时间可查、清单冻结后只读。
- 延期、降范围、取消三类判定标准互斥，同一工作项不会同时落入两类；宽限期和折算方式已提前约定。
- 兑现率可按基线口径复算，变更披露按类型分列，两个口径的数字能相互解释。
- 统计截止时点有数据快照，快照包含基线版本、变更记录和实际状态，事后复核结果一致。
- 五类角色均已落实到人，承诺提出与确认、冻结与审批、记录与核算的职责分离。
- 试算周期内至少出现一次变更，验证变更记录字段完整、审批留痕可查。
检查通过后，规则连同清单模板、变更记录模板和统计报表模板一并发布，作为后续周期的统一口径。规则运行两到三个周期后，再根据实际变更分布调整宽限期或折算方式，调整需记录版本和生效时间，避免历史数据与新口径混用。
常见问题
承诺时点定在迭代计划会结束还是版本评审通过，团队该怎么选？
选择依据是该时点之后范围与完成日期能否被稳定引用。以迭代为承诺周期的团队，计划会结束时范围与任务拆分已确认，颗粒度细，适合作为承诺时点；以版本发布为承诺周期的团队，排期评审通过后跨团队依赖已对齐，对外口径统一，更适合作为承诺时点。存在客户或合作方交付约定的，可以对外承诺确认作为时点，但内部排期要同步冻结，避免内外两张清单。无论选哪个时点，冻结动作都要当场完成并留痕。
承诺周期内发生整体重排，旧基线还要保留吗？
要保留。整体重排经承诺确认方批准后生成新基线，旧基线归档但不删除，统计时明确标注使用的是哪一版基线。这样同一周期不会出现两套口径，事后复核也能还原重排前后的承诺内容。如果重排发生在统计周期中途，建议在数据快照中同时记录新旧基线版本号和切换时间。
被动取消的工作项到底计不计入兑现率分母？
两种做法都可以，关键是规则中预先约定并在所有周期一致适用。不计入分母的理由是取消决定不由团队发起，计入分母则口径更严格、兑现率相应下降。建议把主动取消与被动取消分列披露，让读者看到外部原因和内部决策各自的影响，避免两类原因混在一个数字里。
规则运行一段时间后，宽限期或折算方式可以调整吗？
可以调整，但要记录版本和生效时间，新口径只适用于生效之后的统计周期，历史数据按原口径保留，不与新口径混算。建议规则先运行两到三个周期，观察实际变更分布后再调整，调整依据写成书面说明，避免每次遇到争议就临时改口径。
团队规模小、角色由一人兼任时，职责分离还必要吗？
职责分离的目的是让范围与日期经过一次独立核对、变更审批与统计核算互不干扰。人手有限时可以一人兼多角，但每个动作仍要单独留痕：谁提出承诺、谁确认基线、谁批准变更、谁核算统计，在记录中分别写明。兼岗时至少保证统计核算人不修改变更记录，只按已有记录计算，数字才可复算。
