跨团队规划记录和跨团队依赖清单的边界，落在“记录什么”和“跟踪什么”上：规划记录沉淀这次跨团队规划形成的共识、决策与承诺，回答后续按什么口径推进；依赖清单逐条管理团队之间的交付关系与状态，回答谁在什么时间点向谁交付什么、目前走到哪一步。两者可以互相引用，但职责不同，混用容易让文档既难读又难跟踪。
要点总览（TL;DR）
- 跨团队规划记录沉淀共识、决策与承诺，回答“按什么口径推进”；跨团队依赖清单逐条管理交付关系与状态，回答“谁在什么时间点向谁交付什么、现在到哪一步”。
- 判断内容归属可以问一句：它描述的是“决定了什么、承诺了什么”，还是“某条交付关系现在处于什么状态”，前者进规划记录，后者进依赖清单。
- 规划记录与依赖清单是引用与来源关系：依赖条目可以从规划会中产生，规划记录可以引用依赖清单的汇总情况，但各自维护各自的内容。
- 规划会议纪要记录讨论过程，规划记录提炼结论与承诺，依赖清单跟踪条目状态，三者产生于同一场规划活动却承担不同职责。
- 常见误区是在规划记录里维护依赖的实时状态，导致结论被冲淡、两份文档状态互相矛盾；状态统一在依赖清单中维护。
一句话说清两者的分工
跨团队规划记录是一份带决策与承诺的规划结论，核心内容是“这次规划达成了什么共识、谁承诺了什么、后续按什么口径推进”。跨团队依赖清单是一份可逐条跟踪的依赖条目集合，核心内容是“哪些团队之间需要彼此交付什么、在什么时间点、由谁跟进、当前状态如何”。
两者的关系是引用与来源，而非互相替代。规划会上确认的依赖事项，可以作为条目进入依赖清单；依赖清单的汇总情况，也可以被规划记录引用，作为承诺兑现情况的依据。但规划记录不会因为引用了依赖清单就变成跟踪工具，依赖清单也不会因为来源于规划会就承担记录决策的职责。
判断一份内容该放哪里，可以用一个简单问题：它描述的是“我们决定了什么、承诺了什么”，还是“某条交付关系现在处于什么状态”。前者进规划记录，后者进依赖清单。
跨团队规划记录包括什么、不包括什么
规划记录的价值在于把一次跨团队规划从讨论变成可回看的结论。它面向的是参与规划的各方负责人和后续执行者，读者需要从中快速知道共识是什么、边界在哪里、出了分歧按什么依据处理。
应进入规划记录的内容包括：
- 目标与范围共识：本次规划覆盖哪些团队、共同目标是什么、明确不做什么。
- 关键决策与取舍理由：在资源、优先级、交付节奏上做了哪些选择，为什么这样选，当时考虑了哪些约束。
- 各团队承诺的交付：每个团队承诺在规划周期内交付什么结果，以结果或里程碑描述，而非逐日任务。
- 风险与假设：规划成立所依赖的前提，以及已识别的主要风险和对策方向。
- 后续跟进责任：谁负责推动规划落地、下一次检视在什么时点、以什么方式确认承诺兑现。
不属于规划记录的内容包括：逐条依赖的实时状态、单迭代内的日常执行明细、项目集日常协同中的排期调整。这些内容变化频繁，放进规划记录会让结论被大量过程信息淹没，也会导致同一信息在两处维护、彼此不一致。
规划记录与规划会议纪要也需要区分。纪要是过程留痕，按时间顺序记录谁参加了、讨论了什么、有哪些分歧；规划记录是结论与承诺的结构化沉淀，按主题组织，突出已达成的一致和明确的责任。纪要可以作为规划记录的输入，但两者不能互相替代。
跨团队依赖清单包括什么、不包括什么
依赖清单的职责是让每一条跨团队依赖都能被指派、被查看、被推进。它以条目为单位组织，条目数量随执行进展增减，状态随实际情况更新。
一条可跟踪的依赖条目通常包含以下要素：
| 要素 | 说明 |
|---|---|
| 提供方与接收方 | 明确哪一方交付、哪一方接收，避免双方都以为对方在推进 |
| 依赖内容 | 具体交付物或接口、文档、环境等，描述到可验收的程度 |
| 需要的时间点 | 接收方需要该交付的最晚时间，以及提供方计划完成的时间 |
| 当前状态 | 如待确认、已承诺、进行中、已交付、有风险、已取消 |
| 跟进人 | 对条目状态更新和风险升级负责的人 |
依赖清单关注条目状态与流转，随执行持续更新，出现阻塞时及时升级。它不承载规划层面的目标取舍、决策理由和团队整体承诺。这些内容属于规划记录，依赖清单只需引用相关规划结论，不必重复论证。
在工具承载上，规划结论可以沉淀为文档，依赖条目则作为工作项逐条跟踪，形成从共识到跟踪的连续流程。以 ONES 为例，迭代规划中产品负责人可按优先级将需求规划至迭代，并在迭代计划会议上与团队评审；对需求与验收标准达成一致后，设计、研发、测试人员可用子任务拆分需求，便于后续处理和跟踪；迭代结束后还可用 ONES Wiki 沉淀经验。跨团队场景下，可参照这一思路：把规划共识写入文档，把需要逐条推进的交付关系拆成可指派、可更新状态的工作项，让文档负责结论、工作项负责流转。
规划记录、依赖清单与规划会议纪要怎么区分
这三个概念常被混为一谈，原因在于它们往往产生于同一场规划活动。把它们放在一起对照，各自的回答对象和产出时点会更清楚。
| 文档 | 回答的问题 | 内容性质 | 产出时点 | 更新频率 |
|---|---|---|---|---|
| 规划会议纪要 | 会上讨论了什么、谁说了什么 | 过程记录 | 会议进行中或会后即时 | 一次成型，基本不改 |
| 跨团队规划记录 | 达成了什么共识、承诺了什么、按什么口径推进 | 结论与承诺 | 会议结束后整理确认 | 规划周期内按需修订，变更需留痕 |
| 跨团队依赖清单 | 有哪些依赖、现在到哪一步、谁在跟进 | 条目与状态 | 规划会中识别，会后持续补充 | 随执行持续更新 |
三者的产生顺序通常是：会议纪要记录讨论过程，规划记录从中提炼共识与承诺，依赖清单把承诺中涉及跨团队交付的部分拆成可跟踪条目。引用关系上，规划记录可以引用依赖清单的汇总情况，依赖清单可以标注来源规划记录，但各自维护各自的内容，避免同一信息在两处反复修改。
一个跨团队规划的例子与常见误解
以下为演示情景，用于说明内容如何分流，不代表真实案例。
假设支付团队和订单团队共同参加一次跨团队规划会。会上双方确认：本季度共同目标是让新支付方式在订单侧上线；支付团队承诺在第六周前提供接口文档和测试环境，订单团队承诺在第八周前完成接入并联调；双方约定每两周同步一次进展，由两位负责人共同跟进。讨论中，订单团队提出需要支付团队在第四周前先给出字段定义，否则接入工作无法启动。
按边界分流，内容应这样落位：
- 进入规划记录：共同目标与范围、第六周和第八周的交付承诺、每两周同步的跟进机制、字段定义能否提前这一取舍及其理由、接口按期交付这一假设及对应风险。
- 进入依赖清单：一条“支付团队向订单团队提供字段定义，需要时间点为第四周”的条目，一条“支付团队向订单团队提供接口文档和测试环境，需要时间点为第六周”的条目，各自标注提供方、接收方、状态和跟进人。
- 留在会议纪要：会上谁提出了字段定义的顾虑、讨论了几种方案、最终如何拍板的过程。
围绕这个例子，有三类常见误解值得纠正。
误解一：把依赖清单当成规划记录的全部。依赖清单只说明有哪些交付关系，无法说明为什么这样安排、放弃了哪些选项。缺少规划记录，后续出现资源冲突时就没有判断依据。
误解二：在规划记录里维护依赖的实时状态。规划记录一旦承担状态跟踪，就会随执行频繁改动，结论部分被不断冲淡，且与依赖清单形成两份互相矛盾的状态记录。正确做法是规划记录只写承诺和时间点，状态统一在依赖清单中维护。
误解三：只留会议纪要，缺少承诺与决策的结构化记录。纪要按时间顺序记录讨论，读者难以快速找到最终共识和责任归属。规划记录把结论按主题整理出来，才能支撑后续检视和交接。
把这三类误解反过来看，边界就清晰了：规划记录管结论与承诺，依赖清单管条目与状态，会议纪要管过程留痕。三者各司其职，通过引用保持关联，跨团队规划的执行才有稳定的依据。
常见问题
规划周期中途目标发生调整，规划记录和依赖清单分别怎么处理？
目标调整属于规划层面的决策变化，应先在规划记录中修订，保留变更痕迹，说明调整原因和影响范围。依赖清单随后跟进：受影响条目的时间点、内容或状态需要相应更新，不再成立的条目可以取消并注明原因。
顺序上先改结论、再改条目，避免依赖清单先动而规划记录还停留在旧口径，造成两份文档对不上。
依赖清单里的条目状态，需要定期汇总回规划记录吗？
需要，但汇总的是结论而非明细。规划记录可以在检视节点引用依赖清单的整体情况，例如“本期识别的跨团队依赖中，按期交付几条、存在风险几条、已取消几条”，用来支撑承诺兑现情况的判断。
逐条状态仍留在依赖清单中维护，规划记录只保留汇总结论和必要的说明，避免同一信息在两处反复修改。
规划会上临时提出的依赖，还没确认时间点，应该先记在哪里？
可以先进依赖清单，状态标为待确认，并指定跟进人负责在约定时间内补齐提供方、接收方和时间点。这样条目不会在讨论中被遗漏，也不会因为信息不全就写进规划记录、被误当成已承诺事项。
待确认条目补齐信息并经双方确认后，再视其重要性决定是否在规划记录中体现为承诺。
团队规模较小、跨团队依赖不多时，还需要把两份文档分开维护吗？
可以合并载体，但职责仍要分清。例如在一份规划文档中，前半部分写共识与承诺，后半部分用表格列依赖条目并持续更新状态。
合并的前提是读者能一眼区分哪部分是结论、哪部分是跟踪信息。依赖条目增多或参与团队变多后，建议拆开维护，否则频繁的状态更新会不断冲淡规划结论。
规划记录中的承诺和依赖清单中的条目如何对应，避免各说各话？
常用做法是让依赖条目标注来源，例如注明来自哪次规划、对应哪条承诺；规划记录在承诺处引用相关依赖条目的编号或链接。
对应关系建立后，检视时可以从承诺追到条目状态，也可以从阻塞条目回溯到当初的规划依据。对应关系不必追求一一覆盖，团队整体承诺中不涉及跨团队交付的部分，留在规划记录中即可。
