研发承诺兑现率长期偏低，通常说明承诺形成时缺少可核对的容量依据，执行中又缺少偏差预警，最后只能靠事后缩小范围把数字做上去。改进分三层：承诺评审固定“谁承诺、依据什么容量、范围边界在哪”；容量校准用历史投入修正承诺口径；过程预警让偏差在承诺期内暴露。下文给出基线表、评审清单、校准表、预警检查表和验证口径，并说明前提与代价。
要点总览（TL;DR）
- 先按统一口径量出基线：以承诺评审通过、范围冻结为承诺起点，按项数或点数计算兑现率，并按团队、迭代拆开，连续三个及以上迭代低于同一区间才视为长期偏低。
- 承诺评审要留下可复核的输入：评审前提交事项、预估、依赖与验收口径，评审中核对容量余量与依赖状态，评审后明确范围边界与变更规则，未确认依赖的事项不进入承诺。
- 容量校准用历史数据反推可用容量：统计实际投入与名义人力的折算系数，把会议、支持、缺陷、休假等非计划工作显性化为扣减项，按角色分别校准后回写为下一轮承诺上限。
- 执行中在迭代中段设检查点，对比已完成量、剩余承诺量与剩余容量，触发预警后按调整范围、补充资源或拆分交付处置，并保留变更时点与原因。
- 验证时四项指标一起看：兑现率、承诺偏差幅度、变更时点分布、承诺量变化；只有兑现率上升而变更集中在结算前，通常是口径美化而非真实改善。
当前做法与目标：先量出兑现率偏低的真实基线
改进之前先要把“偏低”变成可核对的数字。兑现率的基本口径是：在承诺时点被列入承诺范围的事项，到迭代结束时按原范围完成的比例。按项数计算时，兑现率＝按期完成承诺项数÷承诺项总数；按故事点计算时，用同一批承诺项的预估点数作分子分母。两种口径不能混用，选定一种后至少连续观察若干迭代再作判断。
承诺时点的界定直接决定口径是否可信。建议以承诺评审通过、范围冻结的那一刻作为承诺起点，此后新增的事项不计入本期承诺分母，移出的事项仍保留在分母中并标注变更时点。这样分母稳定，兑现率才反映真实的交付能力，而不是范围反复调整后的结果。
基线要按团队和迭代两个维度拆开看。把所有团队汇总成一个数字，容易掩盖个别团队的长期偏低；只看单个迭代，又容易把偶发波动当成结构性问题。判断标准可以这样设：连续三个及以上迭代低于同一区间，视为长期偏低；单次跌破但前后正常，按波动处理，先记录不启动大改。
改进目标同样要写成可对照的指标，而不是“提高兑现率”这样的方向性表述。建议同时设定三项：兑现率进入一个稳定区间并保持若干迭代；承诺偏差幅度（实际完成量与承诺量的差值占比）收窄；变更发生时点整体前移，即范围调整更多发生在迭代中段而非结算前。
需要提前明确一条禁止项：不得在结算前临时缩小承诺范围来抬高指标。判断方法是核对变更记录——如果范围缩减集中发生在迭代最后几天，即使兑现率数字上升，也应视为口径美化而非改善。
现状基线表可按以下字段建立，示例数字为演示假设，不代表任何团队的实测水平：
| 迭代 | 承诺项数 | 承诺点数 | 按期完成项数 | 兑现率（按项） | 结算前缩范围项数 | 变更时点分布 |
|---|---|---|---|---|---|---|
| 迭代1 | 24 | 86 | 17 | 71% | 4 | 末3天集中 |
| 迭代2 | 26 | 92 | 18 | 69% | 5 | 末3天集中 |
| 迭代3 | 23 | 80 | 17 | 74% | 3 | 中段1、末段2 |
瓶颈与误区：承诺为什么长期兑现不了
兑现率偏低的原因通常集中在三类环节，先把本团队的情况归到具体环节，后面的改进动作才有针对性。
容量失真。最常见的情况是按名义人力估算容量：团队8人，就按8人×迭代天数计算可投入工时，没有扣除会议、线上支持、缺陷处理、休假和在途未完成事项。名义容量与实际可用容量之间往往有明显差距，承诺量按名义容量定，兑现率自然长期偏低。
承诺评审形式化。评审会开成了排期确认会：事项列出来、时间对一遍就通过，缺少范围边界说明，也缺少依赖状态确认。依赖方尚未给出交付时间的事项照样进入承诺，等到执行中才发现被阻塞。这类问题的特征是承诺清单本身信息不全，事后无法复核当初依据了什么。
过程失察。迭代进行中没有人对比已完成量、剩余量与剩余容量，偏差要到结算时才暴露。此时只剩两个选择：延期或缩范围，而缩范围又会让下一轮承诺继续虚高，形成循环。
与之相伴的是一个典型误区：把事后调整范围当成改进手段。范围一缩，兑现率数字好看了，但承诺形成时的容量判断没有变，下一轮仍会重复同样的偏差，可预测性并未提升。判断是否落入这个误区，看变更记录的时间分布即可。
把上述原因整理成归类清单，逐条标注本团队是否存在、证据是什么、影响哪个环节，可以作为启动改进的输入：
- 容量按名义人力估算，未扣除非计划工作——对应容量校准动作
- 承诺清单缺少依赖与验收口径——对应承诺评审动作
- 迭代中段无偏差检查——对应偏差预警动作
- 变更集中在结算前——对应变更规则与验证口径
优先改进动作一：把承诺评审做成可复核的输入
承诺评审的目标是让每一次承诺都留下可核对的依据：承诺了什么、依据多少容量、边界在哪、谁负责。评审前、评审中、评审后三个环节各有明确产物。
评审前，由事项负责人提交承诺清单，每项至少包含：事项描述、预估（项数或点数，与兑现率口径一致）、外部依赖及其当前状态、验收口径。清单不完整的事项不进入评审议程，避免会上临时补信息导致判断草率。
评审中做两件事。第一，核对容量余量：把清单总预估与本期可用容量上限对比（上限来自下一节的容量校准结果），超出部分当场决定移出或拆分。第二，核对依赖状态：依赖方未确认交付时间的事项不进入承诺，可放入候选池，待依赖确认后在下一次评审补入。
评审后要明确范围边界与变更规则。边界包括本期承诺包含什么、明确不包含什么；变更规则包括哪些情况允许调整范围、由谁批准、必须记录哪些字段。变更记录至少保留：变更时点、变更类型（移出/新增/拆分）、原因、批准人。这份记录既是执行中的管理依据，也是事后核对兑现率口径的凭证。
评审输出统一留档，形成承诺评审记录，字段建议如下：
| 字段 | 填写要求 |
|---|---|
| 事项与负责人 | 一项一条，负责人唯一 |
| 预估 | 与兑现率口径一致，注明单位 |
| 依赖及状态 | 已确认/未确认，未确认不进入承诺 |
| 验收口径 | 可判定的完成标准 |
| 本期容量上限 | 引用容量校准结果 |
| 范围边界 | 包含项与明确排除项 |
| 变更记录 | 时点、类型、原因、批准人 |
这些记录如果散落在会议纪要和聊天记录里，事后核对成本很高。把承诺清单、评审结论和变更记录放在同一处工作项与文档中留痕，能让兑现率统计直接引用原始记录。ONES 可以在工作项和文档中承载承诺清单、评审记录与变更留痕这类管理动作，具体配置按团队现有流程设定。
优先改进动作二：用容量校准修正承诺口径
容量校准要回答一个问题：这个团队在一个迭代里，真正能用于承诺事项的投入是多少。做法是用历史数据反推，而不是继续用名义人力拍数。
第一步，统计历史迭代的实际可用投入。取近若干迭代的实际投入数据，与同期名义人力对比，得出折算系数：折算系数＝实际用于计划事项的投入÷名义人力投入。系数低于1的部分，就是被非计划工作占用的容量。
第二步，把非计划工作显性化为扣减项。会议、线上支持、缺陷处理、招聘面试、培训、休假，逐项统计历史占比。扣减项不必追求精确到小时，按迭代统计占比即可，重点是让扣减有数据来源而不是凭感觉。
第三步，按角色或团队分别校准。不同角色的非计划工作占比差异往往很大，用一个统一系数会掩盖差异：支持类角色扣减比例高，纯开发角色相对低。分别校准后，各角色得到自己的可用容量，承诺评审按角色容量上限核对。
第四步，把校准结果回写到下一轮承诺评审。容量上限＝名义人力×折算系数，或名义人力减去各项扣减后的余额。这个上限作为评审中的硬约束，超出即调整范围。校准结果建议每季度或每若干迭代复核一次，人员结构或业务节奏变化明显时提前复核。
容量校准表可按以下结构建立，示例数字为演示假设：
| 角色/团队 | 名义人力（人·迭代） | 会议与协作扣减 | 支持与缺陷扣减 | 休假与其他扣减 | 折算系数 | 可用容量 |
|---|---|---|---|---|---|---|
| 后端小组 | 5 | 0.5 | 0.8 | 0.2 | 0.70 | 3.5 |
| 前端小组 | 4 | 0.4 | 0.5 | 0.1 | 0.75 | 3.0 |
| 测试小组 | 3 | 0.3 | 0.9 | 0.1 | 0.57 | 1.7 |
校准过程中要注意一个倾向：为了让承诺更容易兑现而人为压低容量上限。判断方法是看承诺偏差幅度——如果兑现率很高但承诺量持续明显低于历史完成量，说明校准过度保守，应回调系数。
优先改进动作三：在承诺期内设置偏差预警
偏差预警的作用是把问题暴露在承诺期内，让调整发生在还有回旋余地的时候。核心动作是在迭代中段设置检查点，用同一口径对比三个数：已完成量、剩余承诺量、剩余可用容量。
检查点的判定规则建议提前写定，例如：剩余承诺量超过剩余可用容量一定比例时触发预警。阈值按团队历史偏差分布设定，不套用统一数字。触发预警后，处置选项有三类：
- 调整范围：移出部分事项，记录变更时点与原因，移出项保留在承诺分母中
- 补充资源：从其他团队借调或调整优先级，需评估对依赖方的影响
- 拆分交付：把大事项拆成可独立验收的部分，本期交付其中一部分并明确剩余部分的安排
每次处置都要留下记录：触发时点、偏差幅度、处置选项、批准人、对承诺范围的影响。这份记录与承诺评审记录使用同一套字段，保证兑现率统计时能按同一口径核对。
预警信号还要回流到承诺评审。如果某类事项反复在中段触发预警，说明评审时的预估或依赖判断存在系统性偏差，下一轮评审应调整该类事项的预估方法或提高依赖确认要求。这样评审、执行、复盘形成闭环，而不是每轮重新猜。
偏差预警检查表可按以下条目执行：
| 检查项 | 判定与动作 |
|---|---|
| 已完成量与计划对比 | 低于计划一定比例，记录并分析原因 |
| 剩余承诺量与剩余容量对比 | 超出即触发预警，进入处置流程 |
| 依赖状态复核 | 依赖未按期确认的，评估是否移出 |
| 处置记录 | 时点、选项、批准人、范围影响齐全 |
| 回流事项 | 标注需在下轮评审调整的预估或依赖要求 |
适用前提与代价：这套改进需要什么条件
这套改进能落地，前提是团队有可追溯的承诺记录和完成记录。如果历史数据缺失，第一步的基线就建不起来，容量校准也缺少输入，需要先补若干迭代的记录再启动。另一个前提是团队愿意暴露真实容量：如果成员担心报出低容量会影响评价，校准数据就会失真，改进随之失效。
代价要提前说清楚。承诺评审和容量校准会增加前期投入，评审会时间变长，每轮要做数据统计；改进初期承诺量可能下降，因为容量扣减后可用上限变低，短期看交付数字不如以前。这个下降是口径修正的结果，需要管理层的理解与配合，否则改进很容易在第一个季度就被叫停。
还有一个副作用需要防范：过度保守的承诺会让兑现率失去意义。如果团队把承诺量压到远低于实际能力，兑现率可以很高，但可预测性和产出都未改善。因此验证时必须同时看承诺偏差幅度和承诺量变化，不能只看兑现率一个数字。
这套方法也有不适用的情况。单次迭代的执行问题，比如某个事项因个别人员变动延期，属于具体异常排查，不需要启动整套评审与校准机制。计划与实际投入的工时偏差分析属于另一个分析主题，本篇不展开，需要时单独处理。
效果验证：怎么判断改进真的起作用
验证的关键是排除口径变化带来的假象。改进前后必须用同一口径对比：承诺分母的界定一致、兑现率计算方式一致、变更记录的字段一致。如果改进同时调整了口径，对比结果就无法归因。
对照指标建议四项一起看：兑现率是否进入目标区间并保持若干迭代；承诺偏差幅度是否收窄；变更时点分布是否整体前移，即中段调整占比上升、结算前集中缩范围减少；承诺量是否保持稳定或随容量校准合理变化。四项中兑现率单独上升而其余三项恶化，通常说明是口径美化。
验证周期上，建议至少覆盖改进前后的各若干迭代，样本太短容易把波动当趋势。对照方式采用同团队前后对比，若同时有未启动改进的团队，可作为参照观察整体环境变化的影响，但不把参照组差异直接当作因果证据。
数据来源要求：承诺清单、评审记录、变更记录、完成记录必须来自同一套留痕，统计时直接引用原始记录而非事后回忆。效果验证表可按以下结构建立，示例数字为演示假设：
| 指标 | 口径 | 对照周期 | 判定标准 |
|---|---|---|---|
| 兑现率 | 按期完成承诺项÷承诺项总数 | 改进前后各3个迭代 | 进入目标区间并保持 |
| 承诺偏差幅度 | |实际完成−承诺|÷承诺 | 同上 | 幅度收窄 |
| 变更时点分布 | 中段变更占比、结算前变更占比 | 同上 | 中段占比上升，结算前占比下降 |
| 承诺量 | 每迭代承诺项数或点数 | 同上 | 稳定或随校准合理变化，不持续走低 |
如果四项指标同向改善，可以判断改进起了作用；如果只有兑现率上升，先检查变更时点分布，确认是否存在结算前集中缩范围的情况，再决定是否继续推进或调整动作。
常见问题
承诺评审已经开了会，为什么兑现率还是上不去？
常见原因是评审停留在排期确认：事项列出来、时间对一遍就通过，没有核对容量余量，也没有确认依赖状态。这样的评审产不出可复核的依据，事后无法回答“当初凭什么承诺这么多”。
可以检查两点：评审前是否提交了含预估、依赖、验收口径的承诺清单；评审中是否把清单总预估与本期可用容量上限做了对比，超出部分当场移出或拆分。这两步缺失时，评审会开得再准时，承诺量仍按名义人力定，兑现率自然偏低。
容量校准的折算系数需要多精确？数据不全时怎么起步？
折算系数的作用是让承诺上限有数据来源，不要求精确到小时。按迭代统计占比即可：取近若干迭代的实际投入与名义人力对比，把会议、支持、缺陷、休假等扣减项逐项列出占比，得出系数。
历史数据不全时，先用现有记录做粗略估计并标注为估计值，同时从下一轮开始完整记录承诺清单与完成情况，积累若干迭代后替换估计值。关键是扣减项有来源、可复核，而不是凭感觉拍一个系数。
迭代中段发现偏差，调整范围会不会又变成事后缩范围？
区别在时点和记录。中段调整发生在承诺期内，此时还有补充资源或拆分交付的选择空间；结算前集中缩范围则是在结果已定后修改分母，属于口径美化。
操作上要保证两点：移出的事项仍保留在承诺分母中并标注变更时点，兑现率统计时按原范围核对；每次处置记录触发时点、偏差幅度、处置选项与批准人。验证阶段再看变更时点分布，中段变更占比上升、结算前占比下降，才说明调整机制在起作用。
团队担心报出真实容量会影响评价，校准数据失真怎么办？
这是这套改进能否落地的关键前提。如果成员认为低容量会被视为能力不足，报出的数据就会偏高，校准失去意义。
可行的做法是把容量数据与个人绩效评价脱钩，明确容量校准用于承诺口径修正，不用于排名；同时让管理层接受改进初期承诺量下降是口径修正的结果。评审记录中保留扣减项依据，让容量数字可解释、可讨论，而不是变成对个人的判断。
改进多久能判断是否有效，中间要不要调整动作？
建议至少覆盖改进前后各若干迭代再作判断，样本太短容易把波动当趋势。判断时四项指标一起看：兑现率是否进入目标区间并保持、承诺偏差幅度是否收窄、变更时点是否整体前移、承诺量是否稳定或随校准合理变化。
如果兑现率上升但承诺量持续明显走低，说明校准过度保守，应回调系数；如果某类事项反复在中段触发预警，说明评审时的预估或依赖判断有系统性偏差，下一轮评审要调整该类事项的预估方法。验证周期内允许按这些信号修正动作，但口径本身要保持一致，否则前后对比无法归因。
