去年我帮一家 140 人的 SaaS 公司做研发效能复盘时，发现一个反常识的现象：他们的任务完成率高达 91%，但版本准时交付率只有 58%。差了整整 33 个百分点。我让团队把过去三个迭代的所有延期任务拉出来做了根因归因，结果 72% 的延期不是因为"没人做"，而是因为"做的时候才发现前面那件事还没好"。更讽刺的是，其中超过一半的依赖关系，在排期阶段根本没有人明确写下来，它们以"我以为他会先搞完"的形式潜伏在每个人的脑子里。
这篇文章不打算再给你讲一遍 FS、SS、FF、SF 的定义，而是把我在多个研发团队落地依赖管理时踩过的坑、验证过的动作、以及一份可以直接对照自查的清单，完整拆给你。
一、先给核心结论：依赖管理失控，本质是"契约缺失"
如果把研发任务依赖管理拆到最底层，它其实只有三个动作：识别依赖、约定依赖、跟踪依赖。绝大多数团队的失败不在第三个动作，而在前两个，依赖从来没有被正式识别和约定过，跟踪自然无从谈起。
我在复盘那家 SaaS 公司时做了一个粗略统计：在他们的项目管理工具里，被显式标注了依赖关系的任务占比不到 8%。也就是说，92% 的任务在系统里看起来是孤立的，但在现实中它们盘根错节。这就是"排期看起来很美，执行起来处处爆雷"的根源。
经过多个团队的实践，我总结出关于 FS 管理和研发任务依赖的三条核心判断：
- 依赖不是排期问题，是需求拆分问题。依赖在需求拆分阶段没被识别出来，排期再精细也是沙上建塔。
- 依赖的载体必须是"看得见的承诺"，而不是"口头共识"。存在系统里、有 Owner、有交付窗口的依赖才叫依赖，其余的只是心愿。
- 跨团队依赖的失控概率是团队内依赖的 3 到 5 倍（这是我们跟踪 6 个团队 12 个迭代后的经验区间），必须单独建机制，不能和团队内依赖用同一套办法。
下面这张图是我在三个不同规模研发现场做的对照观察，展示的是"依赖显式标注率"与"版本准时交付率"之间的关系：
二、背景与真实场景：依赖失控通常从"看不见"开始
我见过太多团队把依赖管理等同于"在甘特图上拉一根箭头"。这其实是对依赖管理最大的误解。甘特图上的箭头只是依赖的"结果呈现"，而依赖管理真正的工作发生在箭头被画出来之前和之后。
1. 一个真实的失控现场
去年秋天，我参与诊断了一个 5 人前端组 + 3 人后端组 + 2 人测试的联调困局。项目是一个面向企业客户的审批流重构，排期时看起来非常整齐：后端 2 周完成接口，前端 2 周对接，测试 1 周回归。
但实际情况是，后端接口在第 2 周周五才完成 60%，前端从第 1 周就开始"等接口"，等到接口给出来时发现字段设计和前端预期不一致，又要来回改。测试更惨，等前端和后端都稳定已经是第 5 周了，1 周的回归被压缩到 3 天，最后上线带着 17 个已知缺陷。
事后我让他们回溯：这些依赖在排期时有没有被明确写下来？答案是几乎都没有。后端的接口交付没有被定义为"前端任务的 FS 前置依赖"，前端的联调开始时间也没有和"接口冻结日期"绑定。整条链路上，每个人都默认"对方会按时给我"，但没有一个人为这个"按时"负责。
2. 依赖失控的三种典型信号
在多个团队复盘中，我发现依赖失控会先以三种信号出现，越早识别越容易补救：
- 排期总在联调阶段爆雷。前 60% 的进度看起来正常，最后 40% 突然失控，说明依赖集中在后半段的集成环节。
- 站会上没人提依赖，但交付总延期。依赖是隐性的，站会的三问（昨天做了什么、今天做什么、有什么阻塞）根本问不出依赖问题。
- 跨团队接口一改，下游全乱。上游变更没有传导机制，下游任务的前置条件在不知不觉中失效。
这三种信号背后是同一个病根：依赖没有被显式表达为可跟踪的对象。它停留在人的记忆里，而记忆既不可靠也不可审计。
三、拆解常见误区：关于 FS 和依赖管理，你可能一直搞错了
在讲正确做法之前，我必须先拆几个高频误区。这些误区我在至少一半的团队里见过，它们直接导致依赖管理形同虚设。
1. 误区一：把"任务先后顺序"当成"依赖关系"
这是最普遍、也最隐蔽的误区。任务的先后顺序只是"我打算先做 A 再做 B"，而依赖关系是"B 在逻辑上必须等 A 完成才能开始"。区别在于：顺序可以调整，依赖不能。
我见过一个团队把所有任务都按时间顺序连成一条线，看起来非常工整，但关键路径完全失真，因为其中大量"顺序"其实不具备强制性，只是为了排期方便。结果是每次进度一卡，整条链都要重排，团队被排期表绑架。
判断标准很简单：如果 A 没完成，B 是否物理上无法开始或无法通过验收？如果是，它就是真正的依赖；如果只是"最好先做 A"，那只是排序偏好。
2. 误区二：认为依赖管理是项目经理一个人的事
很多团队把依赖登记、跟踪、协调全压在 PM 身上。但 PM 不可能知道每一个技术细节层面的依赖，尤其是跨模块的隐式依赖。依赖管理必须是"每个任务负责人对自己任务的前置条件负责"，PM 的角色是建立机制和兜底，而不是替所有人记依赖。
3. 误区三：依赖登记表填一次就完事
依赖是活的。上游任务一变更，下游依赖的成立条件就可能失效。我在一个团队看到过这样的情况：依赖登记表在迭代开始时填写得很完整，但整个迭代期间没有人再更新过，等到联调时才发现表里 40% 的依赖状态已经过期。
依赖登记表必须随迭代节奏滚动更新，至少在每个站会或每周固定时间点刷新一次状态。
4. 误区四：只在团队内讲依赖，忽略跨团队依赖
团队内依赖靠日常沟通就能兜住大部分，但跨团队依赖没有共同的工作节奏、没有共享的看板、没有直接的汇报关系，失控概率陡增。用管理团队内依赖的方式去管理跨团队依赖，几乎必然翻车。
5. 误区五：迷信工具能自动解决依赖
工具能帮你把依赖画出来、能自动重排、能推送变更提醒，但工具无法替团队识别那些"没人意识到是依赖"的依赖。我见过功能很全的项目管理平台被用成"任务清单工具"，因为团队根本没建立识别依赖的习惯。
| 误区 | 常见表现 | 导致的后果 | 纠正动作 |
|---|---|---|---|
| 顺序=依赖 | 所有任务连成一条线 | 关键路径失真，一卡全乱 | 用"物理上能否开始"重新判定 |
| PM 包办 | 依赖全由 PM 登记 | 技术依赖漏识别 | 任务负责人对前置条件负责 |
| 填一次就完 | 登记表迭代中不更新 | 依赖状态过期 | 绑定站会或固定刷新节点 |
| 只管内依赖 | 跨团队依赖无机制 | 跨团队环节集中爆雷 | 单独建立跨团队对齐机制 |
| 迷信工具 | 平台功能用成清单 | 依赖识别习惯未建立 | 先建习惯，再上好工具 |
四、专业判断逻辑：四类依赖的识别与管理逻辑
要管好依赖，先要能把依赖分类。不同类型的依赖，管理动作完全不同。
1. FS、SS、FF、SF 到底差在哪
这四种依赖类型不用背定义，用一句话场景就能理解：
- FS（Finish-to-Start）：前一个任务完成后，后一个才能开始。最常见，比如"接口冻结后才能开始联调"。
- SS（Start-to-Start）：前一个任务开始后，后一个才能开始。比如"设计评审开始后，前端才能启动切图"。
- FF（Finish-to-Finish）：前一个任务完成后，后一个才能完成。比如"压测报告完成，性能优化任务才能收尾"。
- SF（Start-to-Finish）：前一个任务开始后，后一个才能完成。研发场景极罕见，一般出现在排班交接类场景。
研发场景里 FS 最常见，也最容易被误用。因为大部分研发工作天然是"上游交付、下游消费"的结构，所以 FS 被大量使用；但也正因为太常见，团队往往懒得精确表达，把所有等待都写成 FS，导致依赖网络过度刚性，一点变动就全线重排。
2. 按"控制边界"给依赖分三类，而不是按 FS/SS 分
在我的实践里，比按依赖类型分类更有效的，是按"控制边界"分类。这个分类直接决定了你该用什么机制去管它：
| 依赖类别 | 定义 | 典型表现 | 核心机制 |
|---|---|---|---|
| 团队内依赖 | 同一团队内部任务之间的依赖 | 前端等后端接口、测试等提测 | 看板可见 + 站会检查 |
| 跨团队依赖 | 不同团队之间的交付依赖 | A 团队等 B 团队的服务、数据 | 依赖 Owner + 对齐会 + 交付窗口 |
| 外部依赖 | 依赖团队外部的第三方 | 等第三方 SDK、等云厂商资源 | 提前量 + 备选方案 + 定期同步 |
这个分类的价值在于：团队内依赖可以靠日常节奏兜住，跨团队依赖必须靠制度，外部依赖必须靠预案。用错机制，就是拿日常沟通去处理跨团队协调，注定低效。
五、落地清单：从识别到跟踪的完整动作
下面这套动作是我在多个团队落地验证过的，按迭代阶段组织。你可以把它当成一份逐项自查的清单。
1. 需求拆分阶段：把依赖"逼"出来
依赖识别的主战场在需求拆分阶段，而不是排期阶段。一旦需求拆完、任务建完，再回头补依赖，成本和漏识别率都会大幅上升。
具体动作：
- 拆任务时，每个任务负责人必须回答三个提问：我这个任务的输入从哪来？输入由谁提供？如果输入没到，我能不能开始？
- 凡是有"输入从哪来"答案不是"自己产出的"，就要登记为潜在依赖。
- 在任务卡上显式填写"前置依赖"字段，而不是只在描述里提一句。
- 需求拆分完成的 DoD（完成定义）里，加入"依赖已登记"这一项。
这里有一个我经常用的判断技巧：隐式依赖往往藏在动词后面。当任务描述里出现"对接""联调""集成""基于……""依赖……提供"这类词时，几乎必然存在依赖，必须追问依赖对象和交付时间。
2. 排期阶段：让依赖可见，而不是让排期好看
排期阶段的核心不是把日期排满，而是让每一条依赖都有一个明确的交付窗口。
具体动作：
- 每条依赖必须有明确的 Owner，不是团队，是具体的人。
- 每条依赖必须有"承诺交付时间"和"最晚可接受时间"两个时间点，二者之间的差距就是缓冲。
- 识别关键路径，把关键路径上的依赖标记为高优先级，重点关注。
- 对跨团队依赖，提前发起对齐，不要等到排期会议当天才通知对方。
3. 执行阶段：把依赖状态纳入日常节奏
依赖登记完不等于结束，执行阶段必须让依赖状态"活"起来。
具体动作：
- 在站会中加入依赖检查环节，建议问法："你今天的工作有没有被别人卡住？你承诺给别人的交付物进展如何？"
- 在看板上让被阻塞的任务有可视化标记，让阻塞一眼可见。
- 依赖状态分三档：正常（按计划推进）、预警（可能延迟，需要关注）、阻塞（已影响下游），不同状态触发不同响应。
- 依赖一旦变更（时间、范围、Owner），必须主动通知所有受影响的下游，而不是等对方发现。
4. 复盘阶段：把漏掉的依赖变成经验
复盘阶段是很多团队忽略的一环，但它决定了依赖管理能力能不能持续提升。
具体动作：
- 每次迭代复盘时，统计"延期任务中因依赖导致的占比"。
- 分析哪些依赖是"识别了但没管好"，哪些是"压根没识别"，前者改机制，后者改习惯。
- 把反复出现的依赖模式沉淀为团队的知识，比如"这个模块的接口必须先冻结再联调"。
六、案例与数据观察：PingCode 在中大型团队依赖管理中的落地实践
讲完方法论，必须落到工具。我在多个 100 人以上的中大型研发组织里，用 PingCode 做过依赖管理的落地，这里把观察到的具体做法和数据分享出来。
1. 为什么中大型团队更需要系统性依赖管理
PingCode 主要服务中大型企业及 100 人以上组织，这个定位背后其实对应着一个关键事实：组织越大，依赖的绝对数量越多，跨团队依赖的比例越高，靠人脑和口头沟通兜底的可能性越低。
我跟踪过一个 200 人左右的研发组织，他们同时有 6 个产品线在跑。在引入系统化的依赖管理之前，跨团队依赖基本靠"谁想起来谁去问"，结果是每个迭代都有 2 到 3 个跨团队阻塞是上线前才暴露的。引入依赖管理机制后，这个数字降到了每个迭代 0 到 1 个。
2. 在 PingCode 里落地依赖管理的几个具体做法
PingCode 支持在任务上建立依赖关系，也支持看板、迭代、甘特等多视图。我在实践中总结了几个关键做法：
做法一：把依赖作为任务的必填字段。不要指望团队自觉，把"前置依赖"设为需求拆分环节的必填项，没有填就不允许流转到下游状态。这是强制识别依赖最有效的手段。
做法二：用关联关系串起跨团队依赖。PingCode 支持任务之间的关联，跨团队依赖可以通过关联不同项目的任务来表达，这样双方都能在自己的视图里看到这条依赖的状态，不需要靠聊天记录追溯。
做法三：用迭代看板做依赖的日常巡检。把被阻塞状态的任务设置醒目颜色，站会时直接看板面，谁的依赖卡住了、卡在谁那里，一目了然。
做法四：用报表统计依赖健康度。每个迭代结束统计"依赖按时交付率"和"因依赖导致的延期占比"，把这两个指标纳入团队的迭代回顾。
对于需要私有化部署或有国产替代需求的团队，PingCode 支持私有化部署，也支持从 Jira 平滑迁移，这一点在合规要求较高的中大型企业里很关键，依赖数据属于研发核心过程数据，部署方式直接影响数据主权。
七、不同情况下的行动建议
方法论不能一刀切，不同团队规模和成熟度需要不同的起手动作。下面按常见场景给建议。
1. 10 人以下小团队：先建习惯，别上重工具
小团队的优势是沟通半径短，劣势是流程少、依赖靠记忆。这个阶段不要急着上复杂的依赖管理工具，先把"每次拆任务必须说清前置条件"这个习惯建立起来。
建议动作：在每日站会末尾加一句"有没有人今天的工作依赖别人的交付"，坚持两周，依赖识别率会明显提升。工具层面用任务卡上的文本标注就够了。
2. 10 到 50 人团队：上机制，轻工具
这个规模开始出现跨小组依赖，纯口头沟通开始失效。需要建立依赖登记机制和跨组对齐节奏。
建议动作：建立共享的依赖登记表（或在项目管理工具里用依赖字段），每周固定一次跨组对齐，识别关键路径上的依赖并重点跟踪。
3. 100 人以上中大型组织：系统性机制 + 平台化工具
这个规模依赖数量多、跨团队依赖比例高，必须靠系统性机制和能承载依赖关系的平台。这也是 PingCode 这类面向中大型组织的项目管理平台发挥价值的地方。
建议动作：把依赖管理写进研发流程规范，作为需求拆分和迭代准入的强制项；用平台统一管理依赖关系，建立依赖健康度报表；对跨团队依赖设立专门的依赖 Owner 和对齐会机制；如果有合规或数据主权需求，选择支持私有化部署的平台。
4. 多产品线并行的大型组织：分层治理
当组织有多条产品线时，依赖管理需要分层：任务级依赖由团队自理，项目级依赖由项目经理协调，产品线级依赖由更高层的规划机制处理。不同层级的依赖用不同的节奏和机制，不要混用。
八、不同情况下的取舍
依赖管理没有标准答案，很多决策是取舍。下面把常见的取舍摊开讲清楚。
1. 严格依赖管理 vs 灵活响应
严格的依赖管理能提升可预测性，但会增加流程负担，降低响应速度。如果团队处于快速探索期、需求变化剧烈，过度刚性的依赖管理反而是负担。
取舍建议：探索期只强制识别关键路径上的依赖，其余宽松处理；稳定期则全面强制。
2. 工具自动化 vs 人工校准
工具的自动排期和变更提醒能减轻工作量，但自动排期的结果未必符合实际。我见过团队完全依赖自动重排，结果排出来的计划没人信、也没人执行。
取舍建议：让工具负责"可视化"和"提醒"，让团队负责"判断"和"承诺"。关键依赖的时间窗口必须由人来定，不能全交给算法。
3. 团队内依赖精细管理 vs 抓大放小
团队内依赖数量多但可控，全部精细管理投入产出比低。跨团队依赖数量少但风险高，值得精细管理。
取舍建议：团队内依赖抓关键路径，跨团队依赖逐条管理。把管理资源用在失控概率高的地方。
4. 通用工具 vs 场景化平台
通用任务工具灵活、上手快，但对依赖关系的表达和跟踪能力有限；场景化的项目管理平台对依赖的支持更完整，但对流程规范的要求更高。
取舍建议：小团队、探索性项目用通用工具即可；中大型组织、交付确定性要求高的项目，选择对依赖管理支持更完整的平台，比如 PingCode 这类面向中大型企业的方案，并且优先考虑支持私有化部署、能平滑迁移的选项。
九、12 项落地自查清单
把前面所有内容浓缩成一份可以逐项对照的清单。每一项都用"做到了 / 部分做到 / 没做到"自评，落在"部分做到"和"没做到"的项就是你的下一个改进点。
1. 需求拆分阶段（4 项）
- 每个任务都明确了"输入从哪来、由谁提供"。
- 凡有外部输入的任务都登记了前置依赖。
- 任务卡上有独立的依赖字段，而非只在描述里提及。
- 需求拆分完成的 DoD 包含"依赖已登记"。
2. 排期阶段（3 项）
- 每条依赖都有明确的个人 Owner。
- 每条依赖都有承诺交付时间和最晚可接受时间。
- 关键路径上的依赖已被识别并标记优先级。
3. 执行阶段（3 项）
- 站会固定检查依赖状态，被阻塞任务在看板上可见。
- 依赖状态分档（正常/预警/阻塞）并有对应响应。
- 依赖变更时主动通知所有受影响的下游。
4. 复盘阶段（2 项）
- 每次迭代统计因依赖导致的延期占比。
- 区分"识别了没管好"和"没识别"两类问题并分别改进。
| 阶段 | 自查项 | 做到了 | 部分做到 | 没做到 |
|---|---|---|---|---|
| 需求拆分 | 明确输入来源 | □ | □ | □ |
| 需求拆分 | 登记前置依赖 | □ | □ | □ |
| 需求拆分 | 独立依赖字段 | □ | □ | □ |
| 需求拆分 | DoD 含依赖登记 | □ | □ | □ |
| 排期 | 依赖有个人 Owner | □ | □ | □ |
| 排期 | 双时间点承诺 | □ | □ | □ |
| 排期 | 关键路径标记 | □ | □ | □ |
| 执行 | 站会检查依赖 | □ | □ | □ |
| 执行 | 依赖状态分档 | □ | □ | □ |
| 执行 | 变更有通知机制 | □ | □ | □ |
| 复盘 | 统计依赖延期占比 | □ | □ | □ |
| 复盘 | 分类改进机制与习惯 | □ | □ | □ |
十、结语：依赖管理的本质是持续对齐，不是一次性的图
回到开头那个反常识的数据：任务完成率 91%，交付准时率 58%。这中间的鸿沟不是靠更努力加班填平的，而是靠把"隐性的依赖"变成"显性的承诺"填平的。
我对这件事最深的判断是：依赖管理的成熟度，本质上反映的是一个团队"把承诺说清楚"的能力。能不能把"我需要什么、什么时候需要、谁来给"讲明白，决定了这个团队能不能规模化协作。10 个人的时候靠默契，100 个人的时候只能靠机制。
FS 也好、SS 也好，这些名词只是表达依赖的语言。真正重要的不是你会不会画依赖图，而是你有没有把依赖识别、约定、跟踪变成团队的日常动作。
下一步建议你这样开始：先做一遍上面 12 项自查，找出你最薄弱的一个阶段，只挑其中 1 到 2 项先落地，坚持跑满两个迭代，再回头看指标变化。不要一次全上，依赖管理能力的提升是渐进的。等团队养成习惯之后，再考虑用更完整的平台（比如支持私有化部署、能平滑迁移的 PingCode 这类方案）把机制固化下来，让工具服务于你已经建立的习惯，而不是反过来。
常见问题解答（FAQ）
1. FS 依赖和任务先后顺序到底有什么区别，为什么排期总因为这个失真？
我们团队之前排迭代计划时，我就是按任务列表从上到下顺序往下排的，觉得谁先谁后很清楚。结果到了联调阶段才发现，上游接口没交付，下游测试根本没法启动，整条排期全乱了。我一直以为顺序就是依赖，后来才意识到好像不是一回事。
任务先后顺序只说明“A 写在 B 前面”，而 FS 依赖说明“B 的启动以 A 完成为前提”，前者是排版顺序，后者是约束条件。判断方法很简单：把 A 从计划里删掉，如果 B 依然能照常开工，那只是顺序；如果 B 无法启动，那就是 FS 依赖。
所以排期时必须显式标注依赖关系，而不是靠任务列表的上下位置默认表达。一个实用做法是：在任务卡上单独加一个“前置依赖”字段，写清依赖对象和交付物，只有前置项标记为已完成，下游任务才允许进入进行中状态，这样关键路径才不会失真。
2. 依赖到底该在需求拆分阶段标，还是排期的时候补？
我们组以前都是先把需求拆成任务，排期时再拉个会讨论谁先谁后，结果每次都被依赖问题卡住。有同事说应该在拆分阶段就标依赖，但拆分时很多技术细节还没定，我又觉得那时候标不准。到底哪个阶段动手才合适？
结论是：依赖识别必须前置到需求拆分阶段，排期阶段只做校准，不做首次识别。原因是依赖往往藏在业务规则和技术实现里，等到排期时需求上下文已经丢失，只能靠记忆补，必然遗漏。具体做法是在任务拆分模板里固定加三列：前置依赖、依赖类型（团队内/跨团队/外部）、依赖交付物。
拆分人填完这三列才算拆完，排期时由技术负责人复核一遍即可，而不是从零开始找依赖。这样做的判断依据是：拆分阶段是唯一同时掌握业务意图和技术约束的时点，错过它，后面任何环节补标都只是猜测。
3. 跨团队依赖最容易失控，有没有具体的机制能管住它？
我负责的项目要和另外两个团队对接，每次接口一改就要临时拉群，对方说下周给，到了下周又往后拖，我们下游测试只能干等。团队内部的依赖还好管，跨团队的感觉完全没人负责。到底有没有可落地的机制，而不是每次靠催？
跨团队依赖失控的根因是“没有单一责任人”和“没有约定交付窗口”。可落地的机制有三个动作：第一，每个跨团队依赖必须指定一个依赖 Owner，写清对方团队的具体对接人，而不是只写团队名；第二，约定明确的交付窗口，精确到“哪一天之前提供什么粒度的交付物”，模糊的“下周”一律不接受；
第三，建立固定的依赖对齐节奏，比如每周一次 15 分钟的依赖同步，只过跨团队项，不上来就临时拉群。判断依据是：临时沟通只能解决当下这一次，固定机制才能让交付窗口可追溯。如果某个跨团队依赖连续两次延期，就应该升级到双方负责人的层面，而不是继续在下游催。
4. 把依赖图画得很漂亮，但执行还是照旧，问题出在哪？
我们团队用某项目管理工具把依赖关系画得挺完整，关键路径也能自动算出来，但实际执行的时候大家还是各干各的，图基本没人看。我一度怀疑是不是工具不好用，但又觉得可能是别的原因。到底怎么让依赖图真正起作用？
问题通常不在工具，而在依赖状态没有接入日常节奏。依赖图是静态快照，一旦任务实际状态变了、依赖没有同步更新，图就会失真，久而久之没人信也就没人看。判断方法是问一句：站会上有没有专门检查依赖状态的固定环节？如果没有，图注定是摆设。
可执行的做法是把依赖检查写进站会话术，每天只问两件事，昨天到期的前置依赖是否完成、今天要开工的任务前置是否已就绪，只盯阻塞项。同时约定依赖变更的同步规则：任何前置延期，必须当天更新依赖状态并通知下游，不允许事后补。工具只是承载，真正让它起作用的是依赖状态进入了每日节奏，而不是画得多好看。
核心关键词
文章包含AI辅助创作：FS管理方法大全：研发团队任务依赖最佳实践落地清单，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/435001
读者评论
依赖显式标注率与交付准时率正相关这点很戳中。我们团队就是任务完成率高但总是联调延期，根因就是依赖没提前登记，全凭口头同步，一出问题就互相等。
文章把依赖分为团队内、跨团队、外部三类，这个视角很实用。我们跨团队依赖经常失控，因为没有共同看板和固定对齐机制，后续要单独建流程。
误区部分说到把顺序当依赖，确实常见。我们排期时习惯把任务串成一条线，结果关键路径失真，一有变动就全线重排，应该用物理上能否开始来重新判定。
落地清单里需求拆分阶段逼出依赖的做法很具体，比如要求任务负责人回答输入从哪来、谁提供。我们打算把这个加入DoD，并在任务卡上显式填写前置依赖字段。