研发计划达成报告围绕“计划承诺—实际结果—偏差原因—改进动作”四段闭环编写：先固定统计口径，再计算计划达成率、按期交付率等指标，逐条归因并落到责任人与改进项，最后附上期改进项的关闭情况。报告的价值在于让计划可靠性可被度量、可被复核，避免变成任务清单的堆叠。以下按编写顺序展开结构、指标、归因、角色节奏与发布前检查。
要点总览（TL;DR）
- 先固定统计口径：纳入范围、完成判定、时间窗口、计划基线四项写成说明表随报告发布，后续每期沿用，变更需标注影响。
- 指标层用计划达成率与按期交付率并列呈现，辅以承诺变更次数与延期天数分布，并注明样本量小、口径变更时的可比性限制。
- 每条偏差按统一分类归因，写清事实、证据与影响范围，改进项必须包含责任人、动作、完成时点与验证方式，并回顾上期关闭情况。
- 明确编写者、数据提供者、评审者、决策者的职责，按数据收集、初稿、评审、发布四个节点固定节奏，评审会只处理判断与决策。
- 发布前用检查清单核对口径一致性、数据可回溯、归因完整、改进项可验证、决策事项到人，任一项不通过即退回修改。
报告先定口径：统计范围、完成判定与时间窗口
同一份计划数据，在不同周期、不同团队手里算出不同结论，多数时候问题出在口径而非数据本身。编写前先把口径写成一页说明表，随报告一起发布，后续每期沿用；确需调整时在报告中标注变更点与影响范围。
口径说明表至少覆盖四类字段：统计对象范围、完成判定标准、时间窗口、计划基线。填写时给出定义与取值示例，让数据提供者按同一规则取数。
| 字段 | 定义 | 取值示例 |
|---|---|---|
| 统计对象范围 | 纳入本期报告的计划项、团队或项目清单，以及排除项及理由 | 纳入A、B两个项目组的全部已承诺需求项；实验性预研项不计入 |
| 完成判定标准 | 状态定义、验收条件、关闭时点三者合一才算完成 | 状态为“已完成”且通过验收、在统计周期内关闭 |
| 时间窗口 | 统计周期起止日期，跨周期项的归属规则 | 每月1日至月末；跨周期项计入承诺完成所在周期 |
| 计划基线 | 作为承诺基准的计划版本及冻结时点 | 以月初评审通过的版本为基线，月中新增项单独标注 |
完成判定最容易产生分歧。建议把“状态变更”“验收通过”“正式关闭”三个动作分开记录，报告只认三者都满足的项；只改状态未验收的，计入“进行中”而非“完成”。跨周期项的归属规则要提前约定：按承诺完成周期归属，还是按实际关闭周期归属，两种算法得出的达成率不同，选定一种并保持稳定。
计划基线决定了“承诺”的含义。以哪一版计划作为基准，直接决定达成率的分母。基线冻结后新增的计划项，应单列为“基线外新增”，避免用不断调整的计划稀释偏差。
核心指标与计算方式：把计划可靠性量化
报告主体用少量指标回答“计划是否可信”，而不是把所有任务状态搬进表格。建议固定四个指标：计划达成率、按期交付率、承诺变更次数、偏差分布。每个指标写清公式、数据来源和解读边界，形成指标定义表。
| 指标 | 计算方式 | 数据来源 | 解读注意 |
|---|---|---|---|
| 计划达成率 | 周期内完成项数 ÷ 计划项数 | 基线计划项清单、完成判定记录 | 反映完成广度，不反映时间是否守约 |
| 按期交付率 | 按期完成项数 ÷ 应完成项数 | 承诺完成日期、实际关闭日期 | 反映时间守约程度，与达成率配合看 |
| 承诺变更次数 | 周期内计划项的范围、时间、内容变更次数，按原因分类 | 计划变更记录 | 次数多说明计划稳定性弱，需结合原因看 |
| 偏差分布 | 延期天数分布、未完成项占比 | 计划与实际日期对比 | 看集中区间，避免只看平均值 |
计划达成率与按期交付率回答两个不同问题：前者看“做完没有”，后者看“按时做完没有”。一个团队达成率很高但按期交付率低，说明计划排期偏乐观；反之则可能存在为保时间而缩减范围的情况。两个指标并列呈现，才能判断计划可靠性的真实水平。
承诺变更要分类记录原因，例如需求方调整、技术方案变化、资源调配、优先级重排。变更次数本身不是问题，未记录的变更才是。偏差分布建议用区间呈现，如延期1–3天、4–7天、7天以上各多少项，比单一平均延期天数更能暴露问题集中在哪里。
指标解读有三条限制需要写明：样本量小的周期（如计划项不足十项）比率波动大，宜看趋势而非单期数值；口径发生变更的周期，需注明与上期不可直接比较；指标只描述结果，原因解释放在归因章节，避免在同一张表里混入判断。
这些指标依赖稳定的计划基线与可追溯的状态记录。在ONES中，计划项以工作项形式承载，状态流转与变更记录随工作项留存，报告取数时可回溯到具体条目，减少手工汇总带来的口径漂移。
偏差归因与改进项：从数据到可执行动作
指标呈现的是结果，归因章节要回答“为什么”和“接下来做什么”。做法是：对每一项未完成或延期的计划项，用统一分类框架归因，写清事实、证据与影响范围，再转化为带责任人和完成时点的改进项。
原因分类建议固定五类，便于跨期统计：需求变更、估算偏差、资源冲突、依赖阻塞、外部因素。分类不宜过细，过细会导致同一原因被拆散；也不宜过粗，否则无法指导动作。每条偏差的归因写法遵循三段：事实（发生了什么）、证据（变更记录、阻塞记录、评审结论）、影响范围（影响了哪些计划项、延期多少天）。
| 偏差项 | 原因分类 | 事实与证据 | 影响范围 | 改进项 | 责任人 | 完成时点 | 验证方式 |
|---|---|---|---|---|---|---|---|
| 示例：接口联调延期5天 | 依赖阻塞 | 上游系统接口交付晚于约定日期，有对接记录 | 影响2个计划项，合计延期5天 | 联调前增加接口就绪检查点 | 项目负责人 | 下月计划评审前 | 下期联调按新检查点执行且无同类阻塞 |
改进项要可跟踪、可验证，避免写成“加强沟通”“提升估算准确性”这类无法判断是否完成的话。每条改进项包含四个要素：责任人、具体动作、完成时点、验证方式。验证方式最好能在下一期报告中直接核对，例如“下期同类偏差不超过一项”“检查点记录齐全”。
报告末尾设一节回顾上期改进项的关闭情况：已关闭的写明验证结果，未关闭的说明原因并顺延。这一节让报告形成闭环，也防止改进项在跨期流转中丢失。
角色分工与评审节奏：谁写、谁审、何时发
报告能否按期产出、结论能否被采纳，取决于角色边界和节奏是否清晰。建议区分四类角色：编写者、数据提供者、评审者、决策者，各自职责与交付物写入职责表。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 编写者 | 汇总数据、按口径计算指标、撰写归因与改进项 | 报告初稿 |
| 数据提供者 | 按口径提供计划项、完成状态、变更与阻塞记录 | 原始数据与来源说明 |
| 评审者 | 核对口径一致性、抽查数据可回溯性、审阅归因是否成立 | 评审意见 |
| 决策者 | 确认需决策事项、批准改进项与资源安排 | 决策结论 |
节奏上按周期固定四个节点：数据收集截止、初稿完成、评审会、定稿发布。以月度报告为例，可在月末后两个工作日内完成数据收集，第三个工作日出初稿，第四个工作日评审，第五个工作日发布。节点写入报告日历，提前告知各角色。
评审会聚焦三类事项：口径是否有变更及是否已说明、指标异常项的原因是否成立、需决策事项如何定。评审会不做数据重算，数据核对在会前完成，会上只处理判断与决策。报告定稿后归档，保留版本号与口径版本，便于后续追溯与跨期比较。
示例：一份月度研发计划达成报告骨架
以下骨架可直接套用，括号内为填写提示。示例数据为演示情景，实际编写时替换为本期真实数据。
一、报告头部。周期：2024年5月1日–5月31日；范围：A、B两个项目组已承诺需求项；口径版本：v2（较上期新增跨周期项归属规则，已标注影响）。
二、结果概览。计划项32项，完成27项，计划达成率84%；应完成30项，按期完成24项，按期交付率80%；承诺变更4次，其中需求方调整2次、资源调配1次、技术方案变化1次；延期项中延期1–3天3项、4–7天2项、7天以上1项。
三、偏差明细与归因。逐项列出未完成与延期项，按五类原因归因，附事实、证据与影响范围。示例：接口联调延期5天，归因依赖阻塞，上游接口交付晚于约定日期，影响2个计划项。
四、改进项与上期关闭情况。本期新增改进项3条，均含责任人、动作、完成时点与验证方式；上期改进项5条，关闭4条并写明验证结果，1条因资源未到位顺延，说明原因。
五、结论与需决策事项。结论用两三句话概括本期计划可靠性水平与主要问题；需决策事项逐条列出，明确到人，例如“是否调整下月B项目组的承诺范围，由项目负责人于评审会确认”。
骨架的衔接逻辑是：头部定口径，概览给结果，明细解释结果，改进项指向下一期，决策事项交给评审会。各章节篇幅按问题严重程度分配，偏差多的周期归因章节可适当展开，平稳周期则压缩。
完成检查：发布前逐项核对
发布前用一张检查清单逐项核对，任一项不通过则退回修改。检查项与通过标准如下，负责人按角色分工填写。
| 检查项 | 通过标准 | 负责人 |
|---|---|---|
| 口径一致性 | 与上期口径一致；如有变更，已说明变更内容与影响范围 | 编写者 |
| 数据可回溯 | 每个指标数值能对应到来源记录，抽查无差异 | 数据提供者 |
| 偏差归因完整 | 每条未完成或延期项均有原因分类、事实与证据 | 编写者 |
| 改进项可验证 | 每条改进项有责任人、动作、完成时点与验证方式 | 编写者 |
| 上期改进项回顾 | 上期改进项逐条说明关闭或顺延，未关闭有原因 | 编写者 |
| 决策事项明确 | 需决策事项逐条列出并明确到人 | 评审者 |
清单之外还有两条判断标准：报告结论能否用指标和归因支撑，不出现无依据的判断；下一期读者能否仅凭本期报告复现同样的计算。两条都满足，报告才算合格。报告归档时保留版本号与口径版本，为后续跨期比较留下可追溯的记录。
常见问题
计划项在统计周期内改了状态但还没验收，算完成吗？
按本文建议的完成判定口径，不算完成。完成需要同时满足三个条件：状态为已完成、通过验收、在统计周期内正式关闭。只改状态未验收的项应计入“进行中”，并在偏差明细中说明当前所处环节。
如果团队希望把“已提测待验收”单独统计，可以在口径说明表中增加一个中间状态，但该状态不计入计划达成率的分子，避免完成口径被放宽后跨期不可比。
月中新增的计划项要不要计入本期达成率？
建议不计入基线达成率，单列为“基线外新增”。计划基线在月初冻结，达成率的分母以冻结版本为准；月中新增项如果直接进分母，会稀释原有承诺项的偏差，让达成率看起来更平稳。
新增项可以单独统计数量和完成情况，作为计划稳定性的辅助观察。若新增项数量持续偏高，说明计划编制阶段的覆盖度不足，应在归因章节中作为承诺变更的一类原因记录。
计划项不足十项的周期，指标还有参考价值吗？
单期比率波动会比较大，一项未完成就可能让达成率下降十多个百分点。这种情况下建议看连续三到六期的趋势，而不是用单期数值下结论。
报告里可以同时列出绝对数（完成几项、延期几项）和比率，让读者自行判断。若团队长期计划项都很少，也可以考虑把统计周期从月度拉长到季度，让样本量更有代表性，但周期调整需在口径说明表中注明并保持稳定。
评审会上发现数据对不上，应该当场重算吗？
不建议在会上重算。评审会的时间应留给口径确认、异常原因判断和决策事项，数据核对在会前由数据提供者和编写者完成。
如果会上发现数据疑问，记录为待核事项，明确核对责任人和补充时点，会后核实并在报告修订版中说明。若疑问影响结论，可推迟定稿发布，但需在报告日历中同步调整后续节点，避免压缩评审和决策的时间。
上期改进项一直没关闭，报告里怎么处理？
逐条说明未关闭的原因并顺延，同时写明新的完成时点和责任人。连续多期未关闭的改进项，需要在评审会上作为需决策事项提出，判断是资源不足、动作设计不合理，还是问题本身已不再重要。
如果确认不再需要，应正式关闭并说明理由，而不是让它一直挂在报告里。改进项列表长期只增不减，会让读者失去对跟踪机制的信任。
