研发计划达成报告的核心是度量计划可靠性：以计划冻结时承诺的计划项为分母，以按期完成项为分子，算出达成率，再对偏差按原因分类并说明下期承诺如何调整。本文给出一份可直接套用的填写示例，逐项解释字段取值与判断口径，并说明换团队、换周期时怎么改，以及哪些做法会让报告失真。
要点总览（TL;DR）
- 报告以计划冻结时承诺的计划项为分母、按期完成项为分子计算达成率，示例中 24 项承诺、18 项按期完成，达成率 75.0%。
- 完整示例包含基本信息、达成汇总、维度分解、偏差明细和结论五部分，数据前后自洽，可直接替换为团队自有数据。
- 关键口径有三条：冻结后新增项单列不进入分母；完成须同时满足不晚于承诺日期和达到完成定义；取消项的处理方式跨周期保持一致。
- 换周期或换团队时优先保住分母口径与完成定义，周期缩短后建议连续看三个周期的达成率趋势。
- 事后调整基线、把工时偏差混入达成率、用达成率单独评价个人绩效，是三种最常见的失真做法。
这份示例要解决什么问题
这份示例的目标很具体：展示一份研发计划达成报告填写完成后是什么样子，让第一次编制这类报告的人有一个可以照着改的底稿。它回答两个问题——团队在报告周期内对计划承诺的兑现程度如何，未兑现的部分分别是什么原因造成的。
示例覆盖报告的基本信息、达成汇总、维度分解、偏差明细和结论五个部分，数据前后自洽，可以直接替换成自己团队的数据使用。需要说明的是，文中所有团队名称、项目名称、日期和数字均为演示情景，用于说明填写方式，不代表任何真实客户案例，也不构成对某种管理成效的量化证明。
这份示例有明确的边界。单次迭代内部的执行过程，包括任务拆分、每日推进、迭代评审，属于迭代管理的范畴，本示例不展开。计划投入工时与实际投入工时的差异分析，属于计划与实际投入分析的主题，本示例只在偏差原因分类中提及，不给出工时口径的计算方法。工具的价格、版本与认证信息同样不在讨论范围内。
完整示例：某季度研发计划达成报告（演示情景）
以下为一份填写完成的报告范例。为便于阅读，报告拆为基本信息、达成汇总、维度分解、偏差明细和结论五块，实际使用时可以合并为一份文档。
报告基本信息
| 字段 | 填写内容（演示情景） |
|---|---|
| 报告周期 | 2025 年第二季度（4 月 1 日—6 月 30 日） |
| 统计范围 | 交易平台研发线，含订单、支付、履约三个项目组 |
| 计划版本 | Q2 计划 V1.2 |
| 计划冻结时间 | 2025 年 4 月 8 日 |
| 编制人 | 研发项目经理（演示） |
| 编制日期 | 2025 年 7 月 3 日 |
计划达成汇总
| 指标 | 数值 | 说明 |
|---|---|---|
| 冻结时承诺计划项数 | 24 | 分母，以 V1.2 冻结版本为准 |
| 按期完成数 | 18 | 分子，按完成定义判定 |
| 延期完成数 | 4 | 已完成但晚于原承诺日期 |
| 未完成数 | 1 | 周期结束时仍未达到完成定义 |
| 取消数 | 1 | 经变更评审后正式取消 |
| 计划达成率 | 75.0% | 18 ÷ 24 |
| 中途新增计划项 | 3 | 单列，不计入分母 |
按项目组分解
| 项目组 | 承诺项数 | 按期完成 | 延期 | 未完成 | 取消 | 达成率 |
|---|---|---|---|---|---|---|
| 订单组 | 9 | 7 | 1 | 1 | 0 | 77.8% |
| 支付组 | 8 | 6 | 2 | 0 | 0 | 75.0% |
| 履约组 | 7 | 5 | 1 | 0 | 1 | 71.4% |
偏差明细
| 计划项 | 原承诺日期 | 实际完成日期 | 偏差天数 | 偏差原因分类 |
|---|---|---|---|---|
| 订单批量导出优化 | 5 月 16 日 | 5 月 23 日 | +7 | 技术方案返工 |
| 支付渠道对账重构 | 6 月 6 日 | 6 月 18 日 | +12 | 外部依赖延迟 |
| 支付失败重试策略 | 6 月 13 日 | 6 月 20 日 | +7 | 需求澄清滞后 |
| 履约时效看板 | 6 月 20 日 | 6 月 27 日 | +7 | 资源被临时占用 |
| 订单状态机梳理 | 6 月 27 日 | 未完成 | — | 范围评估不足 |
| 履约异常件归档 | 6 月 30 日 | — | — | 经变更评审取消 |
结论与下期承诺调整
本季度计划达成率 75.0%，低于团队设定的 85% 目标线。四起延期中有两起与外部依赖和需求澄清相关，一起为技术方案返工，一起为资源临时占用；一项未完成源于范围评估不足。据此，下季度承诺做三项调整：涉及外部渠道对接的计划项，在承诺日期前预留不少于五个工作日的缓冲，并在计划中标注依赖方；需求澄清完成作为计划项进入开发的前置条件，未澄清的需求不进入承诺清单；单个计划项的评估工作量上限下调，超出部分拆分为多个计划项，降低单点评估偏差对整体达成率的影响。
逐项解释：每个字段为什么这样填
示例中的每个数字背后都有一条取值规则。规则先定、后填数，报告才具备跨周期可比性。下表列出关键字段的口径与判断依据。
| 字段 | 取值口径 | 判断依据与注意事项 |
|---|---|---|
| 分母（承诺计划项数） | 计划冻结时清单内的全部计划项 | 冻结时间点须写进报告；冻结后新增项单列，不进入分母，避免分母随执行过程漂移 |
| 分子（按期完成数） | 实际完成日期不晚于原承诺日期，且达到完成定义 | 完成定义须事先约定，例如通过验收评审或达到约定的交付状态；仅开发自测通过不计入完成 |
| 达成率 | 按期完成数 ÷ 承诺计划项数 | 保留一位小数即可；同时给出绝对数，避免小样本下百分比波动被过度解读 |
| 延期与未完成 | 分开统计 | 延期是已完成但超期，未完成是周期结束时仍未达到完成定义，两者对下期计划的影响不同 |
| 取消项 | 经变更评审后从承诺中移除 | 取消项保留在明细中并注明原因，从分母中扣除时须在报告中说明扣除方式 |
| 偏差原因分类 | 按可控性归类，如技术方案返工、外部依赖延迟、需求澄清滞后、资源占用、范围评估不足 | 分类数量控制在五到七类，过多会导致归类随意；每类应有明确归属示例 |
| 结论与调整 | 从偏差分类中归纳出可执行的承诺修正 | 每条调整对应一类主要偏差，写清下期怎么做，避免只写“加强管理” |
分母口径是整份报告最容易被稀释的地方。计划冻结后如果不断把新需求塞进原清单，达成率的分母就会变大，历史数据失去可比性。示例把中途新增的三项单列，正是为了让分母稳定在冻结版本上，同时又不掩盖新增工作量。
取消项的处理需要一次明确的选择。示例的做法是保留在明细中、从分母中扣除，并在汇总表注明扣除后的口径。另一种做法是保留在分母中按未达成计，两种都可以，关键是同一团队跨周期保持一致，并在报告里写清楚用的是哪一种。
结论段不是数据的复述，而是从偏差分类中推导出的承诺修正。示例中四类偏差对应三条调整，每条调整都能在下期计划中观察到是否执行，例如“外部依赖项预留缓冲”可以在下期计划项的日期安排上直接核对。
可迁移规律：换团队、换周期怎么改
示例的字段结构可以整体迁移，需要调整的是周期长度、分解粒度和计划项颗粒度。调整时优先保住分母口径和完成定义两条主线，其余字段可以按需增减。
- 周期从季度改为月度或双周：保留基本信息、达成汇总、偏差明细和结论四块，维度分解表在团队较少时可省略。周期缩短后计划项数量下降，达成率波动会放大，建议同时给出连续三个周期的达成率，观察趋势而非单期数值。
- 分解维度从项目改为小组：把“按项目组分解”换成“按小组分解”，列结构不变。若一个计划项由多个小组共同承担，指定一个主责小组计入其名下，避免重复计数。
- 计划项颗粒度：以能独立判定完成为准，通常对应一个可验收的交付物。颗粒度过粗会让单点偏差吞掉整期达成率，过细则报告变成任务清单，失去承诺管理的意义。示例中单个计划项的工作量控制在一到三周，可作为参考起点。
- 补充可靠性观察项：达成率之外可以增加承诺变更次数、平均偏差天数两项。承诺变更次数反映计划稳定性，平均偏差天数反映估算偏差的幅度，两者与达成率一起看，比单一百分比更能说明计划可靠性。
- 保持口径稳定：完成定义、分母口径、偏差分类在连续周期内不要随意改动。确需调整时，在新周期的报告中注明变更内容和生效时间，避免历史数据被误读。
报告依赖计划项、完成状态和偏差记录有稳定的管理载体。在 ONES 中，计划项可以对应到工作项，完成状态与验收节点随工作项流转记录，偏差原因可以作为字段沉淀在明细中，编制报告时按周期和项目维度汇总即可。具体到计划基线冻结、完成定义配置和达成率统计的实现方式，建议在选型或配置阶段结合实际流程确认。
适用边界与常见误用
这份示例成立的前提有两个：团队在周期开始时有明确的计划承诺并完成冻结，且“完成”有事先约定的判定标准。缺少任何一个前提，达成率都会变成事后解释的数字，失去度量计划可靠性的作用。
三种误用最常让报告失真。第一种是事后调整计划基线，把延期项的原承诺日期改到实际完成日期附近，达成率随之虚高；防范办法是冻结版本单独留存，报告引用冻结版本而非当前版本。第二种是把工时偏差混入达成率，例如用实际工时超出估算的比例去扣减达成率，这会让两个不同口径的指标互相污染，工时差异应放到投入分析中单独呈现。第三种是用达成率单独评价个人绩效，达成率受计划项难度、外部依赖和分工影响，作为团队计划可靠性的观察指标合适，直接挂钩个人考核会诱导保守承诺和拆分计划项。
探索型工作不适合套用这份报告。研究方向尚不明确、交付物难以事先定义的任务，缺少可冻结的计划承诺，强行计算达成率只会得到失真的数字，这类工作更适合用阶段性评审记录进展。此外，本示例与迭代执行报告、投入分析各有分工：迭代执行报告关注单次迭代内的推进与阻碍，投入分析关注计划与实际工时的差异，本报告只回答承诺兑现程度与偏差原因，三者配合使用才能完整反映研发管理状况。
常见问题
计划冻结之后又插入了紧急需求，达成率的分母要不要跟着改？
建议不改。分母固定为冻结版本中的承诺计划项，中途新增项在汇总表中单列，注明数量和来源。这样做的目的是让不同周期的达成率可以横向比较；如果分母随执行过程不断变大，历史数据就失去参照意义。新增项本身的工作量可以在偏差明细或结论段中说明，不必通过调整分母来体现。
一个计划项延期后拆分成了两个，完成情况怎么统计？
按原承诺项统计一次，不因拆分而增加分子或分母。拆分后的子项都达到完成定义，且最后一个子项的完成日期不晚于原承诺日期，才计为按期完成；否则计为延期，并在偏差明细中注明拆分情况。拆分属于执行过程中的调整，报告记录的是对原承诺的兑现结果。
团队第一次做这类报告，没有历史数据，达成率多少算正常？
首期报告的价值在于建立基线，不必急于和某个百分比比较。可以先连续做三个周期，观察达成率的波动幅度和偏差原因的分布，再据此设定目标线。示例中的 85% 目标线属于演示情景，实际目标应结合团队的计划项颗粒度、外部依赖比例和完成定义的严格程度来确定。
探索型或预研类工作能不能也放进这份报告？
可以放进统计范围，但建议单独分组，不与交付型计划项混算达成率。预研工作缺少可事先冻结的交付承诺，强行按日期判定完成会得到失真的数字。更合适的做法是为这类工作设置阶段性评审节点，在报告中以评审结论记录进展，达成率只覆盖有明确承诺的计划项。
报告里的偏差原因分类，各团队必须统一吗？
同一统计范围内应当统一，跨团队比较时更需要一致。分类数量控制在五到七类，每类给出明确的归属示例，避免同一原因在不同项目组被归到不同类别。分类可以随业务变化调整，但调整时要在报告中注明生效周期，并说明新旧分类的对应关系，防止趋势对比被口径变化干扰。
