项目依赖清单、依赖矩阵和依赖网络图描述的是同一件事——项目之间的依赖关系，区别在于记录形式和使用目的。清单适合逐条登记和跟踪，矩阵适合横向排查覆盖遗漏，网络图适合讲清传导路径。选择时主要看三点：依赖是否需要逐条维护、是否需要检查覆盖面、是否需要向跨团队讲清链路。在项目集协作中，ONES Plan 可用于汇总多项目信息，为依赖登记后的状态跟进和评审提供承载。
要点总览（TL;DR）
- 三者描述的都是项目之间的依赖关系，差异在承载形式：清单逐条记录、矩阵两两交叉、网络图用节点连线呈现传导路径。
- 依赖条数不多、需要逐条指派责任人和跟进时间时，优先用依赖清单作为底账。
- 项目集启动或季度规划时，用依赖矩阵逐格排查，能发现清单里没人上报的遗漏依赖。
- 需要向管理层或跨团队讲清传导路径、识别关键链路和瓶颈节点时，用依赖网络图。
- 常见组合是清单为底账、矩阵查覆盖、网络图做沟通，三者共享同一份依赖数据。
三者回答的是同一个问题吗
三者回答的是同一个问题：项目 A 和项目 B 之间是否存在依赖、依赖什么、什么时候需要。差异体现在承载形式和使用目的上，理解这一点是选对工具的前提。
依赖清单是逐条记录。每一条依赖占一行，写明依赖方、被依赖方、依赖内容、期望时间和状态。它回答的是“有哪些依赖”，适合一条一条地登记、指派责任人和跟进状态。
依赖矩阵是两两交叉表。行和列都是项目，交叉格标记两个项目之间是否存在依赖。它回答的是“任意两个项目之间有没有关系”，适合快速扫一遍覆盖面，发现清单里漏掉的组合。
依赖网络图是节点与连线图。节点表示项目或交付物，连线表示依赖方向。它回答的是“依赖如何传导、哪条链路最长”，适合识别关键路径和瓶颈节点。
三者可以并存，并不互斥。清单提供明细底账，矩阵提供覆盖检查，网络图提供路径视图。同一个项目集里，三者往往服务于不同角色和不同会议场合。
同口径差异对照：可视化、维护成本与协同沟通
把三种形式放在同一组维度下比较，选择依据会更清楚。下表按可视化程度、维护成本、协同沟通适用场合、覆盖排查能力和路径表达五个维度对照。
| 维度 | 依赖清单 | 依赖矩阵 | 依赖网络图 |
|---|---|---|---|
| 依赖可视化程度 | 低，以文字条目为主，需逐行阅读 | 中，交叉格标记一眼可见两两关系 | 高，节点连线直观呈现方向和链路 |
| 维护成本 | 随依赖条数线性增长，每条需单独维护 | 随项目数量平方增长，项目多时表格迅速膨胀 | 关系变化后布局需重排，维护成本较高 |
| 协同沟通适用场合 | 逐条核对、责任确认、状态更新 | 覆盖检查会、依赖排查会 | 跨团队讲解、关键链路评审、风险沟通 |
| 覆盖排查能力 | 弱，容易漏掉未登记的依赖 | 强，行列交叉强制检查每一对项目 | 中，能看出链路但不易确认是否穷尽 |
| 路径与传导表达 | 弱，需人工串联多条记录 | 弱，只表达两两关系 | 强，可追踪多级传导和关键路径 |
各自的盲区也值得注意。清单容易漏登，尤其是没人主动上报的隐性依赖；矩阵在项目数量超过十几个后阅读负担明显上升，且交叉格难以表达依赖的强弱和具体内容；网络图在关系频繁变化时容易变得杂乱，读者可能误把布局位置当作重要性排序。
依赖清单：逐条登记与责任跟踪的底账
依赖清单适合需要逐条跟进、明确责任人和时间的场景。它的价值在于每一条依赖都有归属，可以被指派、被催办、被关闭。
一份可用的依赖清单通常包含以下字段：
- 依赖方：提出需求的项目或团队
- 被依赖方：提供交付物的项目或团队
- 依赖内容：具体需要什么交付物或决策
- 期望时间：依赖方需要该交付物的时间点
- 承诺时间：被依赖方确认的交付时间
- 状态：待确认、已确认、进行中、已满足、已阻塞
- 责任人：双方各自的对接人
- 影响说明：依赖未满足时对依赖方的影响
维护成本随依赖条数增长。几十条依赖时，清单仍然清晰可读；上百条时，需要配合筛选、分组和定期清理，否则容易变成一份没人看的流水账。清单在沟通中的角色是可核对的明细依据：会上讨论某条依赖时，直接定位到对应行，确认状态和责任人是哪一方。
依赖矩阵：横向排查覆盖面的交叉表
依赖矩阵适合做覆盖检查。行和列都是项目，交叉格标记两个项目之间是否存在依赖，读法是“行项目是否依赖列项目”。
矩阵的核心作用是强制穷尽。清单依赖人们主动上报，矩阵则要求逐格确认，能暴露“两个项目明明有关系却没人登记”的情况。在项目集启动阶段或季度规划时，用矩阵做一轮排查，往往能发现若干条清单里没有的依赖。
矩阵的局限同样明显。项目数量增多时，表格规模按平方增长：10 个项目是 100 个格子，20 个项目就是 400 个格子，阅读和填写都变得吃力。交叉格通常只能标记“有或无”，表达依赖方向和强弱的能力有限，具体依赖什么、什么时候需要，仍需回到清单或备注中说明。因此矩阵适合作为检查视图，不适合作为唯一的依赖记录。
依赖网络图：看清传导路径与关键链路
依赖网络图用节点表示项目或交付物，用连线表示依赖方向，适合回答“一个项目延期会波及哪些项目”这类传导问题。
网络图的表达优势在于路径。沿着连线可以从上游追到下游，识别出关键链路和瓶颈节点：某个节点被多个项目依赖，它就是需要重点保障的交付点；某条链路串联了多个项目，它就是进度风险最集中的地方。这类信息在清单和矩阵中都需要人工串联才能看出，网络图则直接呈现。
网络图也适合会议讲解。跨团队沟通时，一张图能让各方快速理解自己在链路中的位置，以及自己的延迟会影响谁。使用网络图需要注意两点：一是关系变化后布局需要重排，频繁更新会带来额外工作量；二是图形布局中的位置远近不代表重要性，读者容易误读，讲解时应明确说明连线方向和关键节点的判定依据。
按场景选择：可视化、维护成本与沟通对象怎么权衡
选择哪种形式，取决于当前要完成的管理动作，而不是哪种图看起来更专业。以下按场景给出条件式建议。
- 依赖条数不多、需要逐条指派责任人和跟进时间时，优先用清单。它是最容易落地、最容易交接的形式。
- 项目集启动、季度规划或怀疑存在漏登依赖时，用矩阵做一轮覆盖排查。排查结果回填到清单，矩阵本身不必长期维护。
- 需要向管理层或跨团队讲清传导路径、识别关键链路和瓶颈节点时，用网络图。讲解场景结束后，网络图可以作为沟通材料保留，但明细仍以清单为准。
- 依赖条数多且项目数量大时，三种形式全量维护的成本都很高，应明确分工：清单作为唯一底账持续更新，矩阵按季度或里程碑做抽查，网络图只针对关键链路绘制。
组合用法是常见做法：清单为底账，矩阵查覆盖，网络图做沟通。三者共享同一份依赖数据，避免各画各的图、各说各的话。
在项目集协作中把三种视图串起来
三种视图要发挥作用，依赖信息需要在项目集层面形成登记、检查、沟通、确认的闭环。一个可操作的流程如下。
第一步，登记。各项目在依赖清单中提交依赖条目，写明依赖方、被依赖方、依赖内容、期望时间和责任人。项目集管理者汇总清单，确认每条依赖都有双方对接人。
第二步，检查。在项目集层面用矩阵做覆盖排查，逐格确认项目两两之间是否存在未登记的依赖。发现遗漏后回填清单，并补充责任人和时间。
第三步，沟通。针对关键链路绘制网络图，在跨团队评审会上讲解传导路径和瓶颈节点，让各方确认自己的交付承诺是否可行。
第四步，确认与流转。评审后更新清单中的状态，从待确认推进到已确认、进行中、已满足。依赖状态的变化应在项目集例会上定期核对，阻塞项单独升级处理。
在承载这些动作时，ONES Plan 支持多项目进度管控和资源管理，可借助项目集管理总览多项目信息，并查看多项目数据集合、多维度掌控项目进度。依赖清单的登记结果和状态变化可以依托项目集层面的项目信息汇总进行跟进，矩阵排查和网络图讲解的结论回到同一处确认。对于同时使用 ONES Project 的团队，ONES Plan 与其数据互通，可监控及规划相关项目和迭代，查看工作量和进度，便于在依赖评审时对照实际交付进展。依赖关系本身的具体登记方式和视图呈现，需结合团队实际配置确认。
常见问题
项目数量很多时，依赖矩阵还能直接用吗？
项目数量增多后，矩阵的格子数按平方增长，20 个项目就是 400 个格子，逐格填写和阅读都会变得吃力。这时可以把矩阵从“全量维护”改为“抽查工具”：按季度或里程碑选取重点子集做覆盖排查，排查结果回填到依赖清单，矩阵本身不必长期保留。全量依赖仍以清单为准，避免为了维护一张大表消耗过多管理精力。
依赖清单和网络图的数据对不上，应该以哪个为准？
建议以依赖清单为准。清单是逐条登记、有责任人和状态的底账，网络图是从同一份数据生成的沟通视图。出现不一致，通常说明网络图绘制后清单又发生了更新，或者网络图只画了关键链路、省略了部分依赖。处理方式是先核对清单中的条目和状态，再按需重绘网络图，并在图上注明绘制时间和覆盖范围，避免会上引用过期视图。
隐性依赖没人主动上报，靠矩阵排查能解决吗？
矩阵能提高发现概率，但前提是有人逐格确认。它的作用是把“两个项目之间有没有关系”变成必须回答的问题，减少完全依赖主动上报带来的遗漏。实际操作中，可以按交付物、共享资源、上线窗口等线索先圈出可能相关的项目对，再重点确认这些格子，比无差别填满整张表更可行。排查出的依赖要回到清单登记责任人和时间，否则矩阵检查的结论无法进入跟踪。
三种视图都需要维护，小团队怎么控制成本？
小团队可以只保留清单作为持续维护的唯一底账，矩阵和网络图按需临时生成。具体做法是：日常只更新清单；在项目集启动、季度规划或重大评审前，用矩阵做一轮覆盖检查；需要向外部团队或管理层讲解时，针对关键链路画一张网络图。这样三种视图共享同一份数据，既控制了维护成本，也保留了各自的检查与沟通价值。
在 ONES 中做项目集依赖管理，哪些环节有产品支撑？
ONES Plan 支持多项目进度管控和资源管理，可借助项目集管理总览多项目信息，并查看多项目数据集合、多维度掌控项目进度；与 ONES Project 数据互通，可监控及规划相关项目和迭代，查看工作量和进度。依赖清单的登记结果和状态变化可以依托项目集层面的信息汇总跟进，矩阵排查和网络图讲解的结论回到同一处确认。依赖关系本身的具体登记方式和视图呈现，需结合团队实际配置确认。
