项目间依赖指的是一个项目的交付物、决策、资源或时间节点，成为另一个项目能否按计划推进的前提条件。它发生在两个或多个项目之间，双方往往分属不同团队、不同负责人，甚至不同预算主体。本文给出可直接引用的定义，划清它与单项目任务依赖、普通跨部门协作的边界，说明依赖的组成要素与传导机制，并整理项目集层面登记和跟踪依赖所需的字段与流程。
要点总览（TL;DR）
- 项目间依赖是指一个项目的交付物、决策、资源或时间节点，成为另一个项目按计划推进的前提条件；判断标准是提供方延期或改变交付口径时，接收方是否需要修改自己的计划。
- 它与单项目任务依赖的区别在管理主体，与普通跨部门协作的区别在约束力：前者由项目集或项目组合层面协调，后者是配合关系而非计划前提。
- 一条可管理的依赖需要写清提供方、接收方、依赖物、承诺时间与验收口径五个要素，状态按提出、确认、交付、关闭流转。
- 项目集层面应在规划对齐和变更评审两个时点识别依赖，登记双方项目、责任人、承诺日期、影响说明与升级路径，并在例会上固定跟踪已确认未交付的条目。
- 依赖需要登记跟踪，风险是在依赖之上附加的概率与影响判断，两者不能互相替代；依赖也不只在启动时识别，变更会持续产生新依赖。
项目间依赖的准确定义
项目间依赖是指：项目A的某项产出或某个决定，构成项目B按既定计划推进的必要前提，若A不能按约定提供，B的范围、进度或成本将被迫调整。这个定义包含四个要素，缺一不可。
- 依赖方（接收方）：计划受影响的项目，它的某项工作要等对方提供的东西到位才能开始或完成。
- 被依赖方（提供方）：承担交付义务的项目，它需要按约定时间、约定口径交出依赖物。
- 依赖物：可以是可交付成果（接口文档、数据模型、测试环境、组件版本），可以是决策（技术选型批复、预算审批、上线窗口确认），可以是资源（人员、设备、许可证），也可以是时间窗口（联调期、发布档期、停机维护时段）。
- 成立条件：提供方的产出必须实际影响接收方的计划安排。仅仅“两个项目有关联”“双方在同一个群里沟通”，不构成依赖。
判断某个关系是否属于项目间依赖，可以用一句话检验：如果提供方延期或改变交付口径，接收方是否需要修改自己的计划？答案是肯定的，就是依赖；答案是否定的，只是相关。
哪些关系算项目间依赖，哪些不算
项目间依赖容易被泛化，把一切跨项目、跨团队的往来都算进去，反而让真正需要跟踪的依赖被淹没。下面按相邻情形逐一划界。
| 情形 | 是否属于项目间依赖 | 判断依据 |
|---|---|---|
| 同一项目内“开发完成后才能测试” | 不算 | 发生在单个项目内部，由项目内的任务排期和任务依赖管理，不涉及两个项目的交付约定 |
| 两个项目定期开同步会、共享进展信息 | 不算 | 属于信息同步，没有一方对另一方的交付承诺，任何一方调整计划不影响对方计划成立 |
| 两个项目共用一名架构师，但未约定投入时间 | 暂不算，需升级为资源依赖才纳入 | 共享资源本身是资源冲突；只有当双方就“何时、投入多少、交付什么”形成约定，才转化为可跟踪的依赖 |
| 上游项目交付接口，下游项目据此开发 | 算 | 典型的上下游依赖，交付物和承诺时间是明确的 |
| 两个并行项目都要用同一套测试环境，且档期冲突 | 算（资源与时间窗口依赖） | 一方的占用安排直接决定另一方能否按期开展测试 |
与单项目任务依赖相比，关键差别在管理主体：任务依赖由项目经理在项目内排定，项目间依赖的双方没有共同的直接上级，需要项目集或项目组合层面的角色介入协调。与普通跨部门协作相比，关键差别在约束力：日常协作是“配合”，项目间依赖是“前提”，前者做不好影响体验，后者做不好直接改变对方的计划基线。
上下游项目与并行项目是两种常见形态。上下游依赖沿交付链条单向传导，识别相对容易；并行项目的依赖多来自共享资源和时间窗口，往往在排期冲突时才暴露，需要在规划阶段主动比对。
项目间依赖的组成与传导机制
一条可管理的依赖记录，需要把五个要素写清楚，否则跟踪时无从判断状态。
| 要素 | 说明 | 缺失后的后果 |
|---|---|---|
| 提供方 | 承担交付义务的项目及具体责任人 | 出问题时找不到对接人 |
| 接收方 | 计划受影响的项目及使用方 | 无法评估影响范围 |
| 依赖物 | 具体的交付物、决策、资源或时间窗口 | “等对方准备好”这类模糊表述无法验收 |
| 承诺时间 | 提供方承诺交付的日期，以及接收方最晚可接受的日期 | 双方对“来得及”的理解不一致 |
| 验收口径 | 交付到什么程度算完成，由谁确认 | 交付了但不可用，依赖实际未解除 |
依赖的传导沿依赖链发生。假设项目A的接口交付延期两周，项目B的联调随之后移，而项目B的联调又处在项目C上线前的关键路径上，一次延期会经过两级放大，最终影响项目C的发布档期。链越长、环节越多，单点延期的累积效应越明显，这也是项目间依赖需要专门管理、而不能靠双方私下沟通解决的原因。
一条依赖通常经历四个状态：提出（接收方识别需求并登记）、确认（提供方认可依赖物、时间和验收口径）、交付（提供方按约定提交，接收方验收）、关闭（确认依赖解除，接收方计划可正常推进）。状态停留在“提出”过久，说明双方尚未达成共识，应视为风险信号。
依赖失效的常见后果包括：接收方关键路径被迫重排、资源闲置等待、上线窗口错过、合同交付节点违约。更隐蔽的后果是团队为规避不确定性而自行搭建临时替代方案，造成重复投入，这部分成本往往不被记录。
项目集层面如何登记与跟踪项目间依赖
项目间依赖的管理动作落在项目集或项目组合层面，由项目集经理或PMO承担协调职责，项目经理负责本侧信息的准确上报。识别时点有两个：规划阶段对齐各项目里程碑时集中梳理，以及执行中发生范围变更、资源调整、优先级变化时增量补充。后者更容易被忽略，建议把“是否产生新的跨项目依赖”列为变更评审的固定问题。
登记时至少包含以下字段，形成一条可跟踪的记录：
- 依赖编号与简述
- 提供方项目、接收方项目
- 双方责任人
- 依赖物描述与验收口径
- 提供方承诺日期、接收方最晚可接受日期
- 当前状态（提出／已确认／已交付／已关闭）
- 影响说明：若延期，接收方哪些里程碑受影响
- 升级路径：超过约定日期未交付时的上报对象
跟踪节奏上，建议在项目集例会上固定过一遍“已确认未交付”的依赖，重点看承诺日期临近和已逾期的条目；状态变更时同步更新记录，避免依赖清单与实际脱节。升级机制要事先约定：当提供方预计无法按期交付时，由谁在多长时间内上报，由谁决定调整接收方计划还是调配资源保提供方。关闭依赖需要证据，通常是接收方对交付物的验收确认，仅有提供方“已发出”的记录不足以关闭。
在工具承载上，跨项目依赖的登记与状态跟踪需要项目集层面的统一视图。ONES Plan 支持借助项目集管理总览多项目信息，支持查看多项目数据集合、多维度掌控项目进度，也支持自定义项目属性以区分不同类型的项目，这些能力可以作为依赖清单和状态字段的承载基础；依赖关系本身是否以专门对象或字段形式提供，建议在选型或实施时结合实际版本核验。若项目执行层使用 ONES Project，ONES Plan 支持监控及规划其中的相关项目和迭代，查看工作量和进度，便于在同一个视图里比对提供方与接收方的排期。
具体例子与常见误解
以下为演示情景，用于说明依赖的识别、传导与处置过程，不代表真实案例。
某公司同时推进“客户数据平台升级”（项目甲）和“移动端改版”（项目乙）。项目乙计划在6月完成新版首页，其中用户画像模块需要调用项目甲提供的新版标签查询接口。规划阶段对齐里程碑时，项目集经理识别出这条依赖：提供方为项目甲，接收方为项目乙，依赖物是标签查询接口及联调文档，项目甲承诺5月10日交付，项目乙最晚可接受5月20日，验收口径为接口在测试环境通过项目乙的联调用例。
执行到4月底，项目甲因数据迁移比预期复杂，预计接口交付推迟到5月25日。由于这条依赖已登记并有承诺日期，项目集经理在例会上提前发现，评估后确认项目乙的联调无法在窗口内完成，遂做出两个处置：一是协调项目甲优先交付只读查询接口，覆盖项目乙首版所需的核心字段；二是将项目乙非核心的画像标签延后到下一迭代。最终项目乙按期上线，代价是部分功能分期交付。若这条依赖未被登记，项目乙很可能在5月中旬才开始追问接口，届时只剩被动延期一种选择。
围绕这个场景，有几个高频误解需要澄清：
- 把相关当依赖。两个项目都涉及客户数据，不等于互为依赖。只有一方的产出实际约束另一方的计划，才需要登记。
- 把依赖当风险。依赖是客观存在的前提条件，风险是对它可能无法满足的评估。依赖本身要登记跟踪，风险是在依赖之上附加的概率与影响判断，两者不能互相替代。
- 认为依赖只在启动时识别。规划阶段的梳理只覆盖当时已知的关系，范围变更、资源调整、优先级切换都会产生新依赖，需要在变更评审中持续补充。
- 认为双方口头说好即可。没有承诺日期和验收口径的口头约定，在任一方计划调整时缺乏约束力，也无法在例会上判断状态。
把定义、边界、要素和跟踪字段放在一起看，项目间依赖的管理本质是把跨项目的口头前提转化为有责任人、有日期、有验收标准、有状态流转的记录，并在项目集层面持续维护这份记录。
常见问题
项目间依赖和项目集里的关键路径是什么关系？
依赖是构成关系，关键路径是排期结果。项目间依赖描述的是“谁等谁、等什么、什么时候等到”，关键路径则是在所有任务和依赖确定之后，算出哪条链路决定整体工期。一条跨项目依赖如果落在接收方的关键路径上，它的延期会直接推迟接收方的里程碑；如果只影响非关键路径上的工作，延期可能被浮动时间吸收。因此登记依赖时，除了记录承诺日期，还应标注它影响接收方的哪些里程碑，这决定了该依赖在跟踪时的优先级。
依赖已经登记，但提供方一直不确认承诺日期，该怎么处理？
状态长期停留在“提出”，本身就是需要升级的信号。可以先明确接收方的最晚可接受日期，把“最晚什么时候必须拿到”作为硬约束摆到台面上，再请提供方在该日期之前给出可交付的时间点。若提供方仍无法确认，应由项目集经理或PMO按事先约定的升级路径上报，由更高层在调整接收方计划、调配资源保提供方、缩减依赖物范围三者之间做取舍。关键是把模糊的等待转化为有截止时间的决策，避免接收方在临近节点时才被动应对。
两个项目共用一套环境或一位专家，什么情况下应登记为依赖？
共享本身是资源冲突，登记为依赖需要双方形成具体约定：谁在什么时间段使用、投入多少、交付什么结果。约定一旦形成，就按资源与时间窗口依赖登记，写清占用档期和交接口径。若只是知道彼此都在用，没有时间与数量的约定，可以先作为资源冲突在项目集层面协调排期，暂不进入依赖清单。判断的分界在于：一方的安排是否直接决定另一方能否按期开展自己的工作。
依赖关闭需要什么证据，提供方发出交付物就算完成吗？
仅有提供方“已发出”的记录不足以关闭依赖。关闭应以接收方的验收确认为准，即交付物达到登记时约定的验收口径，接收方确认自己的后续工作可以正常推进。实际操作中，可以在登记时就写明验收方式和确认人，交付后由接收方在依赖记录上确认，再变更状态为已关闭。这样做的目的是避免出现“交付了但不可用”的情况，让依赖清单反映真实的计划前提是否已经满足。
项目执行层用 ONES Project，项目集层面怎么统一看跨项目依赖？
ONES Plan 支持借助项目集管理总览多项目信息，支持查看多项目数据集合、多维度掌控项目进度，也支持自定义项目属性以区分不同类型的项目，可以作为依赖清单和状态字段的承载基础。ONES Plan 还支持监控及规划 ONES Project 中相关项目和迭代，查看工作量和进度，便于在同一视图里比对提供方与接收方的排期。依赖关系是否以专门对象或字段形式提供，建议在选型或实施时结合实际版本核验。
