跨项目依赖清单要回答三个问题：谁等谁、等什么、什么时候必须到位。本文提供一份可直接复制的空白表格，逐字段说明填写口径，划分必填与选填，并用一条完整示例演示写法，最后给出更新、变更与归档规则，方便项目集和PMO在不同项目组之间统一使用。
要点总览（TL;DR）
- 跨项目依赖清单按“一条依赖一行”记录，核心是回答谁等谁、等什么、何时必须到位，空白模板可直接复制使用。
- 承诺交付时间与需求时间分列记录，两者差距是识别依赖风险的主要依据；状态取值固定为待确认到已取消八档。
- 最小可用清单保留九个必填字段即可运转，项目集完整版再补充受影响对象、依赖类型、影响程度、确认记录与变更记录。
- 清单需设定每周更新节奏、变更追加留痕、例会与里程碑评审衔接及阶段结束归档规则，避免成为一次性文档。
跨项目依赖清单空白模板（可直接复制）
清单按“一条依赖一行”组织，每行代表一个上游项目对下游项目的一次明确承诺。下表为空白模板，字段顺序与后文说明、示例保持一致，复制到表格软件或文档中即可填写。
| 依赖编号 | 上游项目 | 上游交付物 | 下游项目 | 受影响对象 | 依赖类型 | 承诺交付时间 | 需求时间 | 影响程度 | 当前状态 | 上游责任人 | 下游责任人 | 确认记录 | 变更记录 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| DEP-001 | ||||||||||||||
| DEP-002 | ||||||||||||||
| DEP-003 |
依赖编号建议采用“DEP-序号”格式，由清单维护人统一分配，避免各项目自行编号造成重复。上游交付物和受影响对象要写到可核验的粒度，例如“用户中心接口文档V2”而非“接口相关资料”。
状态字段需要一套固定取值，保证不同项目组填写时含义一致。建议使用下表取值：
| 状态取值 | 含义 | 进入该状态的条件 |
|---|---|---|
| 待确认 | 依赖已被识别，双方尚未就交付内容和时间达成一致 | 下游提出依赖，上游未回复或未确认 |
| 已确认 | 双方对交付物、承诺时间和需求时间均认可 | 上下游责任人均在确认记录中留痕 |
| 进行中 | 上游已开始准备或生产该交付物 | 上游给出启动说明或关联工作项已开始 |
| 已交付 | 交付物已提交给下游 | 下游收到交付物并记录接收时间 |
| 已验收 | 下游确认交付物满足使用要求 | 下游完成验收并留痕 |
| 有风险 | 承诺时间或交付质量可能出现偏差 | 上游预警或下游评估后标记 |
| 已延期 | 已超过承诺交付时间仍未交付 | 到期未交付，且未完成变更确认 |
| 已取消 | 该依赖不再需要 | 下游确认取消，并在变更记录中说明原因 |
每个字段记录什么：字段说明与取值口径
字段说明的作用是让不同项目组按同一口径填写。下表逐字段给出含义、填写口径和示例值，示例值仅用于说明写法。
| 字段名 | 含义 | 填写口径 | 示例值 |
|---|---|---|---|
| 依赖编号 | 清单内唯一标识 | 由维护人统一分配，不复用已取消编号 | DEP-012 |
| 上游项目 | 提供交付物的一方 | 填写项目全称，与项目台账一致 | 会员中心重构项目 |
| 上游交付物 | 上游需要交出的具体成果 | 写到可验收的粒度，注明版本或范围 | 会员等级接口及联调文档V2 |
| 下游项目 | 等待并使用交付物的一方 | 填写项目全称 | 营销活动平台项目 |
| 受影响对象 | 下游具体被卡住的工作 | 填写工作项、模块、里程碑或交付节点 | 活动报名模块开发、6月版本上线 |
| 依赖类型 | 依赖的性质分类 | 从统一取值中选择，见下文分类说明 | 交付物依赖 |
| 承诺交付时间 | 上游承诺交出的日期 | 由上游给出并确认，精确到日 | 2025-06-10 |
| 需求时间 | 下游最晚可接受的日期 | 由下游根据自身计划倒推，精确到日 | 2025-06-05 |
| 影响程度 | 依赖延误对下游的影响大小 | 按统一分级判定，见下文口径 | 高 |
| 当前状态 | 依赖当前所处阶段 | 从状态取值表中选择 | 进行中 |
| 上游责任人 | 对交付物负责的人 | 填写具体姓名，不填部门 | 张明 |
| 下游责任人 | 对接收和验收负责的人 | 填写具体姓名 | 李倩 |
| 确认记录 | 双方确认的时间与方式 | 记录确认日期、确认人和确认渠道 | 2025-05-20 双方在项目例会确认 |
| 变更记录 | 时间、范围、状态变化的留痕 | 每次变更追加一条，不覆盖历史 | 2025-06-03 承诺时间由06-05调整为06-10 |
| 备注 | 补充说明 | 填写风险提示、前置条件等 | 依赖第三方短信通道开通 |
上下游项目与交付物的填写口径
上游项目和下游项目都使用项目台账中的正式名称，避免简称混用。上游交付物要写成下游可以直接验收的对象，包含版本号、范围或数量；如果交付物由多个部分组成，拆成多条依赖分别记录，便于分别跟踪状态。受影响对象填写下游被卡住的具体工作项或里程碑，这样依赖延误时能直接判断影响范围。
依赖类型的分类
依赖类型建议固定为五类，同一清单内不随意新增：
- 交付物依赖：上游产出文档、接口、组件、数据等成果交给下游使用。
- 审批依赖：下游需要上游或上级完成评审、签字、合规审批后才能推进。
- 资源依赖：下游需要上游提供人员、设备、环境、预算等资源。
- 信息依赖：下游需要上游提供口径、数据、决策结论等信息才能继续。
- 外部供应商依赖：交付物来自组织外部供应商，上游项目负责对接和验收。
承诺交付时间与需求时间的区别
承诺交付时间是上游确认可以交出的日期，需求时间是下游根据自身计划倒推的最晚可接受日期。两个字段分列记录，目的是让时间缺口可见：当承诺时间晚于需求时间，该依赖在确认阶段就应标记为有风险，并进入协调或变更流程，而不是等到延期后才被发现。
影响程度与状态的判定口径
影响程度建议分三级：高，指依赖延误会导致下游里程碑或对外交付延期；中，指会影响下游部分工作顺序但可通过调整消化；低，指仅影响局部效率，不影响节点。状态按状态取值表判定，状态变化时同步更新变更记录，保证清单反映的是当前事实。
必填与选填：最小可用清单怎么定
必填字段的标准是：缺少它，清单就无法回答“谁等谁、等什么、何时到位”。其余字段用于治理和追溯，可按项目集规模取舍。
| 字段 | 必填/选填 | 理由或适用场景 |
|---|---|---|
| 依赖编号 | 必填 | 唯一标识，支撑引用和变更追溯 |
| 上游项目 | 必填 | 回答“谁等谁” |
| 上游交付物 | 必填 | 回答“等什么” |
| 下游项目 | 必填 | 回答“谁等谁” |
| 承诺交付时间 | 必填 | 回答“何时到位” |
| 需求时间 | 必填 | 识别时间缺口，支撑风险判断 |
| 当前状态 | 必填 | 支撑例会和评审跟踪 |
| 上游责任人 | 必填 | 明确跟进对象 |
| 下游责任人 | 必填 | 明确接收和验收对象 |
| 受影响对象 | 选填 | 项目集完整版建议填写，用于评估延误影响 |
| 依赖类型 | 选填 | 依赖数量多、需要分类统计时填写 |
| 影响程度 | 选填 | 需要排优先级时填写 |
| 确认记录 | 选填 | 治理要求较高的项目集建议填写 |
| 变更记录 | 选填 | 存在频繁调整时必填 |
| 备注 | 选填 | 按需补充前置条件与风险提示 |
小团队精简版保留九个必填字段即可运转，适合依赖数量在几十条以内、沟通靠例会同步的场景。项目集完整版在必填字段基础上补齐受影响对象、依赖类型、影响程度、确认记录和变更记录，适合多项目并行、需要向上汇报依赖风险的场景。两档字段集共用同一套编号规则和状态取值，后续从精简版扩展到完整版时不需要重建清单。
填写示例：一条跨项目依赖怎么记
下面用一条依赖演示各字段如何落到具体内容。情景为演示设定：会员中心重构项目向营销活动平台项目交付会员等级接口。
| 字段 | 填写内容 |
|---|---|
| 依赖编号 | DEP-012 |
| 上游项目 | 会员中心重构项目 |
| 上游交付物 | 会员等级查询接口及联调文档V2 |
| 下游项目 | 营销活动平台项目 |
| 受影响对象 | 活动报名模块开发、6月版本上线 |
| 依赖类型 | 交付物依赖 |
| 承诺交付时间 | 2025-06-10 |
| 需求时间 | 2025-06-05 |
| 影响程度 | 高 |
| 当前状态 | 有风险 |
| 上游责任人 | 张明 |
| 下游责任人 | 李倩 |
| 确认记录 | 2025-05-20 双方在项目例会确认交付范围 |
| 变更记录 | 2025-06-03 承诺时间由06-05调整为06-10，原因：接口联调发现字段口径差异 |
| 备注 | 下游需在上线前完成一轮回归验证 |
这条记录中，承诺时间晚于需求时间五天，状态标记为有风险，影响程度为高，例会可以直接据此安排协调。常见错误写法及修正如下：
| 错误写法 | 问题 | 修正写法 |
|---|---|---|
| 上游交付物填“接口相关材料” | 无法验收，下游不知道收到什么算完成 | 会员等级查询接口及联调文档V2 |
| 只填一个时间“6月初” | 承诺时间与需求时间混在一起，缺口不可见 | 承诺交付时间2025-06-10，需求时间2025-06-05 |
| 责任人填“会员中心团队” | 无法定位跟进对象 | 上游责任人张明，下游责任人李倩 |
| 时间调整后直接改原日期 | 丢失变更历史，无法复盘延期原因 | 保留原记录，在变更记录中追加调整说明 |
| 状态长期停留在“已确认” | 清单与实际进度脱节 | 上游启动后改为进行中，到期未交付改为已延期 |
清单的调整与维护：更新节奏、变更与归档
清单只有进入固定节奏才有持续价值。维护规则建议明确三件事：谁更新、多久更新、在哪些节点评审。
- 更新频率：依赖状态由上下游责任人在每周固定时间更新一次；临近承诺交付时间的依赖改为每日跟进。
- 责任分工：清单维护人负责编号分配、字段完整性和状态取值一致性；上下游责任人负责各自字段内容的准确性。
- 变更记录：承诺时间、交付范围、责任人发生变化时，保留原记录并在变更记录中追加日期、变更内容和原因；依赖取消时状态改为已取消，写明取消原因，不删除该行。
- 延期处理：超过承诺交付时间未交付，状态改为已延期，由双方责任人在下一次例会前给出新的承诺时间或调整方案。
- 评审节点：在项目例会上逐条过有风险、已延期和高影响程度的依赖；在里程碑评审前核对与里程碑相关的依赖是否已验收。
- 归档规则：项目集阶段结束后，将清单连同变更记录整体归档，保留只读版本，供后续复盘和审计使用。
当依赖数量增多、跨团队协作频繁时，可以把清单落到工作项管理工具中承载状态流转。ONES Plan 支持多项目进度管控和资源管理，提供项目里程碑与甘特图，并可按多时间跨度查看进度；其甘特图可监控及规划 ONES Project 中的相关项目和迭代，查看工作量和进度。将依赖作为关联记录或独立工作项维护时，状态字段和责任人可以直接对应清单中的当前状态与双方责任人，减少手工同步。清单模板本身也可以放在 ONES Wiki 的页面模板库中制式化创建，页面版本记录支持查看与回滚，便于保留变更历史。具体字段配置和流转规则需结合所选工具的实际能力确认后再落地。
常见问题
依赖数量很少时，还需要单独建跨项目依赖清单吗？
依赖数量少、且集中在两三个项目之间时，可以先在项目例会的会议纪要中逐条记录，但建议仍保留依赖编号和双方责任人两个字段，便于后续引用。当依赖条数增加到需要跨项目统一跟踪，或出现同一交付物被多个下游项目等待的情况，再迁移到独立清单。迁移时沿用原有编号规则和状态取值，历史记录可以直接并入，不需要重建。
上游承诺时间晚于下游需求时间，清单里应该怎么处理？
这种情况在确认阶段就应标记为有风险，影响程度按实际后果判定，并在备注中写明缺口天数。随后由双方责任人在例会上协调两种方案：上游压缩交付时间，或下游调整自身计划接受较晚的交付。无论采用哪种方案，都要在变更记录中追加一条说明，写清调整后的时间和原因，原承诺时间保留在历史记录中，便于后续复盘。
一个上游交付物同时被多个下游项目依赖，要记几行？
建议按下游分别记录，一个下游项目一行，共用同一个上游交付物描述。这样每个下游项目的需求时间、受影响对象和验收状态都能独立跟踪，避免一个下游已验收、另一个下游仍在等待时状态无法表达。如果多个下游的需求时间完全一致且验收标准相同，也可以在备注中列明其他下游项目，但需保证任一变化时能及时拆分为独立行。
清单里的确认记录和变更记录，用会议纪要代替可以吗？
会议纪要可以作为确认渠道之一，但清单中的确认记录需要写明确认日期、确认人和确认渠道，便于按依赖逐条追溯。变更记录则要求每次变化追加一条，不覆盖历史，这一点会议纪要通常难以做到。实际操作中可以让会议纪要作为原始凭证，清单记录引用会议日期和议题，两者配合使用，既减少重复录入，也保证清单本身可独立查阅。
把依赖清单放到工具里管理，需要提前确认哪些配置？
需要先确认三件事：依赖以什么形式承载（独立工作项还是关联记录）、状态字段能否覆盖清单中的八档取值、上下游责任人能否分别对应到具体人员。ONES Plan 支持多项目进度管控和资源管理，提供项目里程碑与甘特图，并可按多时间跨度查看进度；其甘特图可监控及规划 ONES Project 中的相关项目和迭代，查看工作量和进度。ONES Wiki 提供页面模板库，可一键创建制式化文档模板，并记录所有页面版本，支持随时查看与回滚。具体字段配置和流转规则需结合所选工具的实际能力确认后再落地。
