依赖关系怎么做？实施团队协同管理：任务依赖从0到1

2021 年我接手一个制造业 ERP 实施项目，合同工期 180 天，最终交付用了 268 天。这个数字看起来像典型的项目失败案例，但真正让我在意的是复盘时拆出来的另一组数：团队实际投入的工作量只比计划多了 11 天，剩下的 77 天全是"等"。等客户确认接口人，等甲方采购审批走完流程，等第三方系统开放测试环境，等一个已经离职的人交接历史数据口径。我把这 77 天逐条还原，发现有 63 天来自同一批东西，它们被写在任务卡的备注里，格式是"待客户确认后开始"。

那一刻我确定了一件事：实施团队的延期，八成不是能力问题，而是依赖没有被当成一等公民来管理。依赖一旦只存在于备注、口头承诺和会议纪要里，它就没有 Owner、没有时间约束、没有升级路径，也就没有任何人需要对它的失控负责。这篇文章不讲依赖管理的定义，只讲一件事，实施团队怎么把任务依赖从 0 做到 1，让它变成可识别、可排期、可追踪、可升级、可复盘的协同机制。

一、先给结论：任务依赖不是备注，是交付节奏的控制面

在展开具体做法之前，我先把这些年形成的判断摆出来。如果你只想要结论，这六条就够了；如果你想看推导过程，后面每一节都会展开。

第一，依赖必须字段化，不能写在描述里。凡是不能被工具筛选、排序、提醒、统计的信息，在项目管理里就等于不存在。备注里的依赖没有状态，没有时间，也不会在逾期时报警。

第二，依赖必须有唯一 Owner 和承诺时间，而不是期望时间。"对方部门"不是 Owner，"尽快"不是时间。承诺时间和期望时间的区别，是依赖管理能不能成立的分水岭。

第三，必须区分硬依赖和软依赖，只有硬依赖才进关键路径。把所有依赖都当硬约束，排期会直接变成死锁，团队最后会集体放弃维护这张网。

第四，依赖管理靠节奏，不靠图表。甘特图是表达工具，不是管理动作。没有每日或每周的依赖评审节奏，画得再漂亮的依赖图两天后就会过期。

第五，没有升级路径的依赖等于没有依赖。依赖的本质是"我控制不了的事情会影响我的交付"，既然控制不了，就必须提前约定什么时候、向谁、以什么方式把问题交出去。

第六，只有度量才能让机制活下来。依赖准时交付率、阻塞时长、关键路径偏差这些指标一旦进入周报，依赖管理才会从"PM 的个人习惯"变成"团队的工作方式"。

二、真实场景：实施项目的"等待链"是怎么一环一环断掉的

要理解依赖为什么会失控，先要看清楚实施项目长什么样。它和标准产品研发最大的区别在于：实施项目的关键路径上，有相当一部分节点不在自己的组织内部，甚至不在自己的合同边界内。

我后来把实施类项目的依赖画成一条链，大概是这个顺序：售前方案确认 → 合同与付款条款 → 客户项目组组建 → 数据口径确认 → 环境与网络开通 → 接口联调 → 系统配置 → 单元测试 → 客户 UAT → 缺陷修复 → 培训 → 上线切换 → 验收签字。这条链上有 13 个节点，其中至少 7 个的推动方不是实施团队自己。

1. 依赖失控的四种典型表现

第一种是隐性等待。任务卡上写着"进行中"，实际上人已经卡了三天。因为没人把"等待"当成一个需要被记录的状态，它就被默认成了"在做"。

第二种是串联幻觉。项目计划看起来是串行推进的，实际上很多任务本可以并行，但因为没人识别出真正的依赖边界，全部被排成了前后关系，工期被无谓拉长。

第三种是外部依赖裸奔。客户、供应商、第三方系统这些外部依赖没有进系统，只在周会上口头同步。一旦客户接口人换人，整条链的进度就查不到了。

第四种是缓冲被当成余量随意消耗。计划里留了 5 天缓冲，但因为没人追踪缓冲消耗速度，等到发现时已经吃掉 4 天，剩下 1 天要扛一个 10 天的风险。

2. 一次典型的等待链还原

回到那个延期 88 天的项目。我在复盘会上把等待时间逐条还原成一张表，团队看到之后的反应是沉默，因为大部分等待并不是"对方不配合"，而是"没有人知道这件事卡在谁那里"。

