研发交付计划模板要同时回答四个问题：交付什么、按什么节奏交付、依赖谁、向谁承诺。对应四张核心表——交付范围表、交付节奏表、依赖关系表、承诺与变更表，每张表设置唯一编号以便跨表引用。下面给出可直接复制填写的空白表、字段口径、必填选填标注、一份完整填写样例，以及模板投入使用后的维护规则。
要点总览（TL;DR）
- 研发交付计划模板用四张表承载四类信息：交付范围表记录交付物与验收口径，交付节奏表安排里程碑与迭代窗口，依赖关系表梳理内外部前置项与责任方，承诺与变更表记录对外承诺与日期调整。
- 四张表通过统一编号互相引用：交付物用 D、里程碑用 M、依赖项用 DP、承诺项用 C，交付物编号作为主键，其他表只引用编号不重复描述内容。
- 必填字段以“缺了就无法判断交付是否成立”为标准，小团队可省略跨团队协调类字段，对外发布类交付应保留承诺级别和变更记录。
- 模板维护采用触发式更新：范围增减、里程碑调整、依赖状态变化、承诺变更时更新对应行，变更记录追加不覆盖，每个版本发布后归档为只读版本。
可复制空白模板：四张核心表
四张表可以放在同一份文档里，也可以拆成四个工作表。建议先填交付范围表，再排节奏表，然后梳理依赖表，最后形成承诺表。编号规则统一为“表前缀-两位序号”，交付物用 D、里程碑用 M、依赖项用 DP、承诺项用 C，例如 D-01 在节奏表、依赖表、承诺表中被引用时保持同一编号，不再另起名称。
表一：交付范围表
| 交付物编号 | 交付物名称 | 类型 | 范围说明 | 验收标准 | 验收方式 | 责任角色 | 关联需求/工单 | 状态 |
|---|---|---|---|---|---|---|---|---|
| D-__ | ||||||||
| D-__ |
表二：交付节奏表
| 里程碑编号 | 里程碑名称 | 覆盖交付物编号 | 计划开始 | 计划完成 | 迭代窗口 | 关键活动 | 责任角色 | 状态 |
|---|---|---|---|---|---|---|---|---|
| M-__ | D-__ | |||||||
| M-__ | D-__ |
表三：依赖关系表
| 依赖编号 | 被依赖对象 | 依赖方（交付物/里程碑编号） | 依赖类型 | 提供方 | 需要就绪时间 | 当前状态 | 影响说明 | 应对措施 |
|---|---|---|---|---|---|---|---|---|
| DP-__ | D-__ / M-__ | |||||||
| DP-__ | D-__ / M-__ |
表四：承诺与变更表
| 承诺编号 | 承诺事项 | 关联交付物/里程碑编号 | 承诺对象 | 承诺日期 | 当前计划日期 | 承诺级别 | 变更记录 | 确认人 |
|---|---|---|---|---|---|---|---|---|
| C-__ | D-__ / M-__ | |||||||
| C-__ | D-__ / M-__ |
表间编号引用规则
- 交付物编号 D 是主键，节奏表、依赖表、承诺表引用交付物时只写编号，不重复描述交付物内容。
- 一个里程碑可覆盖多个交付物，在“覆盖交付物编号”列用逗号分隔，例如 D-01, D-03。
- 依赖表指向的对象可以是交付物，也可以是里程碑，填写时注明前缀，便于判断依赖影响的是单个交付物还是整个节点。
- 承诺表只引用已进入范围表的交付物或节奏表中的里程碑，避免出现无来源的承诺项。
字段说明：每个字段记录什么
字段口径统一后，不同人填写的计划才能互相对照。日期统一用 YYYY-MM-DD；状态用有限枚举值，建议为“未开始、进行中、有风险、已完成、已取消”；责任方写角色而非个人姓名，人员变动时只需更新角色对应关系。
| 所属表 | 字段 | 记录内容 | 取值口径与常见错误 |
|---|---|---|---|
| 交付范围表 | 交付物编号 | 该交付物的唯一标识 | 按 D-01 格式顺序编号；错误做法是复用旧编号或中途改号 |
| 交付范围表 | 交付物名称 | 可被验收的具体产物 | 写“订单导出接口”而非“订单功能优化”；名称应能对应验收动作 |
| 交付范围表 | 类型 | 交付物形态 | 枚举：功能、接口、文档、配置、数据、其他 |
| 交付范围表 | 范围说明 | 本次交付包含与不包含的边界 | 写清边界条件，例如“含批量导出，不含定时任务” |
| 交付范围表 | 验收标准 | 判断交付完成的依据 | 写成可核验条件；避免“体验良好”这类无法判定的表述 |
| 交付范围表 | 验收方式 | 由谁、通过什么方式验收 | 枚举：演示验收、测试报告、文档评审、上线验证 |
| 交付范围表 | 责任角色 | 对该交付物结果负责的角色 | 写角色名；一个交付物只设一个主责角色 |
| 交付范围表 | 关联需求/工单 | 需求或工单系统的编号 | 填写外部系统编号，便于回溯范围来源 |
| 交付范围表 | 状态 | 交付物当前进展 | 使用统一枚举值，不写自由文本 |
| 交付节奏表 | 里程碑编号 | 节奏节点的唯一标识 | 按 M-01 格式编号 |
| 交付节奏表 | 覆盖交付物编号 | 该节点要完成的交付物 | 引用 D 编号；空值表示该节点为纯检查点 |
| 交付节奏表 | 计划开始/计划完成 | 节点的时间窗口 | 用 YYYY-MM-DD；完成日期应晚于开始日期 |
| 交付节奏表 | 迭代窗口 | 对应迭代或发布批次 | 例如“2025-S1 迭代 3”；与团队实际迭代命名保持一致 |
| 交付节奏表 | 关键活动 | 该节点必须发生的动作 | 写动作，如“联调完成、回归测试通过、发布评审” |
| 依赖关系表 | 依赖编号 | 依赖项唯一标识 | 按 DP-01 格式编号 |
| 依赖关系表 | 被依赖对象 | 需要先就绪的事项 | 写具体对象，如“支付网关测试环境”“安全合规评审结论” |
| 依赖关系表 | 依赖方 | 受该依赖影响的交付物或里程碑 | 引用 D 或 M 编号，不写自由文本 |
| 依赖关系表 | 依赖类型 | 依赖的性质 | 枚举：内部团队、外部供应商、环境资源、审批决策 |
| 依赖关系表 | 提供方 | 负责满足依赖的角色或组织 | 写角色或团队名；外部依赖写对接方名称 |
| 依赖关系表 | 需要就绪时间 | 依赖最晚可用时间 | 应早于依赖方计划完成日期，留出缓冲 |
| 依赖关系表 | 当前状态 | 依赖满足进展 | 枚举：未启动、进行中、已就绪、有风险 |
| 依赖关系表 | 影响说明 | 依赖未满足时的后果 | 写受影响的交付物和可能延迟天数 |
| 依赖关系表 | 应对措施 | 依赖无法按期满足时的备选方案 | 写具体替代动作，如“使用模拟环境先行联调” |
| 承诺与变更表 | 承诺编号 | 承诺项唯一标识 | 按 C-01 格式编号 |
| 承诺与变更表 | 承诺事项 | 对外或跨团队承诺的内容 | 与交付物或里程碑对应，不写笼统的“按期上线” |
| 承诺与变更表 | 承诺对象 | 承诺给谁 | 写业务方、客户、上下游团队等具体对象 |
| 承诺与变更表 | 承诺日期 | 已对外确认的日期 | 一旦确认不随意改动；改动必须进入变更记录 |
| 承诺与变更表 | 当前计划日期 | 按当前节奏推算的日期 | 与承诺日期分开记录，两者不一致时即为风险信号 |
| 承诺与变更表 | 承诺级别 | 承诺的约束强度 | 枚举：硬承诺（合同/对外发布）、软承诺（内部协同）、参考目标 |
| 承诺与变更表 | 变更记录 | 日期调整的历史 | 每次变更写“原日期→新日期、原因、确认人”，追加不覆盖 |
| 承诺与变更表 | 确认人 | 对承诺变更拍板的角色 | 写角色；硬承诺变更需业务方确认人 |
最容易混淆的是承诺日期与当前计划日期。承诺日期是对外已经说出去的日期，代表约束；当前计划日期是按最新节奏推算的日期，代表现实。两者分开记录，差距一旦出现就能被看见，而不是等到交付前才暴露。计划开始日期与需要就绪时间也常被混用：前者是节点自身的时间，后者是依赖方必须提前满足的时间，后者应更早。
必填与选填：最小可用字段集
必填的判断标准是“缺了这个字段，就无法判断交付是否成立”。按此标准，四张表各有一组最小字段集，其余字段按团队规模和交付类型补充。
| 表 | 必填字段 | 选填字段 | 选填适用场景 |
|---|---|---|---|
| 交付范围表 | 交付物编号、交付物名称、范围说明、验收标准、责任角色、状态 | 类型、验收方式、关联需求/工单 | 交付物形态多样时补类型；需要回溯需求来源时补关联编号；验收涉及多方时补验收方式 |
| 交付节奏表 | 里程碑编号、里程碑名称、覆盖交付物编号、计划完成、责任角色、状态 | 计划开始、迭代窗口、关键活动 | 节点跨度较长时补计划开始；按迭代交付的团队补迭代窗口；节点含多个动作时补关键活动 |
| 依赖关系表 | 依赖编号、被依赖对象、依赖方、提供方、需要就绪时间、当前状态 | 依赖类型、影响说明、应对措施 | 外部依赖多时补依赖类型；关键路径上的依赖补影响说明与应对措施 |
| 承诺与变更表 | 承诺编号、承诺事项、关联交付物/里程碑编号、承诺对象、承诺日期、当前计划日期 | 承诺级别、变更记录、确认人 | 存在合同或对外发布承诺时补承诺级别；发生过日期调整后必须补变更记录与确认人 |
裁剪时遵循两条原则。第一，小团队或单团队交付可以省略跨团队协调类字段，例如依赖类型、确认人，但交付物编号、验收标准、承诺日期不能省，它们决定计划能否被核对。第二，交付类型影响字段取舍：对外发布类交付应保留承诺级别和变更记录；内部平台类交付可弱化承诺表，把重点放在依赖表和节奏表上。字段扩展同样有边界，新增字段应能对应一个明确的判断动作，否则容易变成填了没人看的冗余列。
填写示例：一个版本交付的完整样例
以下为演示情景：某研发团队计划在 2025-06-20 发布订单模块 V2.3，包含批量导出与对账报表两个交付物，依赖支付网关测试环境和安全评审结论。样例仅用于说明四张表如何联动。
交付范围表（节选）
| 交付物编号 | 交付物名称 | 类型 | 范围说明 | 验收标准 | 验收方式 | 责任角色 | 关联需求/工单 | 状态 |
|---|---|---|---|---|---|---|---|---|
| D-01 | 订单批量导出接口 | 接口 | 含按条件批量导出，不含定时任务 | 1 万条订单导出成功率 100%，耗时不超过 60 秒 | 测试报告 | 后端负责人 | REQ-318 | 进行中 |
| D-02 | 对账报表页面 | 功能 | 含日对账汇总，不含月结报表 | 报表数据与财务样例核对一致 | 演示验收 | 前端负责人 | REQ-322 | 未开始 |
交付节奏表（节选）
| 里程碑编号 | 里程碑名称 | 覆盖交付物编号 | 计划开始 | 计划完成 | 迭代窗口 | 关键活动 | 责任角色 | 状态 |
|---|---|---|---|---|---|---|---|---|
| M-01 | 接口联调完成 | D-01 | 2025-05-26 | 2025-06-06 | 2025-S1 迭代 3 | 联调、接口回归 | 后端负责人 | 进行中 |
| M-02 | 版本发布 | D-01, D-02 | 2025-06-16 | 2025-06-20 | 2025-S1 迭代 4 | 回归测试、发布评审、上线 | 研发经理 | 未开始 |
依赖关系表（节选）
| 依赖编号 | 被依赖对象 | 依赖方 | 依赖类型 | 提供方 | 需要就绪时间 | 当前状态 | 影响说明 | 应对措施 |
|---|---|---|---|---|---|---|---|---|
| DP-01 | 支付网关测试环境 | D-01 | 环境资源 | 基础架构团队 | 2025-05-28 | 有风险 | 环境延迟将导致 M-01 推迟，最多影响 3 天 | 先用模拟环境完成非支付链路联调 |
| DP-02 | 安全评审结论 | M-02 | 审批决策 | 安全团队 | 2025-06-13 | 进行中 | 评审未通过则发布节点顺延 | 提前提交评审材料，预留一轮整改时间 |
承诺与变更表（节选）
| 承诺编号 | 承诺事项 | 关联交付物/里程碑编号 | 承诺对象 | 承诺日期 | 当前计划日期 | 承诺级别 | 变更记录 | 确认人 |
|---|---|---|---|---|---|---|---|---|
| C-01 | 订单模块 V2.3 上线 | M-02 | 业务运营团队 | 2025-06-20 | 2025-06-20 | 硬承诺 | — | 研发经理 |
| C-02 | 批量导出能力可用 | D-01 | 业务运营团队 | 2025-06-20 | 2025-06-23 | 软承诺 | 2025-06-10：06-20→06-23，原因 DP-01 环境延迟，确认人：研发经理 | 研发经理 |
样例中 DP-01 状态变为“有风险”后，D-01 的计划完成日期随之调整，C-02 的当前计划日期与承诺日期出现差距，变更记录追加了调整原因和确认人，而 C-01 作为硬承诺保持原日期并进入风险跟踪。这条链路说明：依赖表的变化应推动节奏表更新，节奏表的变化再反映到承诺表的当前计划日期，承诺日期本身只在正式变更时改动。
调整与维护方法：模板落地后的更新节奏
模板填完只是起点，能否持续使用取决于更新是否与真实事件挂钩。建议采用触发式更新，而不是固定周期全量重填：事件发生时更新对应行，周度例会上只核对有变化的行。
| 触发条件 | 需要更新的表 | 更新动作 | 责任人 |
|---|---|---|---|
| 交付物范围增减 | 交付范围表 | 新增或关闭 D 编号，同步检查节奏表引用 | 交付物责任角色 |
| 里程碑日期调整 | 交付节奏表、承诺与变更表 | 更新计划日期，若影响对外承诺则追加变更记录 | 研发经理 |
| 依赖方状态变化 | 依赖关系表 | 更新当前状态，评估影响说明与应对措施 | 依赖对接人 |
| 对外承诺变更 | 承诺与变更表 | 追加变更记录，注明原日期、新日期、原因与确认人 | 承诺确认人 |
| 版本发布完成 | 四张表 | 关闭相关编号，归档本版本计划 | 研发经理 |
变更留痕采用追加方式，不覆盖原值。承诺表的变更记录保留完整历史，依赖表的状态变化可在周会记录中留痕。评审责任按层级划分：交付物层面由责任角色自查，里程碑层面由研发经理在节点前评审，承诺层面由承诺确认人把关。每个版本发布后，将四张表归档为只读版本，作为下一次计划编制的参照。
模板本身也需要版本管理。字段增删、枚举值调整、编号规则变化都应记录模板版本号和生效日期，并在文档开头注明适用版本。模板调整后，旧版本计划不强制迁移，新版本计划统一使用新模板，避免同一时期出现两套口径。
当四张表进入日常协作工具承载时，编号引用和状态同步会更顺畅。ONES 支持项目制管理，针对需求明确、交付周期固定的场景严控里程碑和交付物，与节奏表的里程碑管理相对应；ONES Wiki 的页面模板库可一键创建制式化文档模板，适合把四张表固化为团队统一格式，文档中还可嵌入任务进度和报表，让交付物状态与计划表保持在同一页面查看。依赖项和承诺项的跟踪则可结合需求—任务—测试—缺陷的闭环流程，把交付物编号与需求、工单关联起来，减少手工核对。
常见问题
交付物编号中途需要调整时，其他三张表怎么处理？
编号一旦被其他表引用，就不宜直接改号。更稳妥的做法是保留原编号，在交付范围表中把该行状态改为“已取消”，再新增一行新编号承接后续工作，并在范围说明中注明替代关系。这样节奏表、依赖表、承诺表中的历史引用仍然可追溯，不会出现指向空编号的情况。如果确实需要合并或拆分交付物，建议在版本节点结束时统一处理，避免在交付过程中频繁改号。
承诺日期和当前计划日期出现差距时，应该先改哪一个？
先更新当前计划日期，让它反映按最新节奏推算的现实时间；承诺日期只在正式对外变更并获得确认人同意后才改动。两者出现差距本身就是风险信号，应进入周会跟踪，并评估能否通过调整资源或压缩其他环节追回。硬承诺的日期调整通常需要业务方确认人参与，软承诺可由研发经理判断。差距持续扩大时，应主动与承诺对象沟通，而不是等到交付前才说明。
依赖关系表里的“需要就绪时间”怎么定才合理？
需要就绪时间应早于依赖方的计划完成日期，并留出验证和返工缓冲。对于环境资源类依赖，通常要留出部署和联调时间；对于审批决策类依赖，要留出材料准备和一轮整改的时间。填写时可以倒推：从依赖方的计划完成日期往前减去验证所需时间，得到最晚就绪时间。如果提供方反馈无法满足，应在应对措施列写明替代方案，例如先用模拟环境推进非依赖部分的工作。
小团队只有几个人，四张表都要填吗？
四张表的结构可以保留，字段可以精简。小团队通常可以省略依赖类型、确认人、验收方式等跨团队协调类字段，但交付物编号、验收标准、承诺日期这几项建议保留，它们决定计划能否被核对。如果团队交付内容单一、对外承诺少，承诺与变更表可以只保留承诺事项、承诺对象和承诺日期三列。字段精简的判断标准是：删掉之后是否还能判断某项交付是否成立、是否按期。
模板在协作工具里承载时，编号引用和状态同步怎么落地？
可以把四张表放在同一文档或同一项目的不同视图中，交付物编号与需求、工单编号建立关联，状态变化时同步更新。ONES 支持项目制管理，针对需求明确、交付周期固定的场景严控里程碑和交付物；ONES Wiki 的页面模板库可一键创建制式化文档模板，适合把四张表固化为团队统一格式，文档中还可嵌入任务进度和报表，让交付物状态与计划表在同一页面查看。依赖项和承诺项的跟踪可结合需求—任务—测试—缺陷的闭环流程，减少手工核对。
