跨项目依赖清单和单项目任务依赖清单记录的是两种不同层级的承诺。前者管两个或多个项目之间的交付接口，后者管同一项目内任务之间的先后顺序。判断一条依赖该归哪边，可以看三个分界点：依赖两端是否分属不同项目、交付物是否需要跨项目验收、变更是否需要项目集层面协调。三项中有一项成立，就应进入跨项目依赖清单；三项都不成立，留在单项目任务依赖清单。下面先给判断口径，再用统一维度对照两份清单，最后给出字段模板和维护节奏。
要点总览（TL;DR）
- 判断一条依赖归哪类清单，看三个分界点：依赖两端是否分属不同项目、交付物是否需要跨项目验收、变更是否需要项目集层面协调；任一成立即进入跨项目依赖清单。
- 跨项目依赖清单记录项目之间的交付承诺，责任人是项目接口人，状态按已承诺、已交付、已验收推进；单项目任务依赖清单记录项目内任务先后关系，责任人是任务负责人。
- 两份清单是汇总与执行的关系：跨项目依赖在上游项目内仍需拆成任务，由单项目任务依赖清单承接，通过依赖编号和交付物编号关联。
- 同一交付物被多个项目依赖时，按“交付物—接收方”拆成多条记录，各下游项目的验收结论独立记录。
- 单项目为主的团队可先在任务清单中标注外部依赖，当交付物被两个以上项目依赖或变更需跨项目协调时，再提升到跨项目清单。
两类清单的核心区别：一条依赖到底归谁管
跨项目依赖清单记录的是项目之间的交付承诺：一个项目的产出成为另一个项目的输入。条目归属项目集或协同层，责任人是项目接口人，状态围绕“已承诺、已交付、已验收”推进。它回答的问题是“哪个项目欠哪个项目什么、什么时候交、谁来接”。
单项目任务依赖清单记录的是同一项目内任务之间的先后关系。条目归属单个项目计划，责任人是任务负责人，状态围绕“未开始、进行中、完成”推进。它回答的问题是“这个项目里哪项任务必须先做、哪项任务可以随后启动”。
把一条具体依赖放到这两类清单之间做归属判断，可以依次问三个问题：
- 依赖两端是否落在不同项目。上游交付方和下游接收方如果分属两个项目，这条依赖就跨出了单项目边界。即使两个项目同属一个部门、由同一位负责人管理，只要项目立项是分开的，交付关系就应按跨项目记录。
- 交付物是否需要跨项目验收。上游项目产出的接口文档、数据表、组件、环境或方案，需要下游项目确认“可接收、可使用”，就构成跨项目验收。验收结论由下游项目给出，不能只在上游项目内部标记完成。
- 变更是否需要项目集层面协调。交付日期调整会影响下游项目的排期、资源或上线窗口，或者需要项目集负责人重新排优先级，这类变更就超出了单个项目能自行决定的范围。
三项只要有一项成立，就应进入跨项目依赖清单；三项全部落在同一项目内，留在单项目任务依赖清单。这个口径的好处是可以用一条依赖的具体事实来判断，不依赖组织习惯或口头约定。
同口径差异对照：字段、责任人与状态流转
两份清单容易混淆，是因为它们都叫“依赖清单”，都涉及先后关系。放到同一组维度下对照，差异会清楚很多。下表按记录范围、条目粒度、责任人角色、状态取值、变更触发条件、汇报对象六个维度展开。
| 对照维度 | 跨项目依赖清单 | 单项目任务依赖清单 |
|---|---|---|
| 记录范围 | 两个或多个项目之间的交付接口，归属项目集或协同层 | 单个项目内的任务先后关系，归属该项目计划 |
| 条目粒度 | 一条依赖对应一个可验收的交付物或交付承诺 | 一条依赖对应任务与任务之间的前置/后置关系 |
| 责任人角色 | 项目接口人，负责承诺、交付和对接验收 | 任务负责人，负责本任务按顺序完成 |
| 状态取值 | 已承诺、已交付、已验收，可附延期或取消标记 | 未开始、进行中、完成，可附阻塞标记 |
| 变更触发条件 | 交付日期、交付范围或接收方变化，影响下游项目排期 | 任务顺序、任务工期或负责人变化，影响本项目计划 |
| 汇报对象 | 项目集负责人或跨项目协同例会 | 项目经理或项目内站会 |
字段层面，两份清单可以共用一部分基础信息：依赖编号、标题、提出日期、当前状态、备注。这些字段用于检索和追溯，格式统一能减少维护成本。必须分开维护的是与责任和验收相关的字段：跨项目依赖需要上游项目、下游项目、交付物、接收方、承诺日期、接口人和验收结论；单项目任务依赖需要前置任务、后置任务、任务负责人和计划完成时间。把跨项目的验收结论塞进任务状态里，会让任务完成和交付验收混为一谈；反过来，把任务级的前置关系全部提升到项目集，也会让跨项目清单变得臃肿、失去协调价值。
边界上的灰色地带：跨项目依赖如何回落到任务层
实际工作中最常见的争议是：一条依赖已经记入跨项目清单，上游项目内部还要不要拆任务？答案是两层清单承担不同职能，跨项目清单负责汇总和协调，单项目任务依赖清单负责执行落地。上游项目需要把“向某项目交付某物”拆成本项目内的具体任务，并用任务依赖标明先后顺序；跨项目清单只保留交付承诺和验收结论，不替代项目内的任务排期。
同一交付物被多个项目依赖时，建议在跨项目清单中按“交付物—接收方”拆成多条记录，共用同一个交付物编号和上游接口人。这样每个下游项目的验收结论独立记录，上游项目的交付进度也能按接收方分别跟踪。如果合并成一条记录，容易出现一个下游已验收、另一个下游仍在等待，状态却无法表达的情况。
依赖取消或延期时，两层清单需要联动更新，规则可以固定为三步：
- 跨项目清单先更新状态和承诺日期，记录变更原因和影响的下游项目。
- 上游项目同步调整内部任务的前置关系或工期，确保任务计划与新承诺日期一致。
- 下游项目确认接收计划是否受影响，必要时在跨项目协同例会上重新排优先级。
联动更新的关键是明确触发人：跨项目清单由接口人更新，项目内任务由任务负责人更新，项目集负责人确认变更影响。缺少这一步，两份清单会在几周内出现日期不一致、状态对不上的情况。
在工具承载上，如果组织使用 ONES，项目集层面的多项目总览可以用来汇总跨项目交付承诺和进度，项目内的任务依赖则在具体项目中维护。ONES Plan 支持借助项目集管理总览多项目信息，支持自定义项目属性管理不同类型项目，并可查看多项目数据集合、多维度掌控项目进度；它与 ONES Project 数据互通，可监控及规划相关项目和迭代。跨项目依赖清单的具体字段结构和状态流转方式，需要结合组织实际配置在版本中确认。
落地做法：清单字段设计与维护节奏
两份清单的字段设计应围绕“谁承诺、交付什么、何时交、谁接收、是否验收”展开。跨项目依赖清单建议保留以下字段：
- 依赖编号：全局唯一，便于在例会和文档中引用。
- 上游项目与交付物：写明交付方项目和具体交付物名称，交付物应可验收。
- 下游项目与接收方：写明接收方项目和接口人，避免只写项目名。
- 承诺日期：上游承诺的交付时间，变更时保留原日期和变更原因。
- 接口人：上游和下游各一名，负责对接和状态更新。
- 状态：已承诺、已交付、已验收，可附延期或取消标记。
- 验收结论：下游确认可接收的结论和日期，未验收时留空。
单项目任务依赖清单保留的字段相对精简：任务编号、任务名称、前置任务、后置任务、任务负责人、计划开始与完成时间、任务状态、阻塞说明。任务级清单不需要记录跨项目验收结论，验收信息回填到跨项目清单即可。
维护节奏可以按节点固定下来：接口人在承诺日期变更当天更新跨项目清单；任务负责人在任务状态变化时更新项目内清单；项目集负责人每周或每两周在协同例会上对齐一次跨项目清单，重点看临近承诺日期和已延期条目；每个交付物验收后，由下游接口人回填验收结论。频率不必一刀切，交付链路长、下游项目多的组织可以每周对齐，项目间交付较少的团队可以按里程碑对齐。
适配场景与选择建议
单项目为主、项目间交付较少的团队，不必一开始就建立完整的跨项目依赖清单。可以先在单项目任务依赖清单中标注“外部依赖”字段，记录对接项目和接口人；当同一交付物开始被两个以上项目依赖，或交付日期变更需要跨项目协调时，再把相关条目提升到跨项目清单。这样既保留了轻量维护，也不会在需要协调时缺少记录。
多项目并行、共享资源与交付链路的组织，适合建立独立的跨项目依赖清单，并明确项目集负责人、上下游接口人和对齐节奏。清单条目不宜过细，保持在可验收的交付物层面；项目内的任务拆分和排序仍由各项目自己维护。两份清单通过依赖编号和交付物编号关联，形成“汇总—执行”的对应关系。
与相邻主题的分工也需要说清楚：单项目任务排期与依赖排序的具体方法，属于项目计划主题，本文只说明任务依赖清单记录什么、与跨项目清单如何衔接；普通部门间协作流程设计属于跨部门协作主题，本文不展开审批流和协作机制设计。把边界划清，两份清单各司其职，跨项目协调才有稳定的信息基础。
常见问题
两个项目由同一位负责人管理，它们之间的依赖还需要记入跨项目依赖清单吗？
需要。归属判断看的是项目立项是否分开，与负责人是否同一人无关。只要上游交付方和下游接收方分属两个立项项目，交付关系就跨出了单项目边界，应按跨项目记录。同一位负责人管理两个项目时，可以在协调环节简化流程，但清单条目仍应保留，否则下游项目的验收结论和承诺日期没有独立记录的位置。
跨项目依赖已经记入项目集清单，上游项目内部还需要拆任务吗？
需要。两层清单承担不同职能：跨项目清单负责汇总交付承诺、跟踪验收结论和协调变更；单项目任务依赖清单负责执行落地。上游项目应把“向某项目交付某物”拆成本项目内的具体任务，并用任务依赖标明先后顺序。跨项目清单只保留交付物、承诺日期、接口人和验收结论，不替代项目内的任务排期。
依赖延期时，两份清单的更新顺序是什么？
建议按三步联动：先由接口人更新跨项目清单的状态和承诺日期，记录变更原因和受影响的下游项目；再由上游项目任务负责人调整内部任务的前置关系或工期，使任务计划与新承诺日期一致；最后由下游项目确认接收计划是否受影响，必要时在跨项目协同例会上重新排优先级。触发人明确，两份清单才不会出现日期和状态对不上的情况。
项目间交付很少的团队，需要一开始就建跨项目依赖清单吗？
不必。可以先在单项目任务依赖清单中增加“外部依赖”字段，记录对接项目、接口人和预计交付时间。当同一交付物开始被两个以上项目依赖，或交付日期变更需要跨项目协调时，再把相关条目提升到跨项目清单。这样前期维护成本低，需要协调时也有现成记录可以迁移。
跨项目依赖清单和跨部门协作流程是什么关系？
两者关注的对象不同。跨项目依赖清单管的是项目之间的交付承诺，核心是交付物、承诺日期和验收结论；跨部门协作流程管的是部门之间的审批、沟通和职责分工。一条依赖可能同时涉及跨部门和跨项目，此时交付承诺记入跨项目依赖清单，审批和协作机制按跨部门协作流程执行，两份记录各管一段，不互相替代。