• 等客户确认数据口径：12 天。真正的原因是客户方财务和业务对"客户编码"的定义不一致，但我们的任务卡上只写了"待客户确认"。
• 等第三方系统开放测试环境：18 天。对方的流程是每月集中审批一次，我们的请求提交晚了三天，整整错过一个窗口。
• 等甲方采购审批硬件：21 天。这条依赖在项目启动会上被提过一次，此后再没有人跟踪。
• 等客户指定 UAT 参与人：6 天。客户方项目经理休假，没有备份人选。
• 等内部架构组评审接口方案：6 天。内部依赖反而更容易被忽略，因为默认"自己人好说话"。

这五条加起来 63 天。它们的共同点是：都不是技术问题，也都不是能力问题，全部是"依赖没有被显性化成可管理对象"的问题。

三、拆解常见误区：为什么大多数团队的依赖管理停在"备注"阶段

在我带过的和诊断过的实施团队里，依赖管理失败的形态高度重复。下面这七个误区，几乎每个团队都会踩中至少四个。

1. 把依赖写进备注和描述

这是最普遍也最致命的一条。备注是自由文本，它不能被筛选，不能被排序，不能在逾期时触发提醒，也不能被统计。当依赖是文本时，它的状态更新完全依赖人的主动性，而人的主动性在项目高压期一定是最先被牺牲的。

2. 只画甘特图，不建维护节奏

很多团队花两天时间做出一张漂亮的依赖网络图，然后在启动会上展示一次，之后再没打开过。问题不在图，在于没人规定"谁、在什么会议上、多久更新一次"。

3. 把所有依赖都标成硬依赖

硬依赖一多，排期约束就变成一张密网，任何一处抖动都会引发连锁反应，团队会逐渐意识到"计划永远不准"，进而放弃维护。软依赖应该允许并行、允许加班追赶、允许带条件启动。

4. 依赖没有单点 Owner，只有"对口部门"

"数据组负责"和"张三负责"是两个完全不同的管理对象。前者在出问题时无人可问，后者在请假时你至少知道要找谁备份。

5. 升级靠"喊"，没有阈值和时间点

依赖升级不是情绪行为，应该是规则行为。什么时候升级、升到哪一级、升级后对方需要在多久内响应，这些都应该提前写清楚。

6. 把组织依赖、心理依赖混进任务依赖

这是我在搜索这个话题时特别注意到的一个现象。在搜索联想词里，大量用户把"依赖关系"和"依赖领导怎么办""依赖一个人如何处理"混在一起搜索。任务依赖是"任务 B 的开始受任务 A 的产出约束"，它描述的是交付物之间的时序关系，不是人际关系。概念一旦混淆，讨论就会失去焦点。

7. 迷信工具，以为上系统就解决问题

工具能承载机制，但不能替代机制。字段设计、会议节奏、升级规则、度量口径，这些都要先想清楚，再交给工具固化。

四、专业判断逻辑：什么才算任务依赖，实施场景怎么分类

要把依赖管理做起来，第一步是全团队说同一种语言。否则你会遇到这种场景：三个人对同一个依赖的理解完全不同，一个人认为它是硬约束，一个人认为"差不多就行"。

1. 任务依赖与资源依赖、组织依赖的分界

任务依赖关注交付物：任务 B 需要任务 A 产出的某样东西才能开始。它的约束对象是时间顺序。

资源依赖关注人：任务 A 和任务 B 都需要同一个人，因此不能同时进行。它约束的是并行度，不是顺序。

组织依赖关注审批与决策链：某件事必须经过某个部门或某个层级批准。它约束的是流程时长。

在实施项目里，这三类常常同时存在。我的做法是：任务依赖进依赖字段，资源依赖进资源视图，组织依赖进里程碑和审批清单。混在一起会让依赖表变得不可读。

2. 四种依赖关系在实施场景中的具体样子

通用的依赖类型有四种：完成到开始（FS）、开始到开始（SS）、完成到完成（FF）、开始到完成（SF）。术语本身不难，难的是在实施场景里找到对应物。我整理了一张对照表。

3. 硬依赖与软依赖的判定标准

我的判定标准很简单，问三个问题：

1. 如果前置任务晚一天，后置任务是否一定晚一天？如果是，偏硬。
2. 如果后置任务强行提前开始，是否会产生实质返工？如果会，偏硬。
3. 这个约束是技术决定的，还是流程习惯决定的？技术决定的通常是硬依赖，流程习惯决定的大多是软依赖。

