项目依赖矩阵用一张表回答“哪个项目卡住哪个项目”：以项目为行列，在交叉格标注依赖方向、类型、责任人和交付节点。本文提供可直接复制的矩阵主表与依赖明细表、字段说明、必填与选填划分、一份完整填写示例，以及矩阵随项目推进的更新与维护方法。内容只覆盖项目与项目之间的依赖，单项目内部任务排期和日常部门协作不在讨论范围。
要点总览（TL;DR）
- 模板由矩阵主表和依赖明细表组成：主表以项目为行列、交叉格填依赖编号，明细表一行一条依赖，两表通过依赖编号对应。
- 全表统一按“行项目依赖列项目”阅读，依赖类型分为交付物、审批、资源、信息、里程碑五类，强度与风险标记分开填写。
- 最小可用集包含依赖编号、前后置项目、依赖类型、依赖内容、承诺交付时间、前置方责任人和状态，项目数量增多后再补强度、风险与对接人。
- 矩阵需随里程碑变更、交付延期、范围调整和新项目加入及时更新，并通过固定节奏的依赖评审会推进状态流转与关闭。
- 项目集涉及多项目协同维护时，可将依赖登记与项目集视图放到 ONES Plan 承载，矩阵文档沉淀在 ONES Wiki 中与项目进展对应查看。
可复制的项目依赖矩阵空白模板
模板由两张表组成：矩阵主表用于快速扫视依赖分布，依赖明细表用于记录每条依赖的完整信息。两张表通过“依赖编号”对应，矩阵格中填写编号，明细表中展开该编号的全部字段。复制时保留表头，按项目数量增减行列即可。
表一：矩阵主表（空白）
行列均为项目名称。读法统一为“行项目依赖列项目”，即行项目是后置方、列项目是前置方。交叉格填写依赖编号，多个依赖用逗号分隔；无依赖填“—”。
| 行项目 ＼ 列项目 | 项目A | 项目B | 项目C | 项目D |
|---|---|---|---|---|
| 项目A | — | |||
| 项目B | — | |||
| 项目C | — | |||
| 项目D | — |
对角线为项目自身，固定填“—”。若两个项目互相依赖，则在对称的两个格子中分别填写各自的依赖编号，不要合并成一格。
表二：依赖明细表（空白）
一行一条依赖，矩阵格放不下的时间、责任人、状态和风险都记在这里。
| 依赖编号 | 后置项目（行） | 前置项目（列） | 依赖类型 | 依赖内容 | 强度 | 期望交付时间 | 承诺交付时间 | 前置方责任人 | 后置方对接人 | 状态 | 风险标记 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
两张表如何对应
矩阵主表负责“看得见”：管理者扫一眼行列，就能发现哪个项目被多个项目依赖、哪个项目依赖面最广。明细表负责“查得清”：点开编号即可看到交付时间、责任人和当前状态。填写顺序建议先建明细表、再回填矩阵格，这样编号不会遗漏；阅读顺序则相反，先看矩阵找热点，再查明细看细节。依赖编号建议采用“项目缩写-序号”格式，例如“CRM-01”，便于在会议和文档中直接引用。
矩阵字段说明：每个格子填什么、怎么读
字段设计的目标是让不同角色都能读懂同一张表：项目经理关心方向和强度，交付负责人关心时间和责任人，管理层关心风险和状态。以下字段在模板、说明和示例中保持同名同义。
| 字段名 | 含义 | 取值 | 填写位置 |
|---|---|---|---|
| 依赖编号 | 唯一标识一条依赖 | 项目缩写-序号，如CRM-01 | 矩阵格、明细表首列 |
| 后置项目（行） | 等待对方交付的项目 | 项目名称 | 明细表 |
| 前置项目（列） | 提供交付物或条件的项目 | 项目名称 | 明细表 |
| 依赖类型 | 依赖的性质 | 交付物、审批、资源、信息、里程碑 | 明细表 |
| 依赖内容 | 具体依赖什么 | 一句话描述，如“用户中心接口联调完成” | 明细表 |
| 强度 | 依赖对后置项目的影响程度 | 强、中、弱 | 明细表；矩阵格可用上标标注 |
| 期望交付时间 | 后置项目希望拿到的时间 | 日期 | 明细表 |
| 承诺交付时间 | 前置项目确认的时间 | 日期 | 明细表 |
| 前置方责任人 | 对交付负责的人 | 姓名或角色 | 明细表 |
| 后置方对接人 | 接收并验收的人 | 姓名或角色 | 明细表 |
| 状态 | 依赖当前进展 | 待确认、已确认、进行中、已交付、已关闭、已取消 | 明细表 |
| 风险标记 | 是否需要重点关注 | 高、中、低或无 | 明细表；矩阵格可用颜色或符号提示 |
方向与读法
全表只采用一种读法：行项目依赖列项目。例如“项目B”行与“项目A”列的交叉格填有“A-03”，表示项目B依赖项目A的第3条依赖。统一读法能避免同一张表出现两种理解，尤其在多人协作填写时。若团队习惯把前置方放在行，也可以整体调换，但需在表头注明，且全表不得混用。
依赖类型的判断
交付物依赖指必须拿到对方的产出才能继续，例如接口、组件、文档；审批依赖指需要对方完成评审或签字；资源依赖指共用人员、设备或预算；信息依赖指需要对方提供数据或结论；里程碑依赖指后置项目的关键节点必须排在前置项目某个节点之后。类型决定后续跟踪方式：交付物依赖要盯交付质量，审批依赖要盯审批周期，资源依赖要盯冲突排期。
强度与风险的区别
强度描述依赖本身对后置项目的影响：强依赖意味着没有它项目无法推进，中依赖意味着可以用替代方案过渡，弱依赖意味着只影响局部优化。风险标记描述当前是否存在延误可能，两者独立填写。一条强依赖如果时间充裕、责任人明确，风险可以是低；一条弱依赖如果迟迟未确认，风险也可以是高。
必填与选填：最小可用填写集
项目集刚启动时，字段填得越全，维护成本越高。建议先保证最小可用集，让矩阵能用于一次依赖评审，再随项目推进补全。必填与选填是填写优先级建议，组织可按自身治理要求调整。
| 字段 | 必填/选填 | 理由或适用场景 |
|---|---|---|
| 依赖编号 | 必填 | 两表对应的唯一依据，缺失则无法追溯 |
| 后置项目、前置项目 | 必填 | 决定矩阵格位置和依赖方向 |
| 依赖类型 | 必填 | 决定跟踪方式和评审重点 |
| 依赖内容 | 必填 | 让责任人知道具体要交付什么 |
| 承诺交付时间 | 必填 | 没有承诺时间的依赖无法排期和预警 |
| 前置方责任人 | 必填 | 依赖需要有明确的人负责推进 |
| 状态 | 必填 | 支撑评审会逐条过状态 |
| 强度 | 选填 | 项目数量多、需要排优先级时填写 |
| 期望交付时间 | 选填 | 与承诺时间差异较大时填写，用于谈判 |
| 后置方对接人 | 选填 | 交付需要验收交接时填写 |
| 风险标记 | 选填 | 进入执行期、需要向上汇报时填写 |
| 备注 | 选填 | 记录替代方案、历史变更等补充信息 |
不同规模下的取舍
项目数量在5个以内、依赖条数较少时，只填必填集即可支撑一次评审，强度和风险可以在会上口头确认。项目数量达到10个以上，或存在多个项目共用同一前置项目时，建议补上强度和风险标记，否则矩阵会退化成一张关系图，无法判断先处理哪条。跨部门、跨地域的项目集，建议同时填写期望交付时间和后置方对接人，减少交接中的反复确认。
填写示例：一个项目集的完整依赖矩阵
以下为演示情景，项目名称与数据用于说明填写方式，不代表真实客户案例。某项目集包含四个项目：用户中心（UC）、订单系统（ORD）、数据看板（BI）、移动端（APP）。
填好的矩阵主表
| 行项目 ＼ 列项目 | 用户中心 | 订单系统 | 数据看板 | 移动端 |
|---|---|---|---|---|
| 用户中心 | — | — | — | — |
| 订单系统 | UC-01 | — | — | — |
| 数据看板 | UC-02 | ORD-01 | — | — |
| 移动端 | UC-03 | ORD-02 | BI-01 | — |
填好的依赖明细表
| 依赖编号 | 后置项目 | 前置项目 | 依赖类型 | 依赖内容 | 强度 | 期望交付时间 | 承诺交付时间 | 前置方责任人 | 后置方对接人 | 状态 | 风险标记 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| UC-01 | 订单系统 | 用户中心 | 交付物 | 登录鉴权接口联调完成 | 强 | 3月10日 | 3月14日 | 张工 | 李工 | 进行中 | 中 |
| UC-02 | 数据看板 | 用户中心 | 信息 | 用户分群口径确认 | 中 | 3月8日 | 3月8日 | 王工 | 赵工 | 已确认 | 低 |
| UC-03 | 移动端 | 用户中心 | 交付物 | 单点登录SDK交付 | 强 | 3月20日 | 3月25日 | 张工 | 陈工 | 待确认 | 高 |
| ORD-01 | 数据看板 | 订单系统 | 交付物 | 订单状态数据表结构冻结 | 强 | 3月12日 | 3月15日 | 刘工 | 赵工 | 进行中 | 中 |
| ORD-02 | 移动端 | 订单系统 | 审批 | 下单流程评审通过 | 中 | 3月18日 | 3月18日 | 刘工 | 陈工 | 已确认 | 低 |
| BI-01 | 移动端 | 数据看板 | 里程碑 | 看板首版上线后方可启动移动端数据页 | 弱 | 4月5日 | 4月10日 | 赵工 | 陈工 | 待确认 | 低 |
关键格子的判断依据
用户中心列出现三条依赖，说明它是本项目的关键前置方，评审时应优先确认它的交付能力。UC-03风险标为高，原因是承诺时间比期望时间晚5天，且状态仍为待确认，移动端的排期会直接受影响。UC-02标为信息依赖、强度中，因为分群口径确认后数据看板即可自行开发，不涉及代码交付。BI-01标为弱依赖，因为移动端数据页可以先用静态数据占位，看板上线时间对整体进度影响有限。ORD-02属于审批依赖，跟踪重点是评审排期而非开发工作量。
矩阵的调整与维护方法
矩阵填完只是起点。项目集推进过程中，交付时间、范围和责任人都可能变化，矩阵需要跟着更新，否则会误导排期判断。维护的核心是明确“什么时候改、谁来评审、什么条件下关闭”。
更新触发事件
- 里程碑变更：任一项目的关键节点调整，检查该节点相关的依赖是否需要改承诺时间。
- 交付延期：前置项目预计无法按承诺时间交付，当天更新状态和风险标记，并通知后置方对接人。
- 范围调整：项目新增或删减交付内容，同步增删依赖条目，矩阵格与明细表同时修改。
- 责任人变动：前置方责任人或后置方对接人更换时，更新字段并在评审会上说明交接。
- 新项目加入：在矩阵中增加一行一列，回填与既有项目的全部依赖。
依赖评审会的角色与议程
建议按固定节奏召开依赖评审会，参与角色包括项目集负责人、各项目项目经理、前置方责任人和后置方对接人。议程可以固定为三段：先过状态为“待确认”和“已确认”的依赖，确认承诺时间；再过风险标记为高的条目，给出应对动作和下次检查时间；最后处理新增和取消的依赖。会议输出应落到明细表的状态和备注字段，而不是只停留在会议记录里。
状态流转与关闭规则
状态按“待确认→已确认→进行中→已交付→已关闭”推进，取消的依赖标为“已取消”并保留记录。关闭条件建议同时满足：后置方确认已收到并验收交付物，依赖内容对应的后续工作已启动，明细表中无未处理的风险标记。只在会议上口头确认、未更新状态的依赖，视为未关闭。
与项目计划和风险清单的衔接
矩阵中的承诺交付时间应与各项目计划中的里程碑保持一致，出现差异时以评审确认的时间为准并回写计划。风险标记为高的依赖，应同步进入项目集风险清单，写明影响范围和应对责任人。这样矩阵负责呈现依赖关系，计划负责排期，风险清单负责跟踪应对，三者各司其职又相互引用。
当项目集涉及多个项目、依赖条目需要多人协同维护时，可以把矩阵的登记动作放到协作工具中承载。ONES Plan 支持借助项目集管理总览多项目信息，并支持自定义项目属性、查看多项目数据集合，便于按项目维度汇总依赖相关字段；其甘特图可制定项目里程碑、多时间跨度查看进度，并与 ONES Project 中的项目和迭代联动查看工作量与进度。矩阵本身可作为项目集文档沉淀在 ONES Wiki 中，页面组关联项目后，需求与文档相互对应，文档还可嵌入任务进度和报表，使依赖评审的结论与项目进展保持在同一处可查。具体采用哪种承载方式，取决于团队已有的工具习惯和项目集规模。
常见问题
项目数量不多时，是否可以先只填必填字段？
可以。项目数量在5个以内、依赖条数较少时，先填必填集就能支撑一次依赖评审，强度和风险可以在会上口头确认。随着项目数量增加或出现多个项目共用同一前置项目，再补上强度、风险标记和对接人，避免矩阵停留在关系图层面。
两个项目互相依赖时，矩阵里应该怎么填？
在对称的两个格子中分别填写各自的依赖编号，不要合并成一格。例如项目A依赖项目B的接口，项目B又依赖项目A的验收结论，就在A行B列和B行A列各填一个编号，并在明细表中分别记录两条依赖的类型、时间和责任人。这样评审时能分别跟踪两个方向的交付进展。
依赖已经口头确认，但状态还没更新，算不算关闭？
不算。关闭条件建议同时满足：后置方确认已收到并验收交付物，依赖内容对应的后续工作已启动，明细表中无未处理的风险标记。只在会议上口头确认、未更新状态的依赖视为未关闭，应在会后由责任人补录状态和备注。
矩阵和项目计划、风险清单之间如何避免重复维护？
让三者各承担一段职责：矩阵呈现依赖关系，项目计划负责排期，风险清单负责跟踪应对。承诺交付时间应与计划中的里程碑保持一致，出现差异时以评审确认的时间为准并回写计划；风险标记为高的依赖同步进入风险清单，写明影响范围和应对责任人。这样每张表只维护自己那部分信息，通过依赖编号相互引用。
项目集跨多个团队时，矩阵放在文档里还是放到协作工具中维护？
取决于团队规模和协作习惯。依赖条目少、参与人固定时，文档中的表格足够使用；项目数量多、需要多人同时更新状态时，放到协作工具中更便于跟踪。ONES Plan 支持项目集管理总览多项目信息，并支持自定义项目属性、查看多项目数据集合；矩阵本身可作为项目集文档沉淀在 ONES Wiki 中，页面组关联项目后，需求与文档相互对应，文档还可嵌入任务进度和报表。
