延期、降范围、取消频繁发生时，如果每次变更都直接改写原始承诺，兑现率就会失真：分母被替换、原始日期被覆盖，最终数字既无法解释，也无法比较。本文给出一套可执行的统计规则，把承诺单元、承诺时点、三档判定和三类变更记录固定下来，让兑现率与变更次数分别反映交付可靠性与计划稳定性。
要点总览（TL;DR）
- 承诺兑现率以“承诺单元”为统计对象：一个可独立验收的交付项及其范围、日期、验收标准构成一个单元，承诺时点以评审通过并对外承诺的时间锁定基线，之后变更只追加记录、不覆盖原始承诺。
- 兑现判定分三档：按期按范围交付计为兑现；延期或降范围后仍交付计为有条件兑现，按组织事先约定的权重折算；取消或未交付计为未兑现。计算公式为兑现率=（兑现单元数+有条件兑现折算数）/承诺单元总数。
- 延期记录原日期与新日期，并判断最终交付是否落在承诺周期内；降范围记录移出项与保留项，移出项可转为下期新承诺单元或不计入本期；取消区分主动与被动，均计为未兑现并注明原因。
- 变更次数作为独立观测指标与兑现率并列呈现，避免用变更次数直接扣减兑现率，使“频繁变更”与“交付不可靠”两类问题可分别识别。
- 统计周期按承诺时点归属，避免跨期漂移；紧急变更可先执行后补录，但需明确补录时限与责任人。
先定统计口径：承诺单元、承诺时点与兑现判定
承诺兑现率的统计对象是“承诺单元”，而非项目、版本或团队。一个承诺单元指一个可独立验收的交付项，由三项要素共同界定：交付范围（包含哪些功能、模块或交付物）、承诺日期（对外承诺的完成时间）、验收标准（判定完成的依据）。三项要素缺一，就不能构成可统计的承诺单元。把颗粒度定在可独立验收的交付项上，延期、降范围、取消才有明确的落点，不会因为项目整体口径模糊而无法判断。
承诺时点：锁定基线，变更只追加
承诺时点以评审通过并对外承诺的时间为准。在该时点，承诺单元的范围、日期、验收标准被锁定为基线，写入承诺台账。此后发生的任何调整，都以变更记录的形式追加在原始承诺之后，原始承诺值保持不变。这条规则是整套统计的基础：它保证分母稳定，也让“承诺时是什么”和“最终交付了什么”可以分开查看。承诺时点之后才提出的需求，应作为新的承诺单元登记，不并入原单元。
三档兑现判定与计算公式
兑现判断按最终交付结果分为三档，变更本身不直接改分，改分的是变更后的交付结果。
| 判定档位 | 适用情形 | 计分方式 |
|---|---|---|
| 兑现 | 按原承诺日期、原承诺范围完成并通过验收 | 计 1 |
| 有条件兑现 | 延期后仍交付，或降范围后按保留范围交付并通过验收 | 按组织事先约定的权重折算，如 0.5–0.8 |
| 未兑现 | 取消、未交付，或交付未通过验收 | 计 0 |
计算公式为：兑现率 =（兑现单元数 + 有条件兑现折算数）/ 承诺单元总数。折算权重由组织在规则上线前书面约定，并按变更类型区分，例如“仅延期”与“延期且降范围”可设不同权重。权重一旦确定，同一统计周期内保持一致，避免事后调整影响可比性。
统计周期与样本范围
承诺单元按承诺时点归属统计周期，而非按实际交付时间归属。6 月承诺、7 月交付的单元，计入 6 月周期，这样周期之间的数据不会因为交付延后而漂移。统计样本为该周期内所有已锁定的承诺单元，包括最终取消的单元；尚未到承诺日期、仍在执行中的单元不计入当期分子分母，单独列为在途单元。
延期、降范围、取消三类变更怎么记录
三类变更共用一张变更记录表，字段统一，填写规则按类型区分。记录的目的是保留变更轨迹，让每个承诺单元的最终判定可以回溯到具体变更，而不是让变更去修改原始承诺。
变更记录表字段
| 字段 | 填写要求 |
|---|---|
| 承诺单元编号 | 与承诺台账一致，一个单元可对应多条变更记录 |
| 变更类型 | 延期 / 降范围 / 取消 |
| 发起时间 | 变更申请提出的日期 |
| 原承诺值 | 承诺时点锁定的日期与范围，从台账带出，不手工改写 |
| 变更后值 | 调整后的日期或范围 |
| 原因分类 | 需求变化、技术风险、资源不足、外部依赖等，按组织统一分类填写 |
| 审批人 | 按审批机制确认的产品负责人与研发负责人 |
三类变更的填写规则
延期：记录原日期与新日期，并判断最终交付是否落在原承诺周期内。若新日期仍在原统计周期内且按范围交付，可判为兑现；若跨出原周期，判为有条件兑现。延期记录不修改台账中的原承诺日期。
降范围：记录移出项与保留项，逐项列明。移出项有两种处理方式，需在规则中二选一并保持稳定：转为下期新承诺单元登记，或不计入本期统计。保留项按调整后的范围验收，通过则判为有条件兑现。移出项不能既不计入本期、又不在下期登记，否则会形成统计盲区。
取消：区分主动取消（如业务方向调整、需求撤销）与被动取消（如资源撤出、外部依赖失效），两类均计为未兑现，并在原因分类中注明具体原因。取消记录保留原承诺值，便于后续分析取消集中在哪些类型的需求或阶段。
变更次数作为独立指标
变更次数单独统计，与兑现率并列呈现，不直接扣减兑现率。一个单元发生多次变更时，记录变更次数并在汇总时按单元计数。这样“频繁变更”和“交付不可靠”成为两个可分别识别的问题：兑现率高但变更次数多，说明计划稳定性不足；兑现率低且变更次数少，说明承诺时评估偏差较大。两类问题的改进方向不同，合并成一个分数会掩盖差异。
角色分工与变更审批机制
变更频繁时，数据完整性的主要风险来自口头变更和事后补记。角色分工要解决三个问题：谁发起、谁审批、谁维护台账，以及用什么节奏核对遗漏。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 交付负责人 | 发起变更申请，填写变更类型、变更后值与原因分类 | 变更申请记录 |
| 产品负责人 | 确认范围调整的必要性与移出项处理方式 | 范围变更确认 |
| 研发负责人 | 确认日期调整的可行性与资源影响 | 日期变更确认 |
| 项目经理或效能接口人 | 维护承诺台账与变更记录，按节奏复核 | 承诺台账、变更台账、周期统计结果 |
审批机制上，范围调整由产品负责人与研发负责人共同确认，日期调整由研发负责人确认并知会产品负责人，取消需双方共同确认。审批完成标志是变更记录表中审批人字段填写完整，未完成审批的变更不进入统计。
复核节奏按迭代或按月执行，由项目经理或效能接口人对照承诺台账逐项核对：每个承诺单元是否有对应的变更记录，是否存在已口头调整但未登记的日期或范围。复核的输出是一份差异清单，逐条补录或确认无需变更。这一步在变更频繁的团队中尤其关键，因为遗漏往往发生在“大家都知道改了、但没人登记”的环节。
紧急变更允许先执行后补录，但需明确补录时限与责任人，例如由发起人在变更执行后两个工作日内完成补录，项目经理在下次复核时检查补录完成情况。补录记录同样保留原承诺值，不因补录而改写基线。
当承诺台账、变更记录与交付状态分散在文档和表格中时，维护成本会随变更频率上升。ONES 的项目管理工作项可以承载承诺单元及其范围、日期、验收标准，变更通过状态流转和字段更新留下记录，承诺台账与变更记录在同一处维护，周期统计时按承诺时点筛选即可取数。这样复核时核对的是同一份数据，减少台账与执行记录对不上的情况。
一个完整示例：三次变更的承诺单元如何计分
以下为演示情景，用于说明规则如何执行，数据为假设值。
某团队在 6 月周期承诺两个交付项。交付项 A 承诺 6 月 30 日交付三个模块（模块一、二、三），验收标准为三个模块均通过功能验收；交付项 B 承诺 6 月 25 日交付报表功能。两个单元在 6 月初评审通过并对外承诺，锁定为 6 月周期的承诺单元，分母为 2。
变更一：交付项 A 因接口联调延迟，申请延期至 7 月 15 日，审批通过并记录原日期与新日期。最终 A 在 7 月 15 日按三个模块交付并通过验收。由于交付跨出 6 月周期，A 判为有条件兑现，按约定权重 0.7 折算，计 0.7。
变更二：交付项 A 在执行中移出模块三，记录移出项与保留项，模块三转为 7 月周期的新承诺单元登记。A 的保留范围（模块一、二）按调整后范围验收通过，这一变更不改变 A 已判定的有条件兑现档位，但计入 A 的变更次数。
变更三：交付项 B 因业务方向调整主动取消，记录取消类型与原因，计为未兑现，计 0。
6 月周期汇总：兑现单元数 0，有条件兑现折算数 0.7，未兑现单元数 1，承诺单元总数 2，兑现率 =（0 + 0.7）/ 2 = 35%。变更次数方面，A 发生 2 次变更，B 发生 1 次，该周期共 3 次变更，平均每单元 1.5 次。解读时两个指标一起看：兑现率偏低主要由 B 的取消造成，而 A 的两次变更说明该单元在承诺时的范围与日期评估偏乐观，改进方向分别是取消原因复盘和承诺前评估校准，而非简单归因为执行不力。
上线前的完成检查
规则投入运行前，按以下清单逐项核对，确认口径可执行、数据可信、团队理解一致。
- 口径检查：承诺单元定义、承诺时点规则、三档判定标准与折算权重是否已书面确认，并明确移出项的处理方式（转下期或不计入本期）。
- 数据检查：变更台账是否覆盖统计周期内全部承诺单元，逐项核对有无遗漏的口头变更，紧急变更的补录是否在时限内完成。
- 一致性检查：同一周期内兑现率与变更次数能否相互解释，是否存在兑现率高但变更次数异常多、或兑现率低却无变更记录的单元，后者通常意味着记录缺失。
- 沟通检查：统计结果是否已与团队对齐口径，说明其用途是识别计划稳定性问题，避免被理解为对个人的考核惩罚工具。
- 迭代检查：首期运行结束后回看误判案例，例如因验收标准表述不清导致的判定争议、因承诺时点认定不一致导致的归属错误，据此修订规则并记录修订版本。
完成以上核对后，规则即可进入试运行。试运行期间保持口径不变，先积累一到两个周期的数据，再评估折算权重是否合理、变更原因分类是否够用，避免在数据尚未稳定时频繁调整规则。
常见问题
有条件兑现的折算权重应该怎么定，定多少合适？
权重没有统一标准，取决于组织希望用兑现率反映什么。常见做法是按变更类型分档：仅延期且交付质量达标的单元给较高权重，延期同时降范围的单元给较低权重，使分数能区分变更的严重程度。建议在规则上线前书面约定，并在同一统计周期内保持不变。首期试运行积累一到两个周期数据后，再回看权重是否与实际交付感受一致，调整时记录修订版本，避免不同周期的数据直接比较。
降范围时移出的模块，到底算本期未兑现还是下期新承诺？
两种处理都可行，关键是二选一并保持稳定。转为下期新承诺单元登记，意味着本期只对保留范围判定兑现，移出项在下期重新计入分母；不计入本期，则移出项从统计中退出，本期分母相应缩小。需要避免的是移出项既不在本期判定、也不在下期登记，这会形成统计盲区，让兑现率看起来比实际更好。规则中应写明所选方式，并在变更记录表的移出项字段中标注去向。
团队变更太频繁，变更台账总是记不全，有什么办法保证数据完整？
数据完整性主要靠复核节奏而非事后追责。可以按迭代或按月由项目经理或效能接口人对照承诺台账逐项核对，输出差异清单，逐条补录或确认无需变更。紧急变更允许先执行后补录，但要明确补录时限和责任人，例如发起人在变更执行后两个工作日内补录，下次复核时检查完成情况。当承诺单元、变更记录与交付状态分散在多个文档中时，维护成本会随变更频率上升，把台账与工作项放在同一处维护、按承诺时点筛选取数，能减少对不上的情况。
兑现率低但变更次数也少，说明什么？
这种情况通常指向承诺时点的评估偏差，而非执行过程失控。单元在承诺时对范围、日期或依赖的判断过于乐观，执行中又没有及时发起变更，最终直接以未交付收场。改进方向是校准承诺前的评估：回看这些单元的估算依据、依赖识别和风险判断，在下次承诺评审中增加对应检查。与之相对，兑现率高但变更次数多，说明计划稳定性不足，改进方向是变更原因分类的复盘。两个指标一起看，才能定位到具体环节。
试运行期间可以调整折算权重或变更分类吗？
建议试运行期间保持口径不变，先积累一到两个周期的数据。中途调整权重或分类会让周期之间的数据失去可比性，也难以判断问题出在规则还是执行。试运行结束后再集中评估：折算权重是否合理、变更原因分类是否够用、移出项处理方式是否产生盲区。评估结论形成修订记录，注明生效周期，后续统计按新版本执行，历史数据保留原口径。