按这个标准，一个实施项目里真正的硬依赖通常只占全部依赖的 30% 到 40%。剩下的软依赖应该被标记为"可协商"，允许在项目压力下重新谈判。

五、从0到1第一步：识别与建模，把依赖变成字段

这是整个机制里最关键的一步。识别阶段做不扎实，后面所有环节都是在管理一堆不完整的对象。

1. 用里程碑拆 WBS，先保证边界清晰

我的习惯是先定 6 到 8 个里程碑，比如"环境就绪""数据就绪""首个业务场景跑通""UAT 通过""培训完成""上线切换完成""验收签署"。然后在每个里程碑下拆任务。依赖只能在任务之间建立，任务边界不清，依赖就无从谈起。

这里有个经验：单个任务的工期最好不要超过 5 个工作日。超过 5 天的任务，它的中间产物通常也是别人的依赖对象，一旦不拆，依赖就识别不出来。

2. 依赖访谈四问

光看任务清单识别依赖是会漏的。我一般会做一轮 30 分钟的依赖访谈，固定问四个问题：

1. 谁等谁？，你手上的这件事，有谁在等你的产出？
2. 等什么？，等的是一个可验收的物件，还是一句确认？
3. 等多久？，你承诺的交付时间是什么？你希望对方最晚什么时候给你？
4. 等不到怎么办？，如果对方晚三天，你的 Plan B 是什么？

第四问的价值最大。它暴露了团队有没有备份方案，也直接决定了这个依赖该不该设置缓冲。

3. 依赖建模必须包含的十一个字段

下面这张表是我在多个项目上迭代出来的最小字段集。字段不是越多越好，但这十一个我认为缺一不可。

交付物定义这一栏最容易被敷衍，也最值得较真。"客户数据"不是交付物，"含 12 个必填字段、通过校验脚本、样本量不少于 5000 条、经过客户财务负责人签字确认的客户主数据"才是。定义不清楚，依赖就没法判断完成与否，最后一定会变成扯皮。

4. 建依赖矩阵，标出关键路径

当任务量超过 50 个，靠人脑已经无法维护依赖网络。我的做法是先建一张依赖矩阵（行是前置任务，列是后置任务），把所有依赖关系填进去，然后手动推一遍关键路径。

关键路径上如果有外部依赖，那这条路径就必须单独拿出来做风险管理。因为外部依赖的方差最大，而关键路径对外部依赖的容忍度最低。

六、从0到1第二步：排期与协同机制，把依赖塞进日常节奏

依赖建模完成之后，会面临一个现实问题：模型再漂亮，如果没有人按固定节奏去看它，两周之后就会失效。这一步要解决的是"谁在什么时候看依赖"。

1. 排期三条规则

规则一：承诺时间由承接方给出，不由提出方指定。提出方可以给期望时间，但承诺时间必须由承接方明确回复。这条规则看起来简单，但它把"我以为他答应了"变成了"他有明确回复记录"。

规则二：软依赖不阻塞启动，但要标记"带条件开始"。比如接口联调可以在客户数据只清洗了 60% 的情况下启动，只要标记清楚后续需要补验证。这样能大幅压缩串联工期。

规则三：缓冲池集中管理，不分散到每个任务。分散缓冲会被各个任务无意中吃掉，集中缓冲由项目经理统一调配，能应对真正的关键风险。

2. 会议节奏：四个固定动作

实施项目的依赖评审不能靠临时开会，必须固定在四个场合。

• 启动会：一次性确认所有外部依赖的对接人、审批窗口和提前期，重点是采购和第三方系统这两类流程节拍长的依赖。
• 每日站会（15 分钟）：只回答三个问题，昨天有没有产生新的阻塞、今天有没有依赖到期、有没有依赖需要升级。不讨论技术细节。
• 每周依赖评审（30 分钟）：过一遍所有状态为"风险"和"阻塞"的依赖，逐条确认 Owner、承诺时间和缓冲消耗。
• 里程碑会：重新推演关键路径，判断是否需要调整缓冲分配。

我个人的经验是，每周依赖评审是四个动作里投入产出比最高的一个。30 分钟 × 20 周 = 10 小时，能换回来的通常是数十天的等待时间。

