研发计划达成报告用来回答一个周期内“承诺了什么、实际交付了什么、偏差出在哪里、下一步怎么纠偏”。这份模板资料提供一张可直接复制到文档或表格工具中的空白表，配套字段口径、必填规则和一份完整填写示例，适用于按迭代、按月或按季度出具达成报告的研发团队。下文表格、字段说明与示例使用同一套字段，报告流程在协作工具中的承载方式在最后一节说明，其中会自然提及ONES。
要点总览（TL;DR）
- 研发计划达成报告按周期记录承诺项、实际交付、偏差原因与纠偏动作，模板分为表头、计划明细、偏差与纠偏、汇总四个区域。
- 报告周期、报告人、覆盖团队/项目、统计口径、计划项、承诺完成时间、达成状态为必填；未达成或延期达成时，偏差原因、偏差说明、纠偏动作、责任人、预计完成时间转为条件必填。
- 偏差天数按实际完成时间与承诺完成时间的自然日差计算，未完成项按报告截止日计算并标注；达成率可选按计划项计数或按工作量加权，选定一种并在统计口径栏注明。
- 填写示例演示了 5 个计划项、40% 达成率的完整计算过程，偏差原因分类需结合卡点归属判断，避免随意归类。
- 模板调整以保持跨周期可比为原则，字段增减、分类调整和达成率口径变更都需留下版本记录，历史报告不回溯重算。
可复制空白模板：研发计划达成报告表
模板分为四个区域：表头信息区、计划明细区、偏差与纠偏区、汇总区。复制时保留四个区域，按团队实际情况增删行，字段名称保持一致，便于跨周期和跨团队汇总。
表头信息区
| 字段 | 填写内容 |
|---|---|
| 报告周期 | （起止日期，如 2025-04-01 至 2025-04-30） |
| 报告人 | （姓名/角色） |
| 覆盖团队/项目 | （团队名称或项目名称） |
| 统计口径 | （按计划项计数 / 按工作量加权；计划项纳入范围说明） |
| 报告日期 | （出具日期） |
计划明细区
| 序号 | 计划项 | 承诺完成时间 | 实际完成时间 | 达成状态 | 偏差天数 |
|---|---|---|---|---|---|
| 1 | |||||
| 2 | |||||
| 3 |
偏差与纠偏区
| 序号 | 对应计划项 | 偏差原因分类 | 偏差说明 | 纠偏动作 | 责任人 | 预计完成时间 |
|---|---|---|---|---|---|---|
| 1 | ||||||
| 2 |
汇总区
| 汇总项 | 数值 |
|---|---|
| 计划项总数 | |
| 按期达成数 | |
| 达成率 | |
| 主要偏差类型 | |
| 下周期重点纠偏事项 |
字段说明：每个字段记录什么、怎么填
字段口径决定报告能否横向比较。同一团队连续几个周期使用同一口径，汇总数字才有参考价值；口径需要调整时，按第五节的方法处理历史数据衔接。
表头字段口径
- 报告周期：填写起止日期，与团队的计划节奏一致。按迭代报告填迭代起止日，按月报告填自然月首尾日。周期边界一旦确定，当期内不再改动。
- 覆盖团队/项目：写明报告覆盖的组织单元。跨团队协作的计划项，归属到承诺交付的一方，避免同一计划项在两张报告中重复计数。
- 统计口径：注明达成率按计划项计数还是按工作量加权，以及哪些计划项纳入统计（如是否包含当期新增的紧急插入项）。
计划明细字段口径
- 计划项：以可交付结果为粒度，写成“完成XX模块联调”“输出XX接口文档”这类可判断完成与否的描述。粒度过细会拉长表格，过粗则无法定位偏差，一般以一项工作能在一到两周内交付为宜。
- 承诺完成时间：取计划确定时对外承诺的日期，不随执行过程修改。执行中调整日期时，原承诺时间保留，新日期体现在纠偏动作或备注中，这样偏差才可追溯。
- 实际完成时间：填写实际交付并通过验收的日期。未完成的计划项此栏留空，达成状态填“未达成”或“进行中”。
- 达成状态：建议取值统一为“按期达成”“延期达成”“未达成”“已取消”四类。取消的计划项需在偏差说明中写明取消原因和决策人。
偏差天数与达成率计算口径
偏差天数 = 实际完成时间 − 承诺完成时间，按自然日计算，按期达成为 0，提前完成记为负数或统一记 0，团队内保持一致。未完成的计划项，偏差天数按报告截止日与承诺完成时间之差计算，标注为“截至报告日”。
达成率按计划项计数时：达成率 = 按期达成数 ÷ 计划项总数 × 100%。按工作量加权时：达成率 = 按期达成计划项的加权工作量之和 ÷ 全部计划项加权工作量之和 × 100%。两种口径各有适用场景：计划项规模相近时用计数口径更直观；计划项大小差异明显时，加权口径更能反映实际进度。选定一种后在统计口径栏注明，不混用。
偏差原因分类的常见取值
建议初始分类为：需求变更、依赖阻塞、估算偏差、资源变动、质量问题、外部环境。分类控制在六到八项，过多会导致填写时随意归类，过少则汇总后看不出问题集中在哪。团队可按自身业务增删，增删时记录版本。
必填与选填：哪些字段不能空
必填项保证报告可汇总、可追责；选填项服务于具体场景，留空不影响报告成立。未达成的计划项触发条件必填，这是本模板的核心规则。
| 字段 | 必填/选填 | 说明 |
|---|---|---|
| 报告周期 | 必填 | 没有周期，报告无法归档和比较 |
| 报告人 | 必填 | 明确报告责任主体 |
| 覆盖团队/项目 | 必填 | 确定统计范围 |
| 统计口径 | 必填 | 决定达成率如何解读 |
| 计划项 | 必填 | 报告的基本记录单元 |
| 承诺完成时间 | 必填 | 偏差计算的基准 |
| 达成状态 | 必填 | 汇总达成率的直接依据 |
| 实际完成时间 | 条件必填 | 状态为按期达成、延期达成时必填 |
| 偏差天数 | 选填 | 可由日期自动计算，手工填写时建议保留 |
| 偏差原因分类 | 条件必填 | 未达成或延期达成时必填 |
| 偏差说明 | 条件必填 | 未达成时必填，写清具体卡点 |
| 纠偏动作 | 条件必填 | 未达成时必填，写清下一步做什么 |
| 责任人 | 条件必填 | 存在纠偏动作时必填 |
| 预计完成时间 | 条件必填 | 存在纠偏动作时必填 |
| 报告日期 | 选填 | 与周期截止日不同时填写 |
字段留空的处理约定：必填项为空时报告不进入评审，退回补充；条件必填项在触发条件成立时为空，按同一规则退回。选填项留空视为“无此项内容”，不另行说明。汇总区由明细区计算得出，不单独手工填写，避免与明细不一致。
填写示例：一个完整周期的达成报告
以下示例为演示情景，团队与项目名称均为虚构，用于说明字段如何配合使用。
表头
| 字段 | 内容 |
|---|---|
| 报告周期 | 2025-04-01 至 2025-04-30 |
| 报告人 | 张明（研发组长） |
| 覆盖团队/项目 | 订单服务组 / 订单中心重构项目 |
| 统计口径 | 按计划项计数；包含当期新增紧急插入项 |
| 报告日期 | 2025-05-06 |
计划明细
| 序号 | 计划项 | 承诺完成时间 | 实际完成时间 | 达成状态 | 偏差天数 |
|---|---|---|---|---|---|
| 1 | 订单查询接口重构并上线 | 2025-04-10 | 2025-04-10 | 按期达成 | 0 |
| 2 | 订单状态机改造完成联调 | 2025-04-18 | 2025-04-23 | 延期达成 | 5 |
| 3 | 对账任务迁移至新调度平台 | 2025-04-25 | — | 未达成 | 5（截至报告日） |
| 4 | 订单导出功能性能优化 | 2025-04-30 | 2025-04-28 | 按期达成 | 0 |
| 5 | 历史订单归档方案评审 | 2025-04-15 | — | 已取消 | — |
偏差与纠偏
| 序号 | 对应计划项 | 偏差原因分类 | 偏差说明 | 纠偏动作 | 责任人 | 预计完成时间 |
|---|---|---|---|---|---|---|
| 1 | 订单状态机改造完成联调 | 依赖阻塞 | 依赖的支付网关接口变更，联调环境延迟三天可用 | 与支付团队约定接口冻结时间，联调环境提前一周准备 | 李华 | 2025-05-15 |
| 2 | 对账任务迁移至新调度平台 | 估算偏差 | 调度平台任务配置比预估复杂，迁移脚本需重写 | 拆分迁移任务，先完成两个核心任务迁移并验证 | 王芳 | 2025-05-20 |
| 3 | 历史订单归档方案评审 | 需求变更 | 业务方决定归档范围调整，方案暂缓，经项目负责人确认取消 | 待新范围明确后重新排期 | 张明 | 待定 |
汇总
| 汇总项 | 数值 |
|---|---|
| 计划项总数 | 5 |
| 按期达成数 | 2 |
| 达成率 | 40% |
| 主要偏差类型 | 依赖阻塞、估算偏差 |
| 下周期重点纠偏事项 | 对账任务迁移拆分推进；联调环境提前准备机制落地 |
示例取值解释
- 达成率计算：按统计口径“按计划项计数”，计划项总数 5，按期达成 2（序号 1、4），达成率 = 2 ÷ 5 × 100% = 40%。延期达成和已取消不计入按期达成数。若团队约定取消项不计入分母，则达成率为 2 ÷ 4 × 100% = 50%，两种算法都需在统计口径栏写明，本例采用前者。
- 偏差天数计算：序号 2 实际完成 4 月 23 日，承诺 4 月 18 日，偏差 5 天；序号 3 截至报告日 5 月 6 日尚未完成，承诺 4 月 25 日，偏差 5 天，标注“截至报告日”。
- 偏差原因分类选择：序号 2 的卡点是外部接口变更导致联调延迟，归入“依赖阻塞”而非“需求变更”，因为本团队的需求范围未变；序号 3 是自身对工作量判断不足，归入“估算偏差”；序号 5 是业务方调整范围，归入“需求变更”，并在偏差说明中记录取消决策人。
- 字段对应：示例中的每个字段与第一节空白模板一一对应，偏差与纠偏区的“对应计划项”通过序号关联计划明细区，汇总区数值全部由明细区计算得出。
调整与维护方法：让模板长期可用
模板的价值来自跨周期可比。调整时优先保持字段名称和计算口径稳定，确需变更时留下记录，让新旧数据能够衔接。
- 计划项粒度调整：当表格行数长期超过二三十行、评审时间明显拉长时，把同类计划项合并为可交付结果级条目；当偏差频繁集中在某个大条目内部、无法定位原因时，将其拆分。粒度调整只影响后续周期，已归档报告不回溯修改。
- 字段增减原则：新增字段需说明它支撑哪个决策，例如增加“风险等级”是为了在评审时优先讨论高风险项。连续两个周期无人填写的选填字段，考虑删除，避免表格膨胀。
- 偏差原因分类维护：分类调整时保留旧分类的历史记录，新周期启用新分类，并在模板版本说明中写明变更日期和原因。跨周期统计偏差类型分布时，注明分类版本差异。
- 达成率口径变更衔接：口径变更（如从计数改为加权）时，在变更当期同时给出新旧口径的数值，之后各期注明所用口径。历史报告保持原口径，不重算，比较趋势时以变更点为界分段解读。
- 评审与更新节奏：建议每季度或每两个迭代回顾一次模板使用情况，检查必填项是否被频繁退回、汇总区是否被实际用于决策。模板变更由报告负责人提出，团队评审后发布新版本，版本号与生效日期记录在模板表头下方。
从表格到流程：报告数据如何进入协作工具
表格适合出具单期报告，长期使用时，计划项的状态变化和汇总数字需要随执行实时更新，这时把报告流程放进协作工具更省力。承载方式可以按一条流程来设计：计划项作为工作项录入，承诺完成时间、达成状态、偏差原因作为工作项字段；报告作为文档，按周期引用当期工作项数据生成；评审时在文档中确认偏差原因和纠偏动作，纠偏动作转为新的工作项并指派责任人；汇总区的计划项总数、按期达成数、达成率随工作项状态更新而重新计算，不需要手工誊抄。
ONES 可以承载这条流程：计划项以工作项形式管理，状态与字段随执行更新；报告以文档形式按周期编写和评审，评审意见与纠偏动作在文档和工作项之间流转；汇总数据基于工作项状态统计，减少明细与汇总不一致的情况。具体字段配置和报表形态可按团队现有流程设置。这样，表格模板仍然是填写口径的依据，协作工具承担状态流转和汇总更新，两者使用同一套字段定义，报告就能持续产出并保持可比。
常见问题
报告周期应该按迭代、按月还是按季度？
取决于团队的计划节奏和报告的使用场景。按迭代报告适合节奏稳定、迭代周期固定的团队，能及时暴露单个迭代内的偏差；按月报告适合计划项跨迭代推进、需要看月度整体进度的团队；按季度报告更适合管理层视角的趋势观察。无论选哪种，周期边界一旦确定，当期内不再改动，否则偏差天数和达成率都失去可比性。同一团队建议保持一种主周期，需要更细粒度跟踪时用迭代数据支撑月度汇总。
计划项在执行中调整了承诺时间，报告里怎么记录？
原承诺完成时间保留不动，这是偏差可追溯的基础。调整后的日期体现在纠偏动作或备注中，达成状态按实际结果填写。如果调整发生在报告周期内且已获批准，可以在偏差说明中写明调整原因和批准人，但不要用新日期覆盖原承诺时间。这样下一期回顾时，能看出哪些计划项是承诺本身不合理、哪些是执行中出了问题。
取消的计划项要不要计入达成率分母？
两种做法都成立，关键是团队内统一并在统计口径栏写明。计入分母时，取消项拉低达成率，反映承诺兑现的严格程度；不计入分母时，达成率只衡量仍在推进的计划项，更贴近实际执行情况。示例中采用计入分母的口径，5 个计划项中 2 个按期达成，达成率 40%；若剔除取消项，则为 2 ÷ 4 = 50%。口径一旦确定，跨周期比较时不要中途切换。
偏差原因分类可以按团队情况自定义吗？
可以，但建议控制在六到八项，并在调整时记录版本。分类过细会导致填写时随意归类，汇总后看不出问题集中在哪里；分类过粗则无法区分不同性质的卡点。自定义时保留几个通用类别作为兜底，例如需求变更、依赖阻塞、估算偏差、资源变动、质量问题、外部环境，团队再按业务特点增删。跨周期统计偏差类型分布时，注明分类版本差异，避免把不同版本的分类直接合并比较。
表格模板和协作工具里的报告流程怎么衔接？
表格模板承担字段口径的定义，协作工具承担状态流转和汇总更新，两者使用同一套字段。具体做法是：计划项作为工作项录入，承诺完成时间、达成状态、偏差原因作为工作项字段；报告作为文档按周期引用当期工作项数据；评审时确认的纠偏动作转为新的工作项并指派责任人；汇总区的计划项总数、按期达成数、达成率随工作项状态更新重新计算。ONES 可以承载这条流程，计划项以工作项形式管理，报告以文档形式编写和评审，汇总数据基于工作项状态统计，具体字段配置和报表形态可按团队现有流程设置。
