项目间依赖冲突往往在交付临近时才暴露，根源是依赖信息散落在会议纪要和个人沟通里。建立识别与记录机制，目标是把这些依赖变成可查、可跟踪的台账：先统一依赖类型和冲突判定口径，再规定在哪些节点由谁识别，用固定字段登记每条依赖及其冲突状态，最后配套分级升级和定期复核。本文按识别、记录、升级三个环节给出可直接落地的做法。
要点总览（TL;DR）
- 先统一口径：把项目间依赖分为交付物、资源、时间窗口、决策审批四类，用时间错位、标准不一致、资源重叠、前置未满足四种情形判定冲突，并按强依赖与弱依赖分级。
- 把识别动作嵌入立项评审、阶段计划会、里程碑前检查和变更评审四个既有节点，明确项目经理提出、项目集经理汇总、接口人确认的分工。
- 用一张依赖台账承载记录，一条依赖一行，冲突状态使用固定枚举值，变更保留痕迹，上下游项目都能查看。
- 冲突登记后按影响里程碑、资源排期、交付质量分级升级，约定响应时限，升级结论回填台账形成闭环。
- 机制是否在运行看台账更新和冲突暴露时点，周度巡检并入项目集周会、月度评审并入现有例会，不单独增设会议。
先定口径：哪些项目间依赖要纳入识别范围
机制的第一步是让不同项目用同一套语言描述依赖。口径不统一，台账上会出现“A说已交付、B说没收到”的争议，识别也就失去意义。建议先明确纳入范围的依赖类型，再给出冲突判定标准，最后按影响程度分级。
纳入识别的四类项目间依赖
| 依赖类型 | 含义 | 典型例子 |
|---|---|---|
| 交付物依赖 | 下游项目的某项工作以上游项目产出物为输入 | 平台项目提供接口文档后，业务项目才能开始联调 |
| 资源依赖 | 两个项目竞争同一人员、环境或设备的时间 | 两个项目共用同一套测试环境或同一名架构师 |
| 时间窗口依赖 | 下游的某个节点必须落在上游动作之后或之前 | 上线窗口需避开另一项目的系统切换期 |
| 决策/审批依赖 | 下游推进需要上游或共同上级做出决策、完成审批 | 需求范围变更需等架构评审组结论 |
边界要写清楚：本机制只处理项目与项目之间的依赖，单个项目内部的任务先后关系由该项目自己的计划管理，不进入跨项目台账。这样能避免台账被大量项目内任务淹没，也能让跨项目评审聚焦真正需要协调的事项。
冲突判定口径
冲突指依赖关系在当前计划下无法按预期成立。建议用四类可观察的情形判定，避免凭感觉登记：
- 时间错位：上游承诺交付时间晚于下游需要的开始时间。
- 交付标准不一致：上下游对交付物的范围、格式、质量要求理解不同，验收时才发现不匹配。
- 资源占用重叠：同一资源在两个项目的时间安排重叠，且无法同时满足。
- 前置条件未满足：审批未完成、决策未落地，导致下游无法启动。
依赖强度分级
按影响程度把依赖分为两级：强依赖（阻塞）指上游不交付，下游关键路径工作就无法开始或无法继续；弱依赖（影响）指上游延迟会降低下游效率或增加返工，但下游可通过替代方案推进。强度分级直接决定后续升级的优先级，登记时必须填写。
识别时点与责任人：在哪些节点由谁发现依赖
依赖识别如果只靠临时沟通，就会漏项。可行做法是把识别动作嵌入已有的项目节奏，每个时点明确输入、动作、输出和负责人，让识别成为流程的一部分而非额外任务。
| 识别时点 | 输入 | 动作 | 输出 | 负责人 |
|---|---|---|---|---|
| 项目立项/计划评审 | 项目计划、交付物清单、资源排期 | 对照上下游交付物清单逐项比对，标出跨项目输入输出 | 新增依赖记录（初版） | 项目经理提出，项目集经理汇总 |
| 迭代或阶段计划会 | 本阶段任务清单、上游交付承诺 | 核对本阶段所需输入是否已列入上游计划 | 更新依赖记录的时间与状态 | 项目经理，接口人确认 |
| 里程碑前检查 | 里程碑交付物清单、依赖台账 | 逐条核对强依赖是否具备交付条件 | 冲突登记或状态更新 | 项目经理，项目集经理复核 |
| 变更评审 | 变更申请、受影响的依赖记录 | 评估变更对上下游依赖时间与标准的影响 | 依赖记录变更及冲突标记 | 变更提出方发起，接口人确认 |
识别动作的具体做法是“两张清单对一遍”：把上游项目的交付物清单与下游项目的需求输入清单逐项比对，凡是下游需要、上游计划中未覆盖或时间不匹配的，都登记为依赖或冲突。比对结果当场记录，不留到会后补。
角色分工上，项目经理负责提出本项目的对外依赖，项目集经理负责汇总和去重，上下游接口人负责确认依赖对象、时间和标准是否准确。三方确认后的记录才视为有效登记。
记录机制：依赖台账的字段与填写规则
台账是机制的核心载体。字段设计要能支撑“查得到、判得清、追得动”三个要求：任何一条依赖都能找到上下游、责任人和当前状态，冲突能看出卡在哪一环。
| 字段 | 填写要求 | 必填 |
|---|---|---|
| 依赖编号 | 全局唯一，建议“项目缩写-序号”格式 | 是 |
| 上游项目 / 下游项目 | 填写项目全称，避免简称歧义 | 是 |
| 依赖对象 | 具体到交付物、资源或决策事项，不写“相关支持” | 是 |
| 期望交付时间 | 下游实际需要的时间 | 是 |
| 承诺交付时间 | 上游确认的时间，未确认时留空并标注待确认 | 是 |
| 依赖强度 | 强依赖（阻塞）/ 弱依赖（影响） | 是 |
| 冲突状态 | 固定枚举：正常 / 时间错位 / 标准不一致 / 资源重叠 / 前置未满足 / 已关闭 | 是 |
| 责任人 | 上下游各一名接口人 | 是 |
| 升级级别 | 未升级 / 一级 / 二级，与升级规则对应 | 是 |
| 最近更新 | 日期加更新人 | 是 |
| 备注 | 替代方案、协商记录等补充信息 | 否 |
填写规则有三条要固定下来：一条依赖占一行，不把多个交付物合并登记；状态变化时更新当前行并保留变更痕迹，用覆盖方式改写会丢失冲突演进过程；冲突状态只能从固定枚举中选，禁止自由填写，否则统计和筛选都会失效。
台账的存放位置应保证上下游项目都能查看，编辑权限收敛到项目经理和项目集经理，接口人可评论或提交变更申请。存放位置建议与项目计划放在同一协作空间，减少“台账在表格里、计划在别处”的割裂。
当依赖条目增多、需要按项目、状态、升级级别筛选视图，并让状态变更自动通知责任人时，可以把台账承载到项目协作工具中。ONES 的项目管理工作项支持自定义字段与状态流转，可将上述字段配置为工作项属性，依赖记录以工作项形式登记，冲突状态变更触发通知，上下游项目在同一空间内查看和更新，减少表格多头维护的成本。是否迁移到工具取决于台账规模和参与项目数量，条目少、参与方少时先用共享表格也能运行。
冲突升级：从记录到处置的分级规则
台账只记录不推动，冲突会长期停留在“已登记”状态。升级规则要回答三个问题：什么情况升到哪一级、由谁在多长时间内响应、升级结果如何回填。
| 冲突分级 | 判定情形 | 升级路径 | 响应时限 |
|---|---|---|---|
| 一级：影响里程碑 | 强依赖冲突导致下游里程碑无法按期达成 | 项目经理 → 项目集经理 | 登记后 2 个工作日内给出处置意见 |
| 二级：影响资源排期 | 资源占用重叠，需调整排期或增补资源 | 项目经理 → 项目集经理 → 资源负责人 | 登记后 3 个工作日内确定调整方案 |
| 三级：影响交付质量 | 交付标准不一致，存在返工或验收风险 | 项目经理 → 上下游接口人 → 技术或质量负责人 | 登记后 5 个工作日内对齐标准 |
升级触发条件要写具体：强依赖冲突超过响应时限未处置，自动升一级；同一依赖连续两次评审仍未关闭，提交项目集经理决策；涉及跨部门资源调整的，直接进入二级路径。时限可按组织节奏调整，但必须事先约定并写入规则。
每次升级都要回填台账：升级级别、升级时间、处置结论、新的承诺时间。关闭依赖时填写关闭原因和关闭日期，记录保留不删除，便于后续复盘同类冲突的发生规律。
示例：一条跨项目交付依赖从识别到关闭的完整记录
以下为演示情景，用于说明字段填写与状态流转，不对应真实项目。
背景：平台项目需向业务项目交付接口文档与联调环境，业务项目据此开展系统对接。
初始登记（计划评审时）：依赖编号 PT-BIZ-012；上游平台项目，下游业务项目；依赖对象为接口文档及联调环境；期望交付时间 6 月 10 日；承诺交付时间 6 月 10 日；依赖强度为强依赖；冲突状态为正常；责任人为平台项目接口人与业务项目经理；升级级别为未升级。
冲突出现（阶段计划会）：平台项目因接口调整，承诺时间推迟至 6 月 18 日，晚于业务项目 6 月 12 日的联调开始时间。冲突状态更新为“时间错位”，升级级别改为一级，备注记录推迟原因。
升级处置：项目集经理在 2 个工作日内组织协商，结论为平台项目先交付核心接口文档（6 月 10 日），联调环境延至 6 月 15 日，业务项目调整联调顺序。台账更新承诺交付时间、升级级别和处置结论。
关闭：6 月 15 日联调环境交付并验证可用，冲突状态改为“已关闭”，填写关闭日期与关闭原因“按调整后计划交付”。记录保留在台账中，作为后续同类依赖排期的参考。
运行与检查：让机制持续有效的复核动作
机制建立后，判断它是否真正在运行，看台账是否被持续更新、冲突是否在早期暴露。建议设置两个固定节奏，并合并进现有会议。
| 复核动作 | 频率 | 参与人 | 检查内容 |
|---|---|---|---|
| 台账巡检 | 每周 | 项目集经理 | 本周新增依赖是否登记、冲突条目是否都有责任人和时限、超时未处置条目 |
| 依赖评审 | 每月 | 各项目经理、接口人 | 强依赖整体健康度、重复出现的冲突类型、已关闭依赖的留痕完整性 |
为减少会议负担，周度巡检可并入项目集周会的前十分钟，月度评审可并入现有月度经营或交付例会，不单独增设会议。巡检输出一份简短清单：新增条目数、未关闭冲突数、超时条目数，作为机制运行的直接证据。
机制失效的信号要提前识别：台账连续两周无更新、冲突大多在评审会上才首次暴露、关闭记录缺少原因说明。出现这些情况时，优先检查识别时点是否被跳过、责任人是否缺位，而不是增加更多报表。
机制完成检查清单：
- 依赖类型与冲突判定口径已形成书面文件，各项目使用同一套表述。
- 四个识别时点均已明确输入、动作、输出和负责人。
- 台账字段齐全，冲突状态使用固定枚举，变更保留痕迹。
- 冲突分级与升级路径、响应时限已约定并通知到相关角色。
- 至少完成一条依赖从登记到关闭的完整记录。
- 周度巡检与月度评审已排入现有会议日程。
常见问题
项目间依赖台账和项目计划里的任务依赖有什么区别，需要重复登记吗？
两者管理的对象不同。项目计划里的任务依赖解决单个项目内部任务的先后顺序，由该项目自己排期；项目间依赖台账只登记跨项目的输入输出关系，服务于多个项目之间的协调。同一条跨项目依赖不需要在两处重复维护，建议以台账为准，项目计划中引用台账编号即可。如果某个项目内部任务因跨项目依赖被阻塞，可在项目计划中标注对应台账编号，便于追溯。
参与项目不多、依赖条目很少时，也要建完整台账吗？
机制的核心是字段和规则，载体可以简化。参与方少、条目少时，用共享表格按台账字段登记即可运行，关键是冲突状态使用固定枚举、每条依赖有责任人和承诺时间。当条目增多、需要按项目或状态筛选视图、状态变更要自动通知责任人时，再考虑迁移到项目协作工具承载。迁移的判断依据是维护成本和参与项目数量，而非机制本身是否成立。
上下游项目对交付时间各执一词，台账上应该记谁的时间？
台账同时保留两个时间字段：期望交付时间是下游实际需要的时间，承诺交付时间是上游确认的时间。两者不一致本身就是冲突信号，应登记为时间错位并进入升级流程，由项目集经理组织协商。协商后更新承诺交付时间并记录处置结论，历史时间保留在变更痕迹中，便于复盘同类分歧的成因。
升级时限到了但冲突仍未解决，下一步怎么处理？
按事先约定的触发条件自动升一级：强依赖冲突超过响应时限未处置，升到上一级路径；同一依赖连续两次评审仍未关闭，提交项目集经理决策；涉及跨部门资源调整的，直接进入资源排期对应的升级路径。每次升级都要回填台账的升级级别、升级时间和处置结论，避免冲突在口头沟通中悬空。时限可按组织节奏调整，但需写入规则并通知到相关角色。
怎么判断这套机制是真的在运行，而不是走了形式？
看三个可观察的信号：台账是否每周有更新记录，冲突是否在阶段计划会或里程碑前检查中就被登记，已关闭依赖是否留有原因和日期。反过来，台账连续两周无更新、冲突大多在评审会上才首次暴露、关闭记录缺少说明，说明识别时点被跳过或责任人缺位。此时应检查识别动作是否嵌入既有会议，而不是增加更多报表。