3. 角色机制：谁对依赖负责

这里有个容易被忽略的设计问题：依赖的 Owner 到底是谁？我的答案是需要两个角色。

依赖 Owner是承接方，负责按承诺时间交付依赖物。依赖跟踪人是提出方或项目经理，负责在承诺时间临近时提醒、在违约时启动升级。

只有 Owner 没有跟踪人，依赖会静默失效；只有跟踪人没有 Owner，问题会一直在原地打转。

七、从0到1第三步：执行监控、变更与升级

机制建立起来之后，真正的考验是执行期的动态变化。项目启动时画的那张依赖图，在第三周就一定会和现实不符。这不是失败，这是常态，关键是有没有机制去接住变化。

1. 每日阻塞扫描

我在项目上看的是一个很简单的数：当天处于"阻塞"状态的任务数量。这个数如果连续三天上升，说明依赖机制开始失效，需要立刻介入，而不是等到周末例会。

阻塞扫描不要看百分比，要看绝对数量和张数对应的具体任务名。管理者对具体任务的敏感度远高于对比例的敏感度。

2. 依赖变更评审：谁批准，怎么看影响

依赖变更分三档处理：

1. 缓冲内变更：承接方在承诺时间前后一个缓冲周期内调整，由依赖双方自行确认，项目经理知会即可。
2. 影响关键路径的变更：必须走正式评审，重新推演关键路径，评估是否挪用集中缓冲。
3. 影响里程碑或验收时间的变更：必须升级到项目指导委员会，同时准备客户沟通方案。

这三档的价值在于，它把"要不要惊动领导"从主观判断变成了客观规则。团队不用纠结，直接对号入座。

3. 外部依赖的特殊处理

实施项目里最难管的不是内部依赖，是客户、供应商和第三方系统的依赖。它们有三个共性：流程节拍不由你定、信息不对称、对项目紧急程度不敏感。

我用的方法是三件事：

• 提前探查节拍。合作开始前就问清楚对方的审批周期、会议周期、关键人休假规律，把这些写进依赖的前置条件。
• 锁定窗口而非日期。与其约定"3 月 14 日交付"，不如约定"3 月 13 日前提交申请，进入 3 月 18 日的审批批次"。
• 准备替代路径。每个关键外部依赖都要有 Plan B：能否用模拟数据先开发，能否改用临时接口，能否先做非核心场景。

4. 升级机制：规则化，而不是情绪化

升级的有效性取决于三个要素是否提前明确：触发条件（比如超过最晚可接受时间 24 小时）、升级对象（客户方项目经理还是我方交付总监）、响应时限（对方需在多久内给出方案）。

这三个要素如果在项目启动阶段就和客户书面确认过，后续升级就变成了一个流程动作，不会伤害合作关系。反之，如果每次都靠临场判断，升级就会变成一种需要消耗人际资本的谈判。

八、从0到1第四步：度量与复盘，把机制变成制度

到这一步，机制已经能跑起来，但还停留在"项目经理的个人习惯"层面。要让它在人员流动后仍然存活，必须建立度量。

1. 五个核心指标

我不建议一开始就上十几个指标。下面这五个是经过筛选的，每一个都能对应到具体的管理动作。

需要说明的是：这些指标没有行业统一基准。我在项目上看到过依赖准时交付率长期在 60% 左右但项目仍然按期交付清楚的团队，原因在于他们的缓冲设置得非常保守。指标的价值在于纵向对比自己的历史数据，而不是横向对比别人。

2. 复盘：按根因分类，而不是按责任分类

依赖断裂的根因我一般归为五类：识别遗漏、承诺不实、外部节拍错估、升级延迟、缓冲不足。复盘时按这五类归因，比追究"谁的责任"更有价值，也更容易让团队愿意说真话。

3. 制度化：模板、清单、SOP

制度化的标志是新人加入后能在半天内上手。这就需要三样东西：依赖登记模板、项目启动依赖检查清单、升级操作 SOP。这三样东西一旦沉淀下来，团队的能力就不再绑定在某个资深 PM 身上。

九、案例观察：中大型实施体系里的依赖协同工具化实践

前面讲的是方法论。但方法要落到几百人的组织里，一定需要工具承载。这里我讲一个我参与过复盘的中大型企业案例。

1. 背景：多项目并行下的依赖黑洞

