研发交付计划表把交付链路拆成一条条可跟踪的记录：每个交付物或里程碑占一行，写清负责人、依赖、计划与承诺时间、当前状态和验收口径。本文提供一张可直接复制到表格工具或文档中的空白表，并逐字段说明填写口径、划分必填与选填、给出一条完整填写示例，最后说明上线后的维护方法。
要点总览（TL;DR）
- 模板以“一行一个交付对象”组织：交付物行记录具体产出，里程碑行记录关键节点，两类行共用同一套字段，通过“记录类型”列区分。
- 最小可用字段集为名称、负责人、计划完成时间、当前状态、验收口径五项，缺任一项记录就难以被独立跟踪和验收。
- 计划时间、承诺时间、实际完成时间分开填写，分别对应内部排期、对外承诺和最终结果，便于区分排期调整与承诺延期。
- 维护靠更新触发条件和状态流转规则：例行周更、事件当日更新、评审节点全表核对，状态回退需留痕。
- 本表聚焦交付链路的行级跟踪，版本/迭代列与版本规划对齐，行级时间与项目整体计划的关键节点对齐。
可复制空白模板：研发交付计划表
下表可直接复制到 Excel、在线表格或文档中。表头保持一行，数据行按需增删。交付物行与里程碑行共用同一套字段：交付物行填写具体产出（如接口文档、测试报告、可部署包），里程碑行填写关键节点（如需求评审通过、提测、上线），两类行通过“记录类型”列区分，便于统一筛选和汇总。
| 记录类型 | 交付物/里程碑名称 | 所属版本/迭代 | 负责人 | 协作角色 | 依赖与前置条件 | 计划完成时间 | 承诺完成时间 | 实际完成时间 | 当前状态 | 验收口径 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 交付物 | |||||||||||
| 交付物 | |||||||||||
| 里程碑 | |||||||||||
| 里程碑 | |||||||||||
复制时注意两点：一是“记录类型”列只填“交付物”或“里程碑”，不要混入其他分类，否则筛选会失效；二是空白行数量按当前交付范围预估，行数不足时在表格末尾追加，保持表头唯一。里程碑行通常不填“实际完成时间”以外的细粒度产出描述，验收口径写节点通过条件即可。
字段说明：每一列记录什么
字段说明与上表逐列对应，填写时以“这一行能否被别人独立跟踪和验收”为判断标准。下表列出每个字段的含义、填写口径和常见错误。
| 字段名 | 含义 | 填写口径 | 常见错误 |
|---|---|---|---|
| 记录类型 | 标识该行是交付物还是里程碑 | 只填“交付物”或“里程碑” | 写成“任务”“事项”等模糊分类 |
| 交付物/里程碑名称 | 该行对应的具体产出或节点 | 用“名词+可验证结果”写法，如“订单服务接口文档 V1.2”“提测通过” | 写成“开发工作”“推进中”等无法验收的表述 |
| 所属版本/迭代 | 该交付物归属的版本或迭代范围 | 填写版本号或迭代名称，与团队现有命名一致 | 留空或写“本期”，导致跨版本汇总困难 |
| 负责人 | 对该行结果负直接责任的人 | 填一个人名，不填团队或多人并列 | 填“研发组”“前端团队”，出问题时无人认领 |
| 协作角色 | 需要配合的岗位或团队 | 写角色和配合内容，如“测试：用例评审”“运维：发布窗口” | 只写部门名，不写配合事项 |
| 依赖与前置条件 | 该行开始或完成前必须满足的条件 | 写“依赖对象+满足条件”，如“依赖支付网关联调环境就绪” | 写“依赖上游”，无法判断具体卡点 |
| 计划完成时间 | 团队内部排期的时间 | 填日期，按内部资源测算 | 与承诺时间混用，内部调整时对外口径混乱 |
| 承诺完成时间 | 对业务方或客户承诺的时间 | 填日期，变更需走确认流程 | 随意改动，承诺失去约束力 |
| 实际完成时间 | 实际达成的时间 | 完成当日填写，未完成留空 | 提前预填，掩盖延期事实 |
| 当前状态 | 该行所处的进展阶段 | 从约定状态集中选择，如“未开始/进行中/待验收/已完成/已阻塞” | 自由填写“差不多了”“快好了” |
| 验收口径 | 判断该行完成的客观标准 | 写可检查的条件，如“接口文档经前后端评审签字”“冒烟用例通过率100%” | 写“质量达标”“符合要求”等主观描述 |
| 备注 | 补充说明 | 记录风险、变更原因、关联链接等 | 把关键依赖只写在备注里，主字段留空 |
三个时间字段的分工需要特别说明：计划时间是团队内部排期，资源变化时可以调整；承诺时间是对外口径，变更需要通知相关方并留痕；实际完成时间只在达成后填写，用于复盘排期准确度。三者分开记录，才能区分“内部排期调整”和“对外承诺延期”两类问题。
必填与选填：最小可用字段集
团队刚启用模板时，字段过多会增加填写负担。建议先保证最小可用字段集，再按成熟度补充选填字段。最小可用字段集的底线是：任意一行记录，换一个人接手也能知道做什么、谁负责、何时要、现在到哪、怎样算完成。
| 字段 | 必填/选填 | 理由或适用场景 |
|---|---|---|
| 交付物/里程碑名称 | 必填 | 没有名称，记录无法被识别和引用 |
| 负责人 | 必填 | 明确唯一责任人，避免推诿 |
| 计划完成时间 | 必填 | 支撑排期和延期预警 |
| 当前状态 | 必填 | 支撑进度汇总和阻塞识别 |
| 验收口径 | 必填 | 没有验收标准，完成与否无法判定 |
| 记录类型 | 必填 | 区分交付物与里程碑，支撑分类统计 |
| 依赖与前置条件 | 选填（建议尽早补） | 跨团队交付、存在外部依赖时必填 |
| 承诺完成时间 | 选填 | 有对外承诺或合同节点的交付必填 |
| 实际完成时间 | 选填 | 用于复盘排期准确度，完成时补填 |
| 所属版本/迭代 | 选填 | 多版本并行时建议必填 |
| 协作角色 | 选填 | 需要多岗位配合的交付物建议填写 |
| 备注 | 选填 | 记录风险、变更和关联信息 |
裁剪时守住一条底线：名称、负责人、计划完成时间、当前状态、验收口径五项不能删。这五项缺失任何一项，记录就无法被独立跟踪和验收。依赖和承诺时间可以随团队成熟度逐步补齐，但在跨团队交付场景中应尽早填写，否则阻塞往往在临近交付时才暴露。
填写示例：一条完整交付记录
以下是一条已填写的交付物记录，用于示范各字段如何配合。示例为演示情景，团队可按自身业务替换名称和时间。
| 字段 | 填写内容 |
|---|---|
| 记录类型 | 交付物 |
| 交付物/里程碑名称 | 订单服务接口文档 V1.2 |
| 所属版本/迭代 | V3.4 迭代 |
| 负责人 | 张明（后端） |
| 协作角色 | 前端：联调对接；测试：接口用例评审 |
| 依赖与前置条件 | 依赖订单数据模型评审通过；依赖支付网关沙箱环境可用 |
| 计划完成时间 | 2025-06-18 |
| 承诺完成时间 | 2025-06-20 |
| 实际完成时间 | 2025-06-19 |
| 当前状态 | 已完成 |
| 验收口径 | 接口文档覆盖全部新增接口，前后端评审通过并留评审记录 |
| 备注 | 支付网关沙箱曾延迟一天，已在依赖列标注 |
从这条记录可以提炼几条填写规律。名称写成“对象+版本”，评审时能直接定位文档；负责人只写一人，协作角色写清配合事项，责任边界清楚；依赖写成“依赖对象+满足条件”，阻塞出现时能直接找到卡点；计划时间早于承诺时间，为内部调整留出缓冲；验收口径写成可检查的动作和结果，评审通过与否不靠口头判断；实际完成时间在达成后填写，与计划时间对比即可看出排期准确度。
里程碑行的写法略有不同。例如“V3.4 提测”这一行：记录类型填“里程碑”，名称写“V3.4 提测”，负责人填测试负责人，依赖写“依赖全部提测范围内交付物状态为已完成”，验收口径写“提测清单内交付物全部通过冒烟测试”，实际完成时间在提测通过当日填写。里程碑行不展开具体产出细节，产出细节由对应的交付物行承载。
调整与维护方法：让计划表持续可用
计划表填完只是开始，能否持续可用取决于更新节奏、状态规则和维护责任是否明确。以下规则可按团队规模裁剪，但建议至少保留更新触发条件和状态流转两项。
更新频率与触发条件
- 固定节奏：每周一次例行更新，逐行核对状态、时间和依赖变化。
- 事件触发：交付物完成、依赖解除、承诺时间变更、出现阻塞时，当日更新对应行。
- 节点触发：迭代评审、提测、发布前各做一次全表核对，确认验收口径与实际情况一致。
状态流转规则
状态从约定集合中选择，按“未开始→进行中→待验收→已完成”推进；出现外部依赖未满足或资源冲突时标记“已阻塞”，并在依赖列写明卡点。状态回退需要说明原因并记录在备注中，避免状态反复跳动却无迹可查。已完成的行不再改动，后续问题通过新行或缺陷记录跟踪。
维护责任人与评审节点
每行负责人维护自己负责的记录，项目经理或交付负责人负责全表一致性和汇总。评审节点建议设在迭代计划和迭代复盘：计划时确认字段完整，复盘时对照计划时间与实际完成时间，分析延期原因并调整后续排期。维护责任落到人，表格才不会在第二周就停止更新。
与项目整体计划、版本规划的边界
本表聚焦交付链路层面的行级跟踪，回答“每个交付物和里程碑由谁、何时、按什么标准完成”。项目整体计划的编制方法、产品版本内容的取舍与版本规划属于另外的管理动作，不在本表展开。实际使用时，本表的版本/迭代列与版本规划对齐，行级时间与项目整体计划的关键节点对齐，三者通过共同的版本号和节点名称衔接，避免各写一套。
当团队把这张表迁移到协作工具中承载时，可将表格字段映射为工作项属性，让状态流转和评审记录随工作项一起留存。ONES 支持项目制与产品制并行管理，项目制场景下可围绕里程碑和交付物组织工作项，并通过迭代计划、任务看板跟踪进展；需求、任务、测试与缺陷在同一闭环中流转，交付物的验收记录可与测试计划、缺陷管理关联。具体字段配置和状态设置需按团队流程确定，本文模板可作为梳理字段的起点。
常见问题
团队刚开始用这张表，字段太多填不完怎么办？
先只保留最小可用字段集：名称、负责人、计划完成时间、当前状态、验收口径，再加“记录类型”列用于区分交付物与里程碑。其余字段按场景逐步补：跨团队交付时补依赖与前置条件，有对外承诺时补承诺完成时间，多版本并行时补所属版本/迭代。裁剪时守住一条底线，这五项核心字段不能删，否则记录无法被独立跟踪和验收。
交付物行和里程碑行可以合并成一种记录吗？
不建议合并。两类行的填写重点不同：交付物行要写清具体产出和可检查的验收条件，里程碑行只需写节点通过条件，产出细节由对应的交付物行承载。合并后容易出现里程碑行堆满细节、交付物行反而缺少验收口径的情况。如果团队规模小、节点少，可以只保留交付物行，把关键节点作为一条交付物记录填写，但“记录类型”列仍建议保留，便于后续扩展。
承诺完成时间变更时，表里应该怎么记录？
承诺时间是对外口径，变更需要通知相关方并留痕。建议做法是：更新“承诺完成时间”列，同时在“备注”列写明变更原因、通知对象和确认时间。计划完成时间按内部资源情况单独调整，两者不要互相覆盖。复盘时对照计划时间、承诺时间和实际完成时间三个日期，可以区分“内部排期调整”和“对外承诺延期”两类问题，分别改进。
计划表迁移到协作工具后，还需要保留表格吗？
迁移后表格可以作为字段梳理的起点和阶段性快照，日常跟踪以工具中的工作项为准。迁移时把表格字段映射为工作项属性，状态流转和评审记录随工作项留存，避免表格与工具两套数据各写一份。ONES 支持项目制与产品制并行管理，项目制场景下可围绕里程碑和交付物组织工作项，并通过迭代计划、任务看板跟踪进展；需求、任务、测试与缺陷在同一闭环中流转。具体字段配置和状态设置需按团队流程确定。
状态标记为“已阻塞”后，什么时候可以恢复？
阻塞解除的条件应写在“依赖与前置条件”列里，例如“依赖支付网关沙箱环境可用”。条件满足后，由该行负责人把状态改回“进行中”，并在备注中记录阻塞起止时间和解除依据。如果阻塞持续影响到承诺时间，需要同步发起承诺时间变更流程。评审节点上集中核对一次所有“已阻塞”行，判断哪些依赖需要升级协调，避免阻塞长期挂起无人推动。
