研发计划达成统计里，“计划达成”和“承诺达成”回答的是两个不同的问题：计划达成看团队是否兑现了最初排定的计划，承诺达成看团队是否守住了已经对外承诺的交付范围。两者都用于衡量计划可靠性，但基准对象、变更处理方式和责任视角不同。本文按定义、边界、计算机制、适用场景和常见误解逐层说明，帮助在统计和解读时选对口径。
要点总览（TL;DR）
- 计划达成以初始排定的计划基线为基准，衡量计划内工作按原定范围和时间完成的比例，偏差指向排期质量与估算能力。
- 承诺达成以对外确认的承诺清单为基准，衡量承诺内容被兑现的比例，偏差指向对外交付的可信度。
- 区分两个口径的关键在基准对象、变更处理和责任视角：计划变更可剔除或计入，承诺变更保留原承诺记录并单独说明。
- 评估排期质量、复盘计划偏差看计划达成；评估对外交付可信度、跨团队依赖兑现看承诺达成；两者并用时先看承诺达成再看计划达成。
- 两个口径都属于计划可靠性度量，单次迭代执行归迭代管理，工时偏差归计划与实际投入分析，不宜互相替代解释。
一句话区分：计划达成与承诺达成各看什么
计划达成以初始排定的计划为基准，衡量计划内的工作有多少按原定范围和时间完成。它关心的是“当初排的计划兑现了多少”，偏差指向排期质量、估算能力和计划稳定性。
承诺达成以已经对外承诺的交付范围为基准，衡量承诺清单中的内容有多少被兑现。承诺对象可以是业务方、上下游依赖团队，也可以是某个发布节点。它关心的是“答应别人的事做到了多少”，偏差指向对外交付的可信度。
两者的核心差异可以归纳为三点：
| 对比维度 | 计划达成 | 承诺达成 |
|---|---|---|
| 基准对象 | 初始排定的计划基线 | 对外承诺的交付范围 |
| 变更处理 | 需明确变更剔除还是计入，通常保留原基线用于复盘 | 承诺一旦锁定，范围调整需走承诺变更，原承诺仍计入兑现判断 |
| 责任视角 | 计划负责人对排期质量负责 | 承诺方对对外交付可信度负责 |
一句话判断规则：想知道“排得准不准”，看计划达成；想知道“答应的事靠不靠谱”，看承诺达成。
定义与边界：两个口径各自统计什么、不统计什么
计划达成的统计范围是计划基线内的工作项完成情况。统计前需要先确定三件事：计划基线在什么时点锁定、完成判定以什么状态为准、计划变更如何处理。变更处理有两种常见做法：一是把变更后的范围从分母中剔除，只统计原计划内未变更的部分；二是保留原基线，把新增和删减都作为偏差记录。两种做法得出的数值不同，统计口径必须事先写明。
承诺达成的统计范围是承诺清单内的交付内容。统计前需要确定承诺对象、承诺时点和承诺范围的锁定方式。承诺时点通常是向对方正式确认交付内容的时间，此后范围调整应作为承诺变更单独记录，原承诺仍纳入兑现判断。承诺清单一般小于或等于计划范围，只包含明确对外确认的部分。
两个口径都不覆盖以下内容：
- 单次迭代内的执行过程，包括任务拆分、每日进展和阻塞处理，归迭代管理；
- 计划投入与实际投入的工时偏差，归计划与实际投入分析；
- 需求从提出到交付的周期长度，归需求交付周期度量。
从度量性质看，计划达成和承诺达成属于计划可靠性度量，回答“兑现比例”问题；执行效率度量回答“做得快不快、顺不顺”的问题。两类指标可以并列展示，但不宜互相替代解释。
机制与组成：达成率是怎么算出来的
两个口径的计算框架相似，都是“已兑现数量除以基准数量”，但基准的构成不同，导致同一批数据可能得出不同结果。
| 计算要素 | 计划达成 | 承诺达成 |
|---|---|---|
| 基准来源 | 初始排定的计划基线 | 对外确认的承诺清单 |
| 基准锁定时间 | 计划评审通过或排期确认时 | 向承诺对象正式确认交付内容时 |
| 完成判定 | 工作项达到约定的完成状态 | 承诺清单内条目达到约定的交付标准 |
| 变更处理 | 按事先约定剔除或计入偏差 | 范围调整走承诺变更，原承诺仍计入判断 |
| 统计对象 | 团队、项目或版本均可，需固定口径 | 通常按承诺对象或发布节点统计 |
统计周期和统计对象的选择会直接影响结果。按版本统计时，跨版本的工作项归属需要事先约定；按团队统计时，共享工作项是否重复计入需要明确规则。统计对象一旦变化，历史数据不宜直接比较。
同一批工作项在两个口径下结果不同的典型原因有三类：一是基准范围不同，承诺清单通常只包含对外确认的部分，比计划范围小；二是变更处理不同，计划变更可能被剔除，承诺变更则保留原承诺记录；三是完成判定标准不同，计划达成可能以内部完成状态为准，承诺达成以对外交付标准为准。
在统计口径落地时，需要把计划基线、工作项完成状态和统计视图放在同一套数据里管理。ONES 支持以工作项状态和版本范围组织统计视图，团队可以在其中固定计划基线时点、记录变更，并按项目或版本查看达成情况；具体能力以实际产品资料为准。这样做的目的是让两个口径共用一份数据源，减少手工对账带来的口径漂移。
适用判断对象：什么情况下看计划达成，什么情况下看承诺达成
选择口径的依据是管理目的，而不是数据是否容易获取。
看计划达成的典型场景包括：评估某个团队的排期质量，复盘计划偏差集中在哪些环节，改进估算方法，判断计划变更频率是否过高。这类场景的关注点是内部计划管理能力，数据使用者通常是计划负责人和研发管理者。
看承诺达成的典型场景包括：评估对外交付的可信度，检查跨团队依赖是否按时兑现，保障发布节点的交付内容，向业务方说明交付稳定性。这类场景的关注点是对外承诺的兑现情况，数据使用者通常是承诺方、需求方和上下游协作团队。
同时使用两个口径时，常见的解读方式是先看承诺达成，确认对外交付是否守住；再看计划达成，判断内部排期是否稳定。如果承诺达成高而计划达成低，说明团队通过频繁调整计划保住了对外承诺，排期质量本身需要改进；如果计划达成高而承诺达成低，说明计划内完成的工作与对外承诺的范围存在错位，承诺清单的准确性需要检查。
按角色区分，计划负责人更关注计划达成及其偏差原因；承诺方更关注承诺达成和承诺变更记录；需求方更关注承诺达成，并需要了解承诺范围是否发生过调整。三个角色看同一组数据时，应先对齐口径定义，再讨论数值高低。
相邻概念区别：与迭代执行、工时偏差的界线
计划达成和承诺达成容易与三类相邻度量混淆，混用会导致误读。
| 相邻概念 | 关注点 | 与达成率的区别 |
|---|---|---|
| 迭代执行度量 | 单次迭代内的完成情况、任务流转和阻塞处理 | 迭代执行看过程是否顺畅，达成率看基准是否兑现；单次迭代结果不足以推断整体计划可靠性 |
| 计划与实际投入分析 | 计划工时与实际工时的偏差 | 工时偏差反映资源投入效率，不直接反映计划或承诺的兑现比例 |
| 需求交付周期 | 需求从提出到交付的时间跨度 | 周期关注时间长短，达成率关注兑现比例，两者可以同时改善也可以背离 |
混用的典型风险是：用迭代完成率代替计划达成，忽略跨迭代的计划偏差；用工时偏差解释承诺未兑现，掩盖承诺范围管理的问题；用交付周期缩短推断计划可靠性提升，而实际达成率并未变化。区分这些概念的关键是回到每个指标回答的问题本身。
具体例子与常见误解
以下示例为演示情景，用于说明两个口径的差异，不代表任何真实团队数据。
某版本初始计划包含 20 个工作项。计划评审后，团队向业务方承诺其中 12 个工作项在发布节点前交付。执行过程中，业务方新增 4 个工作项，团队同意纳入计划，其中 2 个纳入承诺清单；同时有 1 个原承诺工作项因依赖未就绪被移出承诺清单，作为承诺变更记录。版本结束时，原计划 20 项中完成 16 项，新增 4 项中完成 3 项；承诺清单原 12 项中完成 10 项，新增承诺 2 项中完成 1 项，移出的 1 项按承诺变更处理。
按“变更剔除、只统计原基线”的口径，计划达成为 16÷20＝80%；按“变更计入”的口径，计划达成为（16＋3）÷（20＋4）＝79.2%。承诺达成按原承诺加新增承诺计算，兑现比例为（10＋1）÷（12＋2）≈78.6%；若把移出的 1 项仍计入原承诺，则为 11÷14≈78.6% 不变，但承诺变更记录需要单独说明。这个例子说明：同一版本的数据，因变更处理规则不同，计划达成会出现两个数值；承诺达成则取决于承诺清单如何锁定和变更。
常见误解及纠正：
- 误解一：把承诺达成等同于计划达成。纠正：两者基准不同，承诺清单通常小于计划范围，数值接近只是巧合，不能互相替代。
- 误解二：计划变更后仍按原基线统计而不说明口径。纠正：无论剔除还是计入，都应在统计说明中写明规则，否则历史数据无法比较。
- 误解三：用单次迭代结果推断整体计划可靠性。纠正：单次迭代受偶发因素影响大，计划可靠性应看多个周期、固定统计对象下的趋势。
把两个口径的定义、基准时点、变更规则和统计对象写进同一份统计说明，是避免混用的基础动作。统计说明应与数据同步更新，口径调整时保留历史记录，后续解读才有共同参照。
常见问题
计划变更频繁时，计划达成应该剔除变更还是保留原基线？
两种做法都可用，关键是事先写明并在多个统计周期内保持一致。剔除变更适合评估原计划内工作的兑现能力，保留原基线适合观察计划偏差的整体规模。若中途切换规则，历史数据不宜直接比较，应在统计说明中标注切换时点和原因。
承诺达成中的承诺清单应该在什么时点锁定？
通常在向承诺对象正式确认交付内容时锁定，例如与业务方确认版本范围、与上下游团队确认依赖交付时间、或发布节点评审通过时。锁定后范围调整应作为承诺变更单独记录，原承诺仍纳入兑现判断。承诺时点没有统一行业标准，由组织在统计说明中约定。
承诺达成高但计划达成低，说明团队管理得好还是不好？
这种组合通常说明团队通过频繁调整计划保住了对外承诺，对外交付可信度尚可，但内部排期稳定性需要改进。解读时应结合计划变更频率和变更原因，判断是估算偏差、需求波动还是资源不足导致，再决定改进方向。
两个口径能否用同一份数据直接计算？
可以共用一份工作项数据源，但需要分别固定基准：计划达成锁定计划基线时点，承诺达成锁定承诺清单和承诺时点。共用数据源能减少手工对账，前提是变更记录完整、完成判定标准在两个口径下分别写明。ONES 支持以工作项状态和版本范围组织统计视图，具体能力以实际产品资料为准。
按团队统计和按版本统计，达成率结果会差很多吗？
会有差异。按版本统计时，跨版本工作项的归属需要事先约定；按团队统计时，共享工作项是否重复计入需要明确规则。统计对象一旦变化，历史数据不宜直接比较，建议固定统计对象后再观察趋势。