这家企业是做工业软件的，交付与实施体系大约 400 人，同时并行 30 到 50 个客户项目。他们原本用一套海外的项目管理工具做研发协同，实施团队则主要靠表格和会议纪要。

问题出现在 2023 年：项目数量翻倍后，实施团队开始出现"资源撞车但无人知晓"的情况。同一个二线顾问被三个项目同时排了同一周，而三个项目经理都认为他已经确认了档期。同时，硬件采购和第三方系统对接的依赖散落在各个项目的表格里，公司层面看不到整体风险敞口。

2. 为什么选择迁移到 PingCode

他们的评估逻辑有三条，我认为对中大型组织有参考意义。

第一是规模匹配。PingCode 主要服务中大型企业及 100 人以上组织，这家企业 400 人的规模、30 到 50 个并行项目的复杂度，正好落在它能覆盖的范围内，不需要为了适配工具而切割流程。

第二是依赖与协同的字段承载能力。他们需要的不是一张甘特图，而是能把依赖的前置任务、交付物、Owner、承诺时间、缓冲、升级路径这些字段固化在任务模型里，并且能跨项目聚合。这是表格做不到的部分。

第三是迁移成本和自主可控。PingCode 支持私有化部署，也支持从 Jira 平滑迁移。对他们而言，研发侧原本积累的工作项类型、状态流、字段映射能够相对完整地保留下来，而不需要重新建一套模型；私有化部署则满足了客户项目涉及敏感数据的合规要求。从国产替代的角度看，这类支持私有化又支持 Jira 平滑迁移的平台，是不少中大型企业评估时的优先选项。

3. 落地后观察到的变化

我参与了他们上线后第 12 周的复盘。这里要说明的是，这是单一企业的内部复盘数据，样本有限，不能当作行业基准，只能作为情景参考。

• 依赖登记率从约 40% 提升到 85% 以上。主要原因是依赖变成了必填字段，不填无法流转到下一状态。
• 跨项目资源冲突的发现时间从平均 6 天缩短到 1.5 天。因为资源视图可以按人跨项目聚合。
• 周依赖评审的会议时长从 90 分钟压缩到 35 分钟。因为大部分状态信息在会前已经可见，会议只处理异常项。
• 外部依赖的节拍信息开始被沉淀。每个客户和供应商的历史响应时长有了记录，下一期排期可以直接引用。

也有没解决好的部分。他们在前两个月遇到的主要阻力是：老项目的历史数据迁移后，依赖关系是断的，导致新旧项目的指标不可比。他们的做法是明确划定一个时间点，之前的老项目只做资源占用同步，依赖管理从新项目开始全量执行。这个取舍我认为是务实的。

十、不同情况下的行动建议

方法不能一刀切。下面按团队规模和项目形态，给出四种不同的起步建议。

1. 十人以下小团队：先把依赖写进任务，把站会加一个问题

不要上复杂工具，也不要做依赖矩阵。只需要做两件事：在任务卡里加一个"前置依赖"字段（哪怕是一行文字），以及把每日站会的第三个问题固定为"今天有谁的产出你在等"。

这个阶段的目标是让团队形成"依赖要被说出来"的习惯。习惯比工具重要得多，十人以下的团队靠沟通就能覆盖大部分依赖。

2. 十到五十人的实施团队：建立依赖看板和每周评审

这个规模开始出现信息不对称，必须基础设施化。建议做三件事：一是把依赖从备注迁移到结构化字段；二是按"内部 / 客户 / 供应商 / 第三方"分类建立四个视图；三是固定每周 30 分钟的依赖评审，只过风险和阻塞项。

这个阶段最容易犯的错是字段设计过度。我的建议是先上最小字段集（前置任务、交付物、Owner、承诺时间、状态），跑三个月后再按实际痛点增加缓冲和升级字段。

3. 五十人以上或多项目并行：需要跨项目聚合和资源视图

到了这个规模，单项目视角已经不够了。核心问题变成"公司级资源冲突"和"整体风险敞口"。这时候需要工具支持跨项目的工作项聚合、资源视图和依赖关系查询。

选型上我建议重点评估三件事：一是能不能把依赖建模成实体而不是文本；二是能不能跨项目聚合；三是能不能满足数据合规要求（涉及客户项目数据的，私有化部署往往是硬性条件）。像 PingCode 这类面向中大型企业、支持私有化部署和 Jira 平滑迁移的平台，在这个阶段的匹配度相对更高。

