跨项目依赖清单以“依赖关系”为记录单位，一行写清一个项目对另一个项目的某项交付、决策或资源的等待关系。本文给出一张可直接复制到表格工具的空白清单，逐列说明填写口径，区分必填与选填字段，并用一条完整记录示范从提出到关闭的填写过程，帮助不同项目按同一口径登记和跟踪依赖。
要点总览（TL;DR）
- 跨项目依赖清单以“依赖关系”为记录单位，一行写清接收方项目等待提供方项目的某个交付物、决策或资源。
- 最小可用字段集包括依赖编号、提供方项目、接收方项目、依赖对象、需要时间、状态和双方负责人；影响描述在项目集规模较大时建议必填。
- 需要时间与承诺时间分开填写，两者不一致时直接暴露排期冲突，并据此判断是否升级到项目集层面协调。
- 清单按周更新，交付验收后改为“已验收”，不再需要的改为“已取消”并保留记录，便于复盘依赖履约情况。
- 依赖记录需要跨项目集中查看时，可用项目集管理工具承载，模板本身也可放入文档库与项目文档一起维护。
可复制空白模板：跨项目依赖清单表
下表可直接复制到 Excel、在线表格或项目集管理工具中。使用时先保留表头，按项目数量逐行增加记录。每一行对应一条跨项目依赖，即“接收方项目等待提供方项目给出某个对象”这一条关系；同一个项目之间的多个任务排期不进入此表。
| 依赖编号 | 提供方项目 | 接收方项目 | 依赖对象 | 依赖类型 | 需要时间 | 承诺时间 | 影响描述 | 接收方负责人 | 提供方负责人 | 状态 | 升级标记 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
状态列建议使用固定可选值，避免各项目自造词导致无法汇总：待确认、已承诺、进行中、已交付、已验收、已取消。升级标记使用“是/否”两值，表示该依赖是否需要提交到项目集层面协调。依赖类型可从交付物、决策、资源三类中选择，便于后续按类型统计瓶颈。
字段说明：每一列记录什么信息
字段口径统一，清单才能跨项目汇总。以下逐列说明每个字段记录什么、按什么标准填写。
| 字段 | 记录内容 | 填写口径 |
|---|---|---|
| 依赖编号 | 该条依赖的唯一标识 | 建议采用“接收方项目缩写-序号”，如 CRM-003，便于检索和引用 |
| 提供方项目 | 给出交付、决策或资源的一方 | 写项目正式名称，不写个人姓名；个人放在提供方负责人列 |
| 接收方项目 | 等待该对象的一方 | 与提供方分列，保证从任一方向都能筛选出相关依赖 |
| 依赖对象 | 具体等待的交付物、决策或资源 | 写可识别、可验收的对象，如“支付接口联调环境”“数据迁移方案评审结论”“两名测试人员两周投入” |
| 依赖类型 | 交付物、决策、资源 | 按对象性质选择，用于分类统计和安排协调方式 |
| 需要时间 | 接收方最晚需要该对象的时间 | 由接收方根据自身节点倒推填写，表达“什么时候要” |
| 承诺时间 | 提供方确认可以给出的时间 | 由提供方填写，表达“什么时候能给”；与需要时间不一致时，差异本身就是协调议题 |
| 影响描述 | 该依赖对接收方项目节点的影响 | 写清受影响的具体里程碑或交付，如“影响 6 月 20 日上线联调，延期将压缩两周测试窗口” |
| 接收方负责人 | 跟踪该依赖的接收方人员 | 负责确认需求、验收交付、更新状态 |
| 提供方负责人 | 承诺并交付该对象的提供方人员 | 负责给出承诺时间并推进交付 |
| 状态 | 依赖当前所处阶段 | 从固定可选值中选择，每次变化记录更新日期 |
| 升级标记 | 是否需要项目集层面协调 | 当承诺时间晚于需要时间、或状态长期停滞时标为“是” |
| 备注 | 补充信息 | 记录变更原因、替代方案、验收结论等 |
需要时间与承诺时间分开，是这张表区别于普通任务列表的关键。前者代表接收方的业务约束，后者代表提供方的实际能力，两者并列才能暴露排期冲突。影响描述要写到具体节点，笼统写“影响进度”无法支撑优先级判断。
必填与选填：先保证清单可用
清单刚建立时，字段过多会增加填写负担，导致记录不全。建议先用最小可用字段集把依赖关系登记起来，再按治理需要补充增强字段。
| 类别 | 字段 | 取舍理由与缺失后果 |
|---|---|---|
| 必填 | 依赖编号、提供方项目、接收方项目、依赖对象、需要时间、状态 | 缺少任何一项，这条记录都无法被定位、跟踪或汇总；没有提供方与接收方，依赖关系不成立 |
| 必填 | 接收方负责人、提供方负责人 | 没有责任人，状态更新和协调无人推动 |
| 建议必填 | 影响描述 | 决定优先级排序的依据；项目集规模超过三五个项目时，不建议省略 |
| 选填 | 承诺时间 | 依赖刚提出、提供方尚未评估时可暂空，进入“已承诺”状态后补填 |
| 选填 | 依赖类型 | 依赖数量较少时可不填；需要按类型分析瓶颈时启用 |
| 选填 | 升级标记、备注 | 用于例外管理和过程留痕，按需填写 |
项目集规模较小时，一张表即可覆盖全部依赖，字段以必填项加影响描述为主。项目数量增多、跨团队协调频繁后，再启用依赖类型、升级标记等字段，用于分类统计和升级管理。无论规模如何，提供方与接收方分列、需要时间、状态和双方负责人这几项不建议省略，它们是清单能够持续运转的基础。
填写示例：一条完整的跨项目依赖记录
以下为演示情景，用于说明字段如何配合，不代表真实项目数据。假设客户管理系统项目需要数据平台项目提供历史数据迁移结果，才能开展上线前的数据核对。
| 字段 | 示例取值 | 说明 |
|---|---|---|
| 依赖编号 | CRM-007 | 接收方项目缩写加序号 |
| 提供方项目 | 数据平台建设 | 给出迁移结果的一方 |
| 接收方项目 | 客户管理系统升级 | 等待该结果的一方 |
| 依赖对象 | 历史客户数据迁移结果及核对说明 | 可验收的具体交付物 |
| 依赖类型 | 交付物 | 属于交付类依赖 |
| 需要时间 | 6 月 10 日 | 接收方按 6 月 20 日上线倒推 |
| 承诺时间 | 6 月 14 日 | 提供方评估后的实际可交付时间 |
| 影响描述 | 影响 6 月 20 日上线前的数据核对，延期将压缩一周测试窗口 | 写到具体节点和后果 |
| 接收方负责人 | 张宁 | 负责验收与状态更新 |
| 提供方负责人 | 李珂 | 负责交付与承诺时间维护 |
| 状态 | 已承诺 | 提供方已确认时间 |
| 升级标记 | 是 | 承诺时间晚于需要时间，需项目集协调 |
| 备注 | 提供方拟分两批交付，首批 6 月 12 日可用于部分核对 | 记录替代安排 |
这条记录在状态变化前后的差异值得注意。刚提出时，状态为“待确认”，承诺时间留空，升级标记为“否”；提供方评估后填入承诺时间，状态改为“已承诺”，由于承诺晚于需要时间，升级标记改为“是”，并在备注中写明分批交付安排。交付完成后状态改为“已交付”，接收方核对无误后改为“已验收”，此时该行保留在表中作为历史记录。
常见填写错误包括：把依赖对象写成“配合工作”这类无法验收的表述；把需要时间填成提供方的计划完成时间，导致冲突被掩盖；影响描述只写“影响进度”；一条记录里塞入多个依赖对象，导致状态无法统一更新。逐项对照上表口径，可以避免大部分问题。
调整与维护：让清单持续可用
清单的价值来自持续更新。建议明确以下维护规则，并在项目集启动时与各项目确认。
- 更新频率与责任人。接收方负责人对记录准确性负责，在每周固定时间检查状态、承诺时间和影响描述；提供方负责人在承诺时间变化时当天更新。项目集层面每周汇总一次，重点查看升级标记为“是”的记录。
- 依赖关闭与失效的处理。交付完成并验收后，状态改为“已验收”；因范围调整不再需要的依赖改为“已取消”，并在备注写明原因。两类记录都保留在表中，不直接删除，便于复盘时统计依赖履约情况。
- 字段增删的判断标准。当某一字段连续多个周期无人填写，或填写内容无法支撑任何决策时，考虑删除；当同类协调问题反复出现、现有字段无法区分时，考虑新增。每次调整字段需同步更新字段说明，避免各项目口径分叉。
- 与例会和里程碑评审的衔接。项目周会检查本周到期和逾期依赖；里程碑评审前，按接收方项目筛选出未关闭依赖，逐条确认承诺时间是否仍成立。升级标记为“是”的记录进入项目集协调议题。
当依赖记录需要跨项目集中查看时，可借助项目集管理工具承载。ONES Plan 支持借助项目集管理总览多项目信息，并提供多项目进度管控和资源管理，便于管理者在同一视图中查看各项目状态；其自定义项目属性能力可用于标记项目类型等信息。清单模板本身也可放入 ONES Wiki，通过模板库创建文档，并将页面组关联到对应项目，使依赖清单与项目文档放在一起维护。具体采用哪种承载方式，需结合团队现有的工具环境和协作习惯确定。
常见问题
跨项目依赖清单和项目里的任务依赖列表有什么区别？
任务依赖列表记录的是同一项目内任务之间的先后顺序，用于排期；跨项目依赖清单记录的是两个项目之间“一方等待另一方给出某个对象”的关系。判断标准是看等待关系是否跨越项目边界：如果提供方和接收方属于同一个项目，放在任务排期里处理；如果分属不同项目，就登记到这张清单。
两者可以并存。项目内部用任务依赖安排顺序，跨项目部分汇总到清单中，由项目集层面统一查看和协调。
提供方一直不给承诺时间，这条依赖该怎么记录？
依赖刚提出、提供方尚未评估时，承诺时间可以留空，状态填“待确认”，但需要时间和影响描述必须填完整，让提供方看到延迟的后果。接收方负责人应在提出后约定一个回复期限，到期仍未给出承诺时间的，将升级标记改为“是”，提交项目集协调。
承诺时间留空不等于这条依赖可以不跟踪，它恰恰说明该依赖处于未确认风险状态，需要在周会上优先过问。
一条依赖涉及多个交付物时，是合并成一行还是拆成多行？
建议拆成多行，每条记录只对应一个可验收的对象。合并成一行会导致状态无法统一更新：其中一个交付物完成、另一个仍在等待时，这一行既不能标“已交付”也不能标“进行中”，跟踪信息就失真了。
如果多个交付物由同一提供方在同一时间给出，可以在备注中注明关联编号，便于协调时一起查看，但记录本身仍分开。
项目集规模扩大后，原有字段不够用怎么办？
先判断现有字段是否真的无法支撑决策。如果同类协调问题反复出现、现有列无法区分，再考虑新增字段，例如按依赖类型统计瓶颈、增加风险等级辅助排序。新增后同步更新字段说明，让各项目按同一口径填写。
反过来，某个字段连续多个周期无人填写，或填写内容不参与任何讨论和决策，可以删除，减少填写负担。字段调整宜在项目集例会中统一宣布，避免新旧口径并行。
依赖已经交付但接收方迟迟不验收，状态怎么处理？
提供方交付后状态改为“已交付”，接收方负责人需在约定时间内完成核对。若核对周期较长，在备注中写明验收计划和预计完成时间，避免这条记录长期停留在“已交付”。
验收完成后改为“已验收”，该行保留在表中作为历史记录。若核对中发现交付物不符合要求，状态退回“进行中”，并在备注写明缺口，由提供方补充交付。
