跨团队规划记录把多个团队在同一规划周期内的目标、依赖、交付节点和风险放进一张表，让联合规划会上的口头共识变成可追踪的记录。本文提供可直接复制的主表与依赖子表，逐字段说明填写口径，区分必填与选填，并用一份完整示例展示字段如何联动，最后给出按团队规模调整和按节奏维护的方法。
要点总览（TL;DR）
- 跨团队规划记录模板由主表和依赖子表组成：主表按团队记录目标、成功标准、关键交付物、里程碑、风险与决策，依赖子表逐条记录提供方、接收方和需要时间。
- 必填字段是规划周期、团队、目标、成功标准、关键交付物、负责人和状态；依赖子表的依赖编号、依赖内容、双方团队和需要时间同样不能空。
- 填写分两步：各团队先独立填写目标与交付物，再在联合规划会上补齐依赖、里程碑和决策记录，复核时先看依赖状态再回主表更新。
- 模板按团队数量和规划层级增减列，字段只增不改；每个周期使用独立记录，按周或双周更新状态，周期结束归档并复盘。
可复制空白模板：跨团队规划记录表
模板由两张表组成：主表按团队逐行记录目标与交付，依赖子表按依赖关系逐条记录提供方与接收方。两张表通过“团队”和“规划周期”字段关联，复制到表格工具后即可填写。
主表：跨团队规划记录
| 规划周期 | 团队 | 目标 | 成功标准 | 关键交付物 | 里程碑 | 风险与假设 | 决策与待办 | 负责人 | 状态 | 下次复核 |
|---|---|---|---|---|---|---|---|---|---|---|
依赖子表：跨团队依赖明细
| 依赖编号 | 规划周期 | 依赖内容 | 提供方团队 | 接收方团队 | 需要时间 | 关联交付物 | 约定方式 | 状态 | 负责人 |
|---|---|---|---|---|---|---|---|---|---|
行数按实际团队数量和依赖条数增减。主表一行对应一个团队在一个规划周期内的承诺；依赖子表一行对应一条跨团队依赖，同一团队可以有多行依赖记录。两张表都保留“规划周期”字段，便于按周期筛选和归档。
字段说明：每个字段记录什么、怎么填
字段口径统一后，不同团队填出来的记录才能横向比较。下表逐字段说明含义与常见写法，填写时以“读者不看会议纪要也能理解”为标准。
| 字段 | 含义 | 填写口径 |
|---|---|---|
| 规划周期 | 本次规划覆盖的时间范围 | 写清起止日期或周期编号，如“2025 Q2（4月1日—6月30日）”。同一周期内所有行使用相同写法。 |
| 团队 | 做出承诺的团队 | 使用组织内通用团队名称，避免简称歧义；跨部门协作时注明所属部门。 |
| 目标 | 该团队在本周期要达成的结果 | 写结果而非动作，一条目标对应一个可判断是否达成的方向；一个团队通常写1—3条。 |
| 成功标准 | 判断目标达成的依据 | 写可观察的指标、验收条件或交付状态，避免“进展顺利”这类无法判断的表述。 |
| 关键交付物 | 本周期对外可见的产出 | 写交付物名称和形态，如“订单服务接口文档v2”“灰度环境上线”。 |
| 里程碑 | 周期内的关键时间点 | 写日期加事件，如“5月15日 接口联调完成”；只列对跨团队有影响的时间点。 |
| 风险与假设 | 可能影响承诺成立的因素 | 风险写“事件+影响”，假设写“前提条件”；每条尽量对应一个应对动作或观察信号。 |
| 决策与待办 | 规划会上形成的结论和后续动作 | 决策写“决定了什么+由谁拍板”，待办写“动作+负责人+期限”。 |
| 负责人 | 对该行记录负责的人 | 写具体姓名，不写团队名；负责人负责更新状态和推动依赖。 |
| 状态 | 当前进展 | 使用统一取值，如“未开始/进行中/有风险/已完成/已取消”，避免自造状态词。 |
| 下次复核 | 下一次检查该行记录的时间 | 写日期，通常与规划节奏对齐，如双周节奏写两周后的日期。 |
| 依赖编号 | 依赖条目的唯一标识 | 按“周期-序号”编号，如“Q2-D01”，便于在会议和待办中引用。 |
| 依赖内容 | 需要对方提供什么 | 写具体交付物或动作，如“提供测试账号与接口Mock”，避免只写“支持”。 |
| 提供方团队 / 接收方团队 | 依赖的两端 | 双方都写团队名；一条依赖只有一个提供方和一个接收方，多方依赖拆成多条。 |
| 需要时间 | 接收方需要该交付的时间 | 写日期或时间窗口，并说明是“最晚需要”还是“期望时间”。 |
| 关联交付物 | 该依赖对应的主表交付物 | 填写主表中“关键交付物”的名称，保持两张表可对应。 |
| 约定方式 | 双方确认依赖的方式 | 写“联合规划会确认”“书面邮件确认”等，便于追溯共识来源。 |
必填与选填：哪些字段不能空
必填字段决定记录能否被追踪和交接，选填字段用于补充上下文。填写下限是：任何一行记录，必填字段完整，选填字段可以留空但需在备注中说明原因。
| 字段 | 必填/选填 | 理由与留空条件 |
|---|---|---|
| 规划周期 | 必填 | 没有周期无法归档和筛选，任何情况下不能空。 |
| 团队 | 必填 | 记录的责任主体，不能空。 |
| 目标 | 必填 | 规划记录的核心内容；团队本周期无独立目标时，写“支撑其他团队目标”并注明对应团队。 |
| 成功标准 | 必填 | 缺少成功标准的目标无法判断达成，不能空；确实难以量化时写验收条件。 |
| 关键交付物 | 必填 | 跨团队协作的交接依据，不能空。 |
| 负责人 | 必填 | 无人负责的记录不会更新，不能空。 |
| 状态 | 必填 | 初始填写“未开始”，之后随进展更新。 |
| 里程碑 | 选填 | 本周期无跨团队时间点时留空；有对外承诺的时间点必须填写。 |
| 风险与假设 | 选填 | 无已知风险时留空，但规划会上提出的风险必须记录。 |
| 决策与待办 | 选填 | 该行未涉及决策时留空；涉及取舍、资源调整的决策必须记录。 |
| 下次复核 | 选填 | 可按团队统一节奏在表头约定，单行有特殊复核需求时填写。 |
| 依赖编号 | 必填（依赖子表） | 依赖条目需要被引用和跟踪，不能空。 |
| 依赖内容 | 必填（依赖子表） | 不能空，且需写到可交付的具体程度。 |
| 提供方 / 接收方团队 | 必填（依赖子表） | 两端缺一不可，否则无法确定责任。 |
| 需要时间 | 必填（依赖子表） | 没有时间要求的依赖无法排期，不能空。 |
| 关联交付物 | 选填 | 依赖暂未挂到具体交付物时可留空，待明确后补填。 |
| 约定方式 | 选填 | 默认在联合规划会上确认，特殊约定时填写。 |
留空处理规则：必填字段留空的记录视为未完成填写，在规划会结束前补齐；选填字段留空不需要解释，但同一字段在同一周期内应保持“填或不填”的一致习惯，避免部分团队填、部分团队不填导致比较失真。
填写示例：一个规划周期的完整记录
以下为演示情景，团队名称和数据均为虚构，用于展示字段如何联动填写。
示例背景
某产品组织按季度做跨团队规划，本周期为2025 Q2（4月1日—6月30日），参与团队包括订单团队、支付团队和客户端团队。规划会分两步：各团队先独立填写目标与交付物，再在联合规划会上补齐依赖、里程碑和决策。
主表填写示例
| 规划周期 | 团队 | 目标 | 成功标准 | 关键交付物 | 里程碑 | 风险与假设 | 决策与待办 | 负责人 | 状态 | 下次复核 |
|---|---|---|---|---|---|---|---|---|---|---|
| 2025 Q2 | 订单团队 | 完成订单服务拆分，支持支付团队独立接入 | 拆分后订单创建接口P95响应时间不超过300ms，支付团队完成联调 | 订单服务接口文档v2、灰度环境上线 | 5月15日 接口联调完成；6月10日 灰度上线 | 风险：历史订单数据迁移可能延期，影响灰度时间；假设：测试环境5月初可用 | 决策：拆分方案采用按业务域拆分，由订单团队负责人拍板；待办：5月8日前输出接口文档，负责人张三 | 张三 | 进行中 | 5月9日 |
| 2025 Q2 | 支付团队 | 接入新订单服务，完成支付链路改造 | 支付成功率不低于改造前水平，联调用例全部通过 | 支付链路改造版本、联调报告 | 5月20日 联调开始；6月20日 全量发布 | 假设：订单团队5月15日前提供稳定接口 | 待办：5月12日前提交联调用例清单，负责人李四 | 李四 | 未开始 | 5月9日 |
| 2025 Q2 | 客户端团队 | 完成支付流程前端改版 | 新流程覆盖全部支付方式，灰度用户无阻断性问题 | 客户端6.2版本 | 6月25日 版本提审 | 风险：应用商店审核周期不可控 | 决策：先灰度10%用户，由客户端团队负责人拍板 | 王五 | 未开始 | 5月9日 |
依赖子表与决策记录填写示例
| 依赖编号 | 规划周期 | 依赖内容 | 提供方团队 | 接收方团队 | 需要时间 | 关联交付物 | 约定方式 | 状态 | 负责人 |
|---|---|---|---|---|---|---|---|---|---|
| Q2-D01 | 2025 Q2 | 提供订单服务接口文档v2与测试账号 | 订单团队 | 支付团队 | 最晚5月8日 | 订单服务接口文档v2 | 联合规划会确认 | 进行中 | 张三 |
| Q2-D02 | 2025 Q2 | 提供稳定可联调的订单服务灰度环境 | 订单团队 | 支付团队 | 最晚5月15日 | 灰度环境上线 | 联合规划会确认 | 未开始 | 张三 |
| Q2-D03 | 2025 Q2 | 提供支付链路改造后的接口说明 | 支付团队 | 客户端团队 | 最晚6月5日 | 支付链路改造版本 | 书面邮件确认 | 未开始 | 李四 |
决策记录写在主表的“决策与待办”列中，与对应团队行放在一起。示例中“拆分方案采用按业务域拆分”是规划会上的取舍结论，“5月8日前输出接口文档”是带负责人和期限的待办。依赖子表中的Q2-D01与主表订单团队的“接口文档v2”对应，Q2-D02对应“灰度环境上线”，两张表通过交付物名称建立关联。复核时先看依赖子表状态，再回到主表更新对应团队的里程碑和风险。
调整与维护方法：按组织规模改字段、按节奏更新
模板需要随团队数量和规划层级调整，否则要么字段过少无法追踪，要么行数过多难以维护。调整时保持字段口径不变，只增减行、列和层级。
按团队规模与规划层级增减字段
| 组织情况 | 调整建议 |
|---|---|
| 3—5个团队，单层规划 | 使用本文主表与依赖子表即可；可省略“约定方式”，在表头统一写明默认在联合规划会确认。 |
| 6—15个团队，存在多个规划小组 | 主表增加“规划小组”列，便于分组筛选；依赖子表增加“升级路径”列，记录依赖逾期时的上报对象。 |
| 多层级规划（团队—项目集—组织） | 主表增加“上级目标”列，把团队目标挂到项目集目标上；依赖子表增加“影响范围”列，标注依赖逾期会影响哪些团队。 |
| 外部供应商或合作方参与 | 在“团队”字段注明内外部属性，依赖子表增加“对接人”列，记录对方接口人。 |
字段只增不改：新增列放在主表末尾，避免打乱已有填写习惯；确需修改字段含义时，在新周期启用新版本，旧周期记录保持原样。
更新频率与复核时点
| 时点 | 动作 | 完成标志 |
|---|---|---|
| 规划会前 | 各团队独立填写目标、成功标准、关键交付物 | 主表必填字段完整 |
| 联合规划会中 | 补齐依赖子表、里程碑和决策记录 | 每条依赖有提供方、接收方和需要时间 |
| 每周或双周 | 负责人更新状态和风险，逾期依赖标注并上报 | 状态列无过期未更新行 |
| 周期中点 | 复核目标是否仍成立，调整里程碑和依赖时间 | 调整有决策记录，相关团队已知会 |
| 周期结束 | 归档本周期记录，复盘未达成项 | 记录只读保存，结论进入下周期规划 |
版本管理与交接约定
每个规划周期使用一份独立记录，文件名包含周期编号，如“跨团队规划记录_2025Q2”。周期内修改保留变更记录，写明修改人、修改时间和原因；负责人变更时，新旧负责人在记录中完成交接，确认未关闭的依赖和待办已转交。归档后的记录不再修改，后续周期引用时以链接或编号指向原记录。
当规划记录需要承载在协作工具中时，可以把主表与依赖子表对应为工作项和关联关系，让目标、交付物、依赖状态在同一处更新。ONES 支持组织架构管理、资源管理与全局进度管控，适用于中大型团队开展敏捷实践；其敏捷研发管理方案打通需求、研发、测试流程，连接需求提出方、产品经理、研发、测试等角色。团队可以把规划记录中的目标与交付物落到需求与子任务上，在迭代计划会上对齐验收标准，通过敏捷看板跟踪状态和风险，周期结束后用报表复盘进度、质量和成本偏差，并用 ONES Wiki 沉淀规划结论，形成可复用的团队知识库。具体字段如何映射到工具，按组织现有工作项结构确定。
常见问题
跨团队规划记录和迭代计划有什么区别，两者需要合并成一张表吗？
跨团队规划记录覆盖一个规划周期内多个团队的目标、依赖和决策，回答的是“各团队在这个周期共同承诺什么、彼此需要什么”；迭代计划聚焦单个团队在一个迭代内要完成的需求和任务拆分。两者可以分开维护：规划记录中的关键交付物和里程碑，作为各团队迭代计划的输入；迭代执行中的进展和问题，按周或双周回写到规划记录的状态和风险字段。团队数量少、规划周期与迭代周期一致时，也可以把规划记录作为上层表，迭代计划作为明细表关联使用。
依赖子表里的依赖条目什么时候可以关闭，关闭后还需要保留记录吗？
依赖条目在接收方确认已收到所需交付物、且该交付物满足约定要求后，可以标记为已完成。关闭时建议在状态字段更新，并在决策与待办中记录确认人和确认时间。记录本身保留到周期归档，便于复盘时统计依赖逾期情况；如果依赖在周期内被取消，状态写“已取消”并注明原因，不直接删除行，避免后续追溯时缺少上下文。
多个团队共同依赖同一个交付物时，模板怎么记录？
一条依赖只对应一个提供方和一个接收方。多个团队需要同一交付物时，拆成多条依赖记录，每条使用独立依赖编号，接收方分别填写，需要时间可以不同。这样每条依赖都能单独跟踪状态和负责人。如果多个接收方的时间要求差异较大，可以在依赖内容中写明交付物的分批范围，例如“第一批接口文档供支付团队联调，第二批供客户端团队对接”，避免一条记录承担多个时间承诺。
规划周期中途目标发生变化，记录应该怎么改？
目标调整需要留下决策依据。建议在原行保留原目标和成功标准，在决策与待办中写明调整原因、拍板人和生效时间，再更新目标字段或新增一行标注“调整后目标”。涉及多个团队的调整，在联合规划会或临时对齐会上确认后同步更新依赖子表中受影响的条目。周期中点复核时集中处理这类变更，避免记录频繁改动导致各团队看到不同版本。
规划记录放在协作工具里时，主表和依赖子表怎么对应？
常见做法是把主表每行对应为一个工作项，承载目标、成功标准、交付物、负责人和状态；依赖子表对应为工作项之间的关联关系或独立依赖条目，记录提供方、接收方和需要时间。ONES 支持组织架构管理、资源管理与全局进度管控，适用于中大型团队开展敏捷实践；其敏捷研发管理方案打通需求、研发、测试流程，连接需求提出方、产品经理、研发、测试等角色。团队可以把规划记录中的目标与交付物落到需求与子任务上，通过敏捷看板跟踪状态和风险，周期结束后用报表复盘，并用 ONES Wiki 沉淀规划结论。具体字段如何映射，按组织现有工作项结构确定。