4. 混合形态：内外部依赖并重的交付体系

如果你的项目同时包含自有产品和客户现场实施，建议把内部依赖和外部依赖分成两套管理动作。内部依赖靠每日站会和依赖看板解决；外部依赖靠启动阶段的节拍探查、窗口锁定和书面升级约定解决。

不要试图用一套流程管理这两种依赖，因为它们的时间可控性和响应机制完全不同。

十一、不同情况下的取舍

依赖管理本质上是一组权衡。下面五组取舍是我在项目上反复遇到的，没有标准答案，只有适合与否。

1. 字段颗粒度 vs 维护成本

字段越细，管理精度越高，但每个任务卡的维护成本也越高。我的经验阈值是：如果填写一张任务卡的时间超过 5 分钟，团队一定会开始敷衍。

取舍建议：项目周期在 3 个月以内、团队规模 20 人以下，用最小字段集；项目周期 6 个月以上、涉及多个外部方，用完整字段集。中间地带可以先上最小集，按季度评估是否扩展。

2. 硬依赖数量 vs 排期灵活性

硬依赖标得越多，计划越"严谨"，但也越僵硬。我见过一个项目把 78% 的依赖标为硬依赖，结果是任何一次小幅延期都会引发全线重排，团队索性不再更新计划。

取舍建议：硬依赖的比例控制在 40% 以内。每次标记硬依赖时，问一句"这是技术决定的还是习惯决定的"。

3. 缓冲集中 vs 缓冲分散

集中缓冲便于统一调配，但对单个任务的保护弱；分散缓冲保护到位，但容易被悄悄消耗。

取舍建议：关键路径上的外部依赖用分散缓冲（明确写进任务），其余用集中缓冲池。这样既保护了最脆弱的部分，又保留了整体调度弹性。

4. 升级门槛低 vs 升级门槛高

门槛低，问题暴露快，但可能造成升级噪音，消耗合作关系；门槛高，噪音少，但问题可能被长期掩盖。

取舍建议：项目前四分之一阶段把门槛设低，目的是快速建立"升级是正常动作"的认知；进入中期后逐步提高门槛，把升级聚焦在真正影响里程碑的事项上。

5. 工具化 vs 轻量表格

表格灵活、零成本，但无法承载自动提醒、跨项目聚合和状态流转约束；工具能承载机制，但有实施成本和迁移成本。

取舍建议：判断标准不是团队人数，而是"是否需要跨项目视角"。如果所有依赖都在单个项目内闭环，表格够用；一旦出现多项目并行、资源撞车、公司级风险敞口，工具化就是必需项。此时要额外考虑迁移成本，比如是否支持从已有工具平滑迁移、是否支持私有化部署。

十二、结语：依赖管理的终点不是图表，是节奏

回到开头那个延期 88 天的项目。如果重来一次，我不会增加任何人手，也不会换工具，我只会做五件事：在启动阶段把外部依赖的审批窗口全部锁定；把依赖从备注搬进字段并指定单点 Owner；给关键路径上的外部依赖加缓冲；固定每周 30 分钟的依赖评审；在合同和启动会上书面约定升级路径和响应时限。

这五件事加起来，一个项目的额外投入大约是 20 到 30 个小时。而它可能换回来的，是几十天的等待时间。

我一直觉得，依赖管理最反直觉的地方在于：它不是让你管住别人，而是让你承认哪些事你管不住，然后为管不住的部分提前留出空间和出口。实施团队真正的能力差异，往往不体现在能交付多复杂的方案，而体现在能不能把一条跨了七八个主体的交付链，稳稳地推到最后一次签字。

如果你今天就想开始，不必等下一个项目。挑出当前正在推进的项目，做这五件事：列出 10 个处于"等待"状态的任务；给每个等待标注它到底在等谁的什么产出；给每个依赖指定一个唯一 Owner 和一个承诺时间；为处于关键路径上的依赖加一段缓冲并写清楚消耗规则；明天开一个 15 分钟站会，只讨论依赖。做完这五步，你已经完成了从 0 到 1。

至于从 1 到 10，那是后面的事，建立指标体系、沉淀模板和 SOP、把外部依赖的节拍数据积累成组织资产。但所有这些的前提，都是先把第一步真正做完：让依赖从备注里走出来，变成一个有人负责、有时间约束、有出口的对象。