项目依赖矩阵用一张“项目对项目”的交叉表，把跨项目的交付物、时间、资源和决策依赖记录清楚，让项目集负责人能在同一张表上看到谁等谁、等什么、等到什么时候。设计时先划定纳入范围，再定义行列表头与单元格字段，随后按固定步骤采集、评审并形成基线，最后用角色分工和检查清单保证矩阵持续可用。矩阵的采集与评审过程可以借助 ONES 这类协作工具承载，具体字段和流程仍需结合组织实际确定。
要点总览（TL;DR）
- 项目依赖矩阵以项目为行列，单元格记录交付物、时间、资源、决策四类依赖，只纳入涉及两个项目负责人对交付内容和时间做出承诺的事项。
- 字段设计固定行项目为接收方、列项目为提供方，单元格必填依赖类型、依赖内容、提供方、接收方、需要时间和状态，双向依赖拆成两条分别填写。
- 建矩阵按确定项目清单与责任人、逐项目采集、填入去重、首次评审、形成基线五步执行，首次评审重点校准口径而非追求条目齐全。
- 矩阵运行依赖项目集负责人、项目经理、提供方和接收方四类角色的分工与交付物，依赖变更走双方确认、关键变更上评审的固定路径。
- 矩阵可用性用范围、字段、方向、时间口径、责任人、状态、强弱分级、更新节奏和变更路径九项检查判断，通过后进入例行更新。
先定矩阵范围：哪些项目和依赖要进表
矩阵设计的第一步是划定边界。范围不清，表会越填越厚，最后变成一份没人维护的项目清单。建议先明确矩阵覆盖的项目集或项目群，例如“2025 年客户交付项目群”或“某产品线全部在研项目”，并写下一句范围说明：纳入哪些项目、由谁批准纳入、什么情况下项目移出矩阵。
范围确定后，再定义要记录的依赖类型。项目间依赖通常分为四类：
- 交付物依赖：A 项目需要 B 项目产出接口文档、组件、数据或验收报告，才能开展下一步工作。
- 时间依赖：A 项目的某个里程碑必须排在 B 项目某个节点之后，或两者需要同步上线。
- 资源依赖：两个项目共用同一批专家、测试环境、预算或供应商产能，一方占用会影响另一方。
- 决策依赖：A 项目的方案或范围需要 B 项目的负责人、架构评审组或项目集负责人先做决定。
需要排除的是单项目内部的任务依赖和普通部门协作。前者属于项目排期中的任务先后关系，放进矩阵会淹没真正的跨项目信号；后者如日常审批、例行沟通，没有明确的交付物和时间承诺，也不适合占用矩阵单元格。判断标准可以简化为一条：这条依赖是否涉及两个项目的负责人对交付内容和时间做出承诺。答案为是，才进矩阵。
本步的交付物是两份材料：一份矩阵范围说明，写清项目集边界、纳入与移出规则；一份依赖类型清单，为每类依赖给出定义和一个组织内示例，供后续填写时对照。
矩阵字段怎么定：行列表头与单元格信息
矩阵的行和列都放项目，行列交叉的单元格记录“行项目对列项目”的依赖关系。为避免方向混乱，建议固定口径：行项目为接收方，列项目为提供方，单元格内容表示行项目需要列项目提供什么。这样读表时横向看一个项目依赖了谁，纵向看一个项目被谁依赖。
单元格需要一组必填字段，才能支撑后续跟踪。可参考下表设计：
| 字段 | 填写内容 | 填写要求 |
|---|---|---|
| 依赖类型 | 交付物、时间、资源、决策四选一 | 一条依赖只选一个主类型，混合依赖拆成两条 |
| 依赖内容 | 具体交付物名称、资源名称或待决事项 | 写到可验收的程度，避免“支持配合”这类描述 |
| 提供方 | 列项目及其责任人 | 责任人写到岗位或姓名 |
| 接收方 | 行项目及其责任人 | 与提供方成对出现 |
| 需要时间 | 接收方需要该依赖到位的最晚日期 | 统一使用一个日期口径，不用“月底前”等模糊表述 |
| 状态 | 待确认、已确认、进行中、已交付、已关闭、有风险 | 状态定义写进填写规则，全员一致 |
依赖方向与强弱也需要统一口径。方向按“接收方依赖提供方”单向记录，双向依赖拆成两条分别填写，避免一个单元格同时表达两个方向。强弱可按对项目目标的影响划分：影响关键里程碑或上线日期的为强依赖，需要重点跟踪；影响效率但不改变节点承诺的为弱依赖，按常规节奏跟进。强弱口径应写入填写规则，并在首次评审时统一校准。
字段表定稿后，建议再补一列“备注或关联工作项”，用于记录依赖对应的任务、文档或评审记录位置，方便后续追溯。字段不宜过多，超过十个字段的矩阵往往填写成本高、更新不及时。
按步骤建矩阵：从采集到首次评审
字段确定后，按以下步骤完成第一版矩阵。每一步都明确输入、动作、输出和完成标志，便于项目集负责人组织执行。
- 确定项目清单与责任人。输入为矩阵范围说明；动作为列出纳入项目，为每个项目指定一名矩阵联系人，通常由项目经理担任；输出为项目清单及联系人表；完成标志是每个项目都有唯一联系人并确认参与。
- 逐个项目采集对外依赖。输入为依赖类型清单和项目计划；动作为联系人按“交付物、时间、资源、决策”四类，逐条列出本项目对其他项目的依赖，以及本项目被其他项目依赖的事项；输出为各项目的依赖草表；完成标志是每个项目至少完成一轮自查并提交草表。
- 填入矩阵并去重合并。输入为各项目草表；动作为按“接收方—提供方—依赖内容”比对，把双方描述不一致的条目合并为一条，冲突处标记待确认；输出为矩阵初稿和冲突清单；完成标志是矩阵中每条依赖都有明确的提供方和接收方，冲突项已单独列出。
- 组织首次评审确认依赖与时间。输入为矩阵初稿和冲突清单；动作为召集项目集负责人、各项目联系人逐条确认依赖内容、需要时间和强弱等级，对无法达成一致的条目记录分歧原因和下次确认时间；输出为评审记录和修订后的矩阵；完成标志是关键依赖全部确认，未确认项有明确责任人和期限。
- 形成基线版本。输入为评审后的矩阵；动作为标注版本号和基线日期，发布给项目集相关成员，并约定下一次更新时点；输出为基线版矩阵和发布记录；完成标志是所有联系人确认收到基线版本。
首次评审的重点是校准口径，而非追求条目齐全。评审中发现的典型问题，例如同一依赖被两个项目重复填写、需要时间写成区间、状态用词不统一，应当场修正并补充进填写规则，减少后续返工。
角色与交付物：谁填、谁审、谁跟进
矩阵能否持续运行，取决于角色分工是否落到具体交付物和时点。可按下表约定：
| 角色 | 主要职责 | 交付物 | 提交时点 |
|---|---|---|---|
| 项目集负责人 | 批准矩阵范围和字段规则，主持评审，裁决跨项目争议 | 范围说明、评审结论、基线批准记录 | 矩阵启动时、每次评审后 |
| 项目经理（矩阵联系人） | 采集本项目对外依赖，维护本方单元格，跟进状态 | 依赖草表、状态更新记录 | 每周固定时点、依赖变化时 |
| 依赖提供方 | 确认可交付内容和时间，反馈风险，交付后更新状态 | 确认记录、交付说明、风险说明 | 评审时、交付节点前后 |
| 依赖接收方 | 提出依赖需求，验收交付物，确认关闭 | 依赖申请、验收记录、关闭确认 | 提出依赖时、验收时 |
依赖变更需要固定确认路径：提供方或接收方任一方提出变更，由双方项目经理确认新内容和时间，涉及关键里程碑的变更提交项目集负责人在评审中确认，确认后更新矩阵并记录变更原因。未经确认的变更不应直接改动基线单元格，可先在备注中标记“变更待确认”，避免矩阵与项目实际承诺脱节。
在工具承载上，矩阵的采集、评审和状态更新可以放入统一的多项目协作环境。ONES Plan 支持借助项目集管理总览多项目信息，并支持自定义项目属性管理不同类型项目、查看多项目数据集合与进度；其甘特图可监控及规划 ONES Project 中相关项目和迭代，查看工作量和进度，并支持成员共享。对于需要把依赖条目与项目计划、里程碑放在同一处查看的团队，可以把矩阵作为项目集层面的协调视图，与各项目计划配合使用。
示例：一个跨项目交付依赖如何进矩阵
以下为演示情景，用于说明单元格填写方式，不代表真实项目数据。
某项目集包含“客户端改版”和“统一登录服务”两个项目。客户端改版计划在 6 月 20 日进入联调，需要统一登录服务在 6 月 10 日前提供测试环境可用的登录接口及接口文档。矩阵中行项目为客户端改版，列项目为统一登录服务，单元格填写如下：
- 依赖类型：交付物依赖
- 依赖内容：登录接口（测试环境）及接口文档 v1.0
- 提供方：统一登录服务项目，责任人张工
- 接收方：客户端改版项目，责任人李工
- 需要时间：6 月 10 日
- 状态：已确认
- 强弱：强依赖，影响联调里程碑
首次评审中，双方确认 6 月 10 日为接口可用日期，文档随接口同步提供；统一登录服务项目提出接口联调需要客户端提前提供回调地址，于是矩阵中增加一条反向依赖：统一登录服务依赖客户端改版提供回调地址，需要时间为 6 月 5 日。两条依赖分别占一个单元格，方向清晰。
后续更新按周进行：6 月 5 日回调地址交付，反向依赖状态改为“已交付”；6 月 8 日统一登录服务反馈接口文档延迟两天，矩阵状态改为“有风险”，备注延迟原因和新的承诺日期，并在当周评审中确认；6 月 12 日接口和文档交付，接收方验收后状态改为“已交付”；联调开始后确认无遗留问题，状态改为“已关闭”，并在更新记录中写明关闭日期和验收人。
完成检查：矩阵是否可用的判断标准
矩阵建好后，可用以下清单逐项核对。全部通过，说明矩阵具备投入日常协同的基本条件；存在未通过项，应先修正再发布基线。
- 范围完整：矩阵覆盖的项目与范围说明一致，没有遗漏纳入项目，也没有混入已移出项目。
- 字段齐全：每条依赖都填写了依赖类型、依赖内容、提供方、接收方、需要时间和状态，没有空白必填项。
- 方向一致：所有单元格均按“行项目依赖列项目”记录，双向依赖已拆成两条，没有方向混填。
- 时间口径统一：需要时间均为明确日期，且与项目计划中的里程碑不矛盾；存在矛盾处已标注并确认。
- 责任明确：每条依赖的提供方和接收方都有具体责任人，不存在只写项目名称的情况。
- 状态规范：状态用词符合填写规则，风险项有原因说明和应对责任人。
- 强弱分级：强依赖已识别并标注，关键依赖能在矩阵中快速筛出。
- 更新节奏已约定：明确了更新频率、更新责任人和评审时点，并有最近一次更新记录。
- 变更路径清晰：依赖变更的提出、确认和记录方式已写入规则，基线版本有版本号和发布日期。
检查通过后，矩阵进入例行运行：项目经理按约定节奏更新本方单元格，项目集负责人在评审中关注强依赖和风险项，依赖关闭时留下验收记录。矩阵的价值来自持续更新和评审使用，字段与格式保持稳定，比频繁调整表结构更重要。
常见问题
矩阵里的依赖条目和项目计划中的任务依赖发生冲突时，以哪个为准？
两者记录的对象不同，处理方式也不同。矩阵记录的是两个项目之间的承诺，项目计划记录的是本项目内部的排期安排。出现冲突时，先核对矩阵中该依赖的“需要时间”是否经过双方确认：已确认的，以矩阵承诺为约束，调整项目计划中的相关任务；未确认的，在矩阵中标记待确认，同时按项目计划推进，并在下一次评审中定稿。
如果冲突涉及关键里程碑，应由项目集负责人裁决，并把结论同时更新到矩阵和项目计划，避免两处数据长期不一致。
项目数量多、依赖关系复杂时，矩阵会不会大到无法维护？
矩阵的规模由纳入范围决定，控制范围是主要手段。可以按项目集或项目群分批建表，每个矩阵只覆盖一组需要频繁协调的项目；对关联较弱的项目，用清单记录关键依赖即可，不必全部进入交叉表。
另一个做法是分层维护：项目集层面只保留强依赖和跨项目集依赖，弱依赖由各项目在自身计划中跟踪，定期汇总。矩阵字段保持精简，超过十个字段往往填写成本高、更新不及时。
依赖状态应该多久更新一次，按周还是按事件？
建议采用固定节奏加事件触发相结合的方式。固定节奏通常为每周一次，由各项目联系人在约定时点更新本方单元格；事件触发指依赖交付、延期、范围变化或风险出现时，相关方在当天更新状态并备注原因。
更新频率应与项目集的评审周期匹配，评审前完成一轮更新，确保评审基于最新数据。频率过高会增加填写负担，过低则矩阵失去协调价值，可在运行一两个周期后根据实际调整。
矩阵中的强依赖和弱依赖如何区分，分级之后怎么用？
分级依据是对项目目标的影响程度：影响关键里程碑、上线日期或验收承诺的为强依赖；影响效率但不改变节点承诺的为弱依赖。分级口径应在填写规则中写明，并在首次评审时由项目集负责人统一校准，避免各项目自行判断导致标准不一。
分级后的用途是分配关注度：强依赖在每次评审中逐条过，风险项指定应对责任人；弱依赖按常规节奏跟进，出现变化时再升级。这样矩阵既能覆盖全面，又不至于让评审被大量低影响条目占满。
矩阵建好之后，怎么和现有的项目管理工具配合使用？
矩阵本质是一张协调视图，可以与项目计划、里程碑和评审记录放在同一协作环境中。ONES Plan 支持借助项目集管理总览多项目信息，支持自定义项目属性管理不同类型项目、查看多项目数据集合与进度；其甘特图可监控及规划 ONES Project 中相关项目和迭代，查看工作量和进度，并支持成员共享。团队可以把矩阵条目与对应项目计划关联，在评审时对照查看。
具体字段映射和更新方式需结合组织现有的项目结构确定，工具承载的是采集、评审和状态更新的过程，矩阵的字段规则和角色分工仍需自行定义。
