任务依赖依赖关系教程：产品经理实操方法，避坑指南

去年 Q3，我负责的一个 App 版本在提测前一天才发现：支付模块的联调任务，实际上依赖风控团队先完成策略配置接口的字段定义。这个依赖在排期表上根本没标出来。结果是三个团队空等了六天，版本从 9 月 12 日拖到 9 月 20 日上线，多消耗了约 27 人天。事后复盘，问题不在这六天里谁不努力，而在于我们从一开始就把"先后顺序"当成了"任务依赖"。

这件事之后，我把团队近两年的 11 个版本迭代全部拉出来重做了一遍依赖梳理。我发现一个很反常识的结论：大部分延期不是因为估算不准，而是因为依赖没被识别出来。估算偏差通常只占延期的 20%-30%，剩下的大头来自依赖漏标、循环等待和跨团队信息不同步。

这篇文章会把我踩过的坑、试过的六步实操法、以及不同规模团队该怎么取舍，完整讲一遍。如果你正在带版本、排迭代、或者刚转产品不久，这篇内容应该能帮你省下至少一次"空等"。

一、先给结论：依赖管理不是画图，是管理"约束"

很多人把任务依赖理解成"画一张漂亮的图"。这是最大的认知偏差。图只是结果，不是过程。真正决定成败的，是你在识别、标注、对齐这三个环节做了多少动作。

1. 结论一：大部分依赖问题，出在识别阶段而不是排期阶段

我用"缺陷发现阶段"统计过我们团队近 11 个版本的依赖类问题，结果很扎心。在需求评审阶段就识别出来的依赖，平均修复成本是 0.5 人天；到开发阶段才发现，成本涨到 4 人天；到测试或上线后才暴露，成本直接跳到 12 人天以上。

依赖问题的成本曲线不是线性的，而是接近指数的。这意味着，你在需求评审会上多花一小时问"这件事之前必须先有什么"，可能比开发阶段开三次对齐会都有用。

所以六步法的核心不是"画得好看"，而是把依赖识别提前到最便宜的阶段。

2. 结论二：依赖的粒度决定了排期能不能用

我见过大量排期表里写着"后端开发"占两周。这种粒度的任务无法建立有效依赖，因为它不可判定，你没法说清楚后端开发完成的标准是什么。

能做依赖管理的任务，必须满足一个条件：有一个可验证的交付物。接口文档、设计稿、字段定义、埋点方案、测试用例集，这些都是可验证的交付物；"开发""联调""优化"这类词不是。

我的经验是，一个两周迭代里，真正需要建依赖的任务节点控制在 20-35 个之间比较合适。低于 15 个，说明拆得不够，依赖关系被藏在大任务里；高于 50 个，说明拆得过细，维护成本超过收益。

3. 结论三：依赖必须带"责任人 + 交付物 + 判定标准"三件套

只写"A 完成之后做 B"是无效依赖。有效依赖必须写清三件事：谁负责交付、交付什么、以及怎么判定交付完成。

我要求团队在依赖描述里用固定句式："B 任务开始的前提是【责任人】在【日期】前交付【交付物】，验收标准是【判定条件】。"

比如："支付联调开始的前提是风控团队在 9 月 5 日前交付策略配置接口的字段定义文档，验收标准是前端、后端、测试三方确认字段类型与枚举值无歧义。"

这句话看着啰嗦，但它把模糊的口头承诺变成了可追踪的契约。我们团队在改成这个句式之后，跨团队等待时长从平均 4.5 天降到 1.3 天。

二、为什么产品经理总在依赖上翻车：三个我亲历的场景

讲方法论之前，先讲三个真实场景。这三个场景几乎覆盖了产品经理 80% 的依赖翻车情况。

1. 场景一：版本迭代里的"隐性等待"

这是最常见也最隐蔽的一种。任务 A 和任务 B 在排期表上并行，但实际执行时 B 必须先等 A 出一份中间产物。

我遇到过的典型例子是：设计团队在出高保真稿的同时，前端已经在搭框架。表面上并行，高效。但高保真稿里有一处交互改动，导致前端提前搭好的三个组件全部推倒重来。

隐性等待的特点是：排期表上看不出来，只有执行到那一刻才暴露。它的根因是任务拆解时没有区分"可并行的部分"和"必须串行的部分"。

2. 场景二：跨团队协作的"口头承诺"

产品经理最常听到的一句话是"这个我们下周给你"。问题是，"下周"是周三还是周日，"给你"是给文档还是给接口，都没有定义。

我在一个中台项目里吃过这个亏。三个业务团队都依赖中台的用户标签能力上线，中台负责人口头承诺"月底前完成"。到了月底，接口有了，但标签口径没对齐，三个业务团队各自按自己的理解开发，最后数据全对不上，整个项目回滚重做。

口头承诺不是依赖承诺。依赖必须落到系统里、落到具体人和具体日期上，否则它只是一个心理安慰。

3. 场景三：外部依赖的黑盒

外部依赖包括第三方 SDK、云服务变更、合规审核、供应商交付等。这类依赖的特点是：你无法控制，但它能一票否决你的排期。

我参与过一个需要对接第三方实名认证服务的小程序项目。对方承诺的接口上线时间推迟了两周，我们的排期内没有任何缓冲，直接导致整个版本顺延。更麻烦的是，这个依赖在排期表上只写了一行"对接第三方认证"，没有标注它是一个外部依赖，也没有人定期去跟进对方的进度。

从那以后，我在所有排期表里都会把外部依赖单独列一栏，并且强制要求：外部依赖必须有备选方案，或者有明确的降级策略。

三、四种依赖类型，产品经理真正要用的只有两个半

很多人一上来就搬出四种依赖类型，讲得很全，但落地时依然不会用。我用一张表把它们讲清楚，然后告诉你哪些是真的要掌握的。

1. FS / SS / FF / SF 到底是什么

这四种类型来自项目管理的经典理论，本质是描述两个任务在时间轴上的约束关系。

2. 为什么 FS 是绝对主力

FS 之所以占绝对多数，是因为它符合软件开发的基本逻辑：先有输入，才有输出。接口文档写完才能联调，设计稿定稿才能切图，测试用例写完才能执行回归。

我统计过我们团队上个季度的 137 条依赖，其中 FS 占 104 条，比例约 76%。这个比例在大多数互联网团队里都很接近。

所以如果你的团队刚开始做依赖管理，先用 FS 一种就够撑起 80% 的场景。不要一开始就追求四种类型全会用，那只会增加学习成本而不增加收益。

3. SS 和 FF 的真实使用场景

SS 的典型场景是"同步启动"。比如：性能压测必须在服务端部署到预发环境后同步开始，不能等预发完全稳定。因为压测本身需要时间，串行会拖长整体周期。

FF 的典型场景是"同步收口"。比如：客户端发版和运营活动配置必须同时完成，因为活动上线依赖新版本的能力。这时候约束是"两边都完成才能结束"，而不是"一个完成另一个才能开始"。

我个人的判断是：SS 可以适度使用来压缩关键路径，但 FF 要谨慎，因为它容易掩盖任务拖延。原因很简单，FF 只约束"完成时刻"，不约束"开始时刻"，一个任务可以一直拖到最后才动。

4. SF 为什么基本不用

SF 的含义是"前置任务开始后，后置任务才能完成"。听起来像某种交班场景：新系统开始运行后，旧系统才能下线。

但这个逻辑在实际排期里几乎无法验证，因为它对后置任务的约束太弱。你无法通过 SF 判断一个任务该什么时候开始、该投入多少资源。我从业至今，没有在任何一次真实排期里用过 SF。

网上有些教程把 SF 也列为"必学类型"，我认为这是把理论完整性凌驾于实操价值之上。知道它存在即可，不需要为它设计流程。

四、六步实操法：从任务清单到可执行的依赖网络

下面是我现在固定使用的六步法。它的设计原则是：每一步都有明确动作和产出物，且可以在一个 60 分钟的工作坊里跑完一遍初稿。

1. 第一步：把任务拆到"可交付物"粒度

动作：列出所有任务，然后逐条检查它有没有可验证的交付物。没有的，继续拆。

产出物：一份带交付物描述的任务清单，建议控制在 20-35 条。

我常用的检查句是："这条任务做完了，我能拿什么东西给别人看？"如果答案是"就说做完了"，那这条任务还需要拆。

对于 100 人以上的组织，这一步通常需要按模块分头拆，最后合并。合并时最常见的冲突是同一份交付物被两个模块重复定义，这本身就暴露了职责边界问题。

2. 第二步：用"输入-输出"识别真依赖

动作：对每一条任务，回答两个问题。第一，它需要什么输入？第二，它产出什么输出？然后把"输出 → 输入"对应起来。

产出物：一份依赖候选清单，通常会比预期的多，30%-50% 是伪依赖，需要在第三步过滤。

这一步的关键是只认交付物，不认部门、不认人情、不认"惯例"。很多团队习惯性地说"前端当然要等设计"，但如果设计只影响视觉不影响结构，前端完全可以先用占位图并行开发。这种依赖就是伪依赖。

3. 第三步：标注依赖类型与依赖强度

动作：给每条依赖标注 FS/SS/FF 类型，并标注它是"硬依赖"还是"软依赖"。

产出物：一份带类型和强度的依赖清单。

我用"硬/软"来替代传统的"强制/酌情"，因为后者太抽象。硬依赖意味着不满足就没法开始；软依赖意味着不满足可以开始，但会带来返工风险。

我在一个中台项目里做过统计：最初的依赖候选清单有 52 条，逐条过完之后，硬依赖 23 条、软依赖 14 条、伪依赖 15 条。删掉那 15 条伪依赖之后，关键路径缩短了 4 天。

4. 第四步：算关键路径与浮动时间

动作：把所有硬依赖连起来，找出最长的那条链路，这就是关键路径。关键路径上的任何延误都会直接导致版本延期。

产出物：关键路径清单 + 每个非关键任务的浮动时间。

浮动时间的意义在于：它告诉你哪些任务可以安全地晚一点，哪些绝对不行。没有浮动时间的排期表，等于把所有任务都当成关键任务，结果是所有人都在紧张，但没人知道真正该紧张的是什么。

我的经验值是：健康的排期里，非关键任务的平均浮动时间应该在 2-5 天之间。如果普遍低于 1 天，说明排期排得太满，没有任何容错空间；如果普遍超过 8 天，说明任务拆解或依赖识别有问题，可能把不该串行的任务串行了。

5. 第五步：给依赖加缓冲和责任人

动作：对每条关键路径依赖，指定唯一责任人，并设置缓冲时间。缓冲不是平均分配的，而是优先给不确定性最高的依赖。

产出物：带责任人和缓冲的依赖清单。

我用一个简单规则决定缓冲分配：跨团队依赖给 3-5 天缓冲，外部依赖给 5-10 天缓冲，团队内依赖给 1-2 天缓冲。原因很直接，你能控制的范围越小的依赖，不确定性越大。

这里有个反直觉的点：缓冲不应该藏在每个任务的估算里，而应该集中放在关键路径末端或特定风险点上。分散的缓冲会被每个任务的拖延消耗掉，集中的缓冲才真正可用。

6. 第六步：对齐、固化、复盘

动作：开一次 60 分钟的对齐会，把依赖清单逐条过一遍，确认责任人和日期；然后把清单固化到工具里，设置提醒；版本结束后复盘哪些依赖判断错了。

产出物：系统中可追踪的依赖关系 + 一份复盘记录。

这一步被最多人省略，但它是唯一能让下个版本变好的环节。没有复盘的依赖管理，只是在重复同一个错误。

我建议复盘只问三个问题：哪些依赖是漏标的？哪些依赖其实可以并行却被串行了？哪些外部依赖的预估偏差最大？三个问题，十五分钟，长期价值极高。

五、完整案例：一次版本迭代的依赖梳理

下面用我实际做过的一个 App 版本迭代案例，把六步法走通一遍。数据来自项目记录，部分细节做了脱敏处理。

1. 场景设定

背景：一个日活约 40 万的 App，做一次"个性化推荐 + 用户标签体系"的版本迭代。涉及 4 个团队：客户端、服务端、算法、数据。原计划 6 周交付。

第一次排期时，项目有 3 个明确的里程碑，17 个大任务。看起来可控。但实际执行到第 3 周时，算法团队发现标签口径没有和数据团队对齐，需要返工；同时客户端在做推荐卡片时，等待服务端接口定义，空等了 5 天。

2. 依赖识别与收敛

我们用六步法重做了一遍。原来 17 个大任务被拆成 34 个可交付物粒度的任务，识别出 52 条依赖候选，过滤掉 15 条伪依赖，最终确认 37 条真依赖，其中 23 条在关键路径上。

真正让我意外的是跨团队依赖的数量：11 条。也就是说，将近一半的关键路径依赖需要跨团队协调。而原排期表里，这些跨团队依赖一条都没显式标注。

3. 排期前后对比

重做之后，我们把版本周期从 6 周调整为 5.5 周，同时增加了 12 人天的投入（主要用在提前定义标签口径和接口字段）。最终实际交付用了 5 周零 2 天，比原计划提前 4 天。

更关键的变化是：跨团队等待总时长从预估的 19 天降到实际的 6 天，返工次数从 3 次降到 0 次。

4. 用 PingCode 落地依赖管理

这个案例的执行阶段，我们把依赖关系固化到了 PingCode 里。选择它的原因很实际：我们的团队规模在 120 人左右，跨 4 个团队协作，同时公司对数据有私有化部署要求。PingCode 主要服务中大型企业及 100 人以上组织，恰好匹配这个场景。

具体怎么用？我们做了四件事。

（1）把 34 个任务全部建成工作项，并绑定交付物

每个工作项的描述里带三件套：责任人、交付物、验收标准。这样任何人都能看懂"这条依赖到底在等什么"，而不是只看到一个任务标题。

（2）用依赖关系把 37 条真依赖连起来

连线之后，前端空等的问题立刻可视化。原来只能靠人发现，现在系统会直接提示"当前任务被阻塞"。这一步对我们的价值最大，因为阻塞状态从"靠人喊"变成了"系统提醒"。

（3）用关键路径视图监控 23 条关键依赖

每天站会只看关键路径上的任务，非关键路径的任务由各团队自己管。这让我们把站会时间从 30 分钟压到 12 分钟，同时风险识别反而更准了。

（4）设置依赖变更的自动通知

任何一条关键依赖的日期被改动，都会触发通知给上下游责任人。这一条规则帮我们提前发现了 4 次潜在的延期风险。

补充一点：我们团队之前用的是 Jira，迁移过程比预想顺利。PingCode 支持 Jira 平滑迁移，工作项、字段映射、历史数据都能带过去，这也是我们当时决策的一个关键因素。对于有国产替代诉求、又不想承担迁移风险的团队，这个路径是可行的。

如果你需要给多团队定义依赖的字段结构，我们在内部用了一份类似的 YAML 描述约定，把依赖关系写成可读的结构化数据，方便在评审时逐条核对：

dependency:
id: DEP-023

from_task: "标签口径定义"

to_task: "算法模型训练"

type: FS # 完成-开始

strength: hard # 硬依赖

owner: "数据团队-王工"

deliverable: "用户标签口径说明 v1.2"

acceptance:

"覆盖 18 个一级标签、62 个二级标签"

"算法、数据、服务端三方确认枚举值无歧义"

due_date: "2026-03-14"

buffer_days: 3 # 跨团队依赖，缓冲 3 天

fallback: "使用上一版本标签口径，推荐效果降级 15%"

这份约定最大的价值不是技术上的，而是它强迫每条依赖都必须写清楚 fallback。没有降级方案的依赖，等于把项目押在别人的进度上。

六、避坑指南：7 个产品经理最常踩的坑

下面这 7 个坑，都是我或者我带的团队真实踩过的。每一个我都会给出错误做法和正确做法。

1. 坑一：把"相关"当"依赖"

错误做法：因为两个任务属于同一个模块，就把它们连成依赖。

正确做法：只认交付物。A 的产出是否是 B 的必要输入？不是，就不连。

这个坑的代价是排期被无谓地拉长。我在一个项目里删掉 15 条伪依赖后，关键路径缩短了 4 天。这 4 天不需要任何额外资源投入。

2. 坑二：循环依赖

错误做法：A 等 B，B 等 C，C 又等 A。这种情况通常出现在跨模块的接口定义上，双方都希望对方先定义，结果僵住。

正确做法：循环依赖必须在评审阶段强制打破。打破的方式通常是先由一方出"可协商的草案"，另一方基于草案反馈，而不是要求对方出"最终版"。

我处理过的循环依赖里，90% 的根因是"都想要确定性"。解决办法是把"确定"拆成两阶段：先确认结构，后确认细节。

3. 坑三：隐性依赖漏标

错误做法：只标注明显的串行关系，忽略"看起来并行实际串行"的部分。

正确做法：对每条并行任务追问一句"如果这条推迟三天，另一条会不会返工？"会，就存在隐性依赖。

这个坑最难发现，因为它不影响任务是否开始，只影响任务是否需要重做。我用"返工假设法"来筛查，效果比单纯看交付物更好。

4. 坑四：依赖过多导致排期僵化

错误做法：尽可能多地建立依赖，认为连得越密越安全。

正确做法：控制依赖密度。我的经验参考值是任务数 : 依赖数 控制在 1 : 1 到 1 : 1.5 之间。超过 1 : 2，通常意味着大量伪依赖混入。

依赖过多还有一个副作用：任何一处微调都会引发连锁反应，团队会逐渐丧失调整排期的意愿，最后变成"排期不可动"，这比不做依赖管理更糟。

5. 坑五：只画图不对齐

错误做法：产品经理一个人把依赖图排好，发到群里就算完成。

正确做法：依赖必须由上下游共同确认，尤其是跨团队依赖。单方面确定的依赖，在对方那里不存在。

我现在坚持的做法是：对齐会上让每个责任人口头复述一遍"我要在什么时间交付什么"。复述不出来的，就是没对齐。

6. 坑六：忽略外部依赖

错误做法：把第三方服务、合规审核、供应商交付当成"应该没问题"的事项。

正确做法：外部依赖单独建表，指定跟进人，设定检查节点，并且必须有降级方案。

我给外部依赖设的默认缓冲是 5-10 天，理由是这类依赖的预估偏差通常是内部依赖的 2-3 倍。

7. 坑七：把依赖清单当甩锅工具

错误做法：出了问题就拿出依赖清单说"这是你们没按时交付"。

正确做法：依赖清单的目的是提前暴露风险，不是事后追责。如果团队氛围变成互相甩锅，大家就会倾向于少报依赖、晚报风险，整个机制会失效。

我在团队里立的规矩是：主动提前暴露风险的，即使最后真的延期，也不算在个人绩效上；隐瞒到最后才说的，才算问题。

七、工具怎么选：按协作复杂度分三档

工具选择这件事上，我的核心判断是：工具要匹配协作复杂度，而不是匹配预算。用太轻的工具管复杂协作会失控，用太重的工具管小团队会浪费。

1. 第一档：画图沟通阶段

适用对象：5 人以下、单团队、依赖关系在 10 条以内的项目。

这一档用通用画图工具就够了。这类工具的优势是上手快、表达自由，适合在评审会上边讲边画。局限是图和执行是分离的，图改了系统里没人知道。

我的建议是：这一档不要追求"图上系统"。小团队靠每日站会口头同步的效率，往往高于维护工具的成本。

2. 第二档：协作落地阶段

适用对象：20 人以上、多团队协作、依赖关系超过 20 条的项目。

这一档必须用工作项管理系统，因为依赖需要和任务状态绑定，阻塞状态需要自动可见。这一档的核心诉求有三个：依赖关系可视化、阻塞状态自动提示、关键路径可筛选。

这一档里，PingCode 是我们团队实际在用的方案。它的匹配点在于：团队规模在 100 人以上、跨多个团队协作、需要把需求，任务，缺陷，测试串成一条链。PingCode 主要服务中大型企业及 100 人以上组织，这个定位和我们对工具的需求是吻合的。

3. 第三档：规模化和合规阶段

适用对象：200 人以上、多产品线、有数据安全或国产化要求的组织。

这一档的决策变量不再是功能，而是部署方式、权限体系、审计能力和迁移成本。私有化部署能力和历史数据迁移能力，往往是这一档的一票否决项。

我们做选型时把这一条放在第一位，原因是数据合规部门的硬性要求。PingCode 支持私有化部署，这一点直接满足了我们的底线条件。

同时我们还评估了迁移成本，因为替换既有工具的最大隐性成本不是采购费，而是历史数据迁移和团队重新学习。PingCode 支持 Jira 平滑迁移，这一条在我们的评分表里占了很高权重。对于正在做国产替代选型的团队来说，这是一个可以重点验证的方向。

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

前面讲的是通用方法，但具体到你的团队，动作应该不一样。下面按四种典型情况给建议。

1. 情况一：5 人以下小团队

不要建复杂的依赖管理系统。你的成本应该花在"每天站会问一句'你今天被什么卡住了'"上。

建议只做两件事：一是任务拆到可交付物粒度，二是在白板或文档里画出不超过 10 条硬依赖。每周复盘一次依赖判断是否准确，坚持一个月，你团队的执行力会有明显变化。

2. 情况二：20-100 人团队

这个阶段是依赖管理最容易失控的区间。团队已经跨了多个小组，但流程还没固化。

建议动作：建立统一的依赖描述模板（三件套）；在版本启动会上强制做一次 60 分钟依赖梳理；把依赖固化到工作项系统里，设置阻塞自动提醒。关键路径每周更新一次，只跟踪关键路径上的任务。

3. 情况三：100 人以上或多产品线组织

这个规模的挑战不是识别依赖，而是跨产品线的依赖治理。建议设立一个轻量的"依赖协调人"角色，通常由 PMO 或资深产品经理兼任。

具体动作包括：建立跨产品线的依赖台账；统一依赖类型和强度定义；每月做一次依赖健康度检查，重点看循环依赖、超期依赖和外部依赖占比。我们团队定的红线是：循环依赖必须为零，超期依赖占比不超过 10%。

4. 情况四：有私有化和国产替代需求的团队

这类团队选型时，功能对比应该放在第二位。第一位是数据能否留在自己手里，第二位是历史数据能否平滑迁移。

建议动作：先做一次小范围试点，选一个真实版本用新工具跑完整流程；重点验证权限配置、依赖视图和报表导出；迁移时先迁一个项目验证映射关系，再批量迁移。PingCode 在这条路径上的私有化部署能力和 Jira 迁移支持，是我们当时验证通过的两个关键点。

九、取舍：依赖管理里有三件事我建议你"不做"

讲完该做的，讲不该做的。这部分往往比方法本身更有价值。

1. 取舍一：不是所有任务都要建依赖

我的判断标准是：只有影响关键路径或涉及跨团队的依赖才值得建。其他依赖记在心里、写在文档里都可以。

理由很简单：依赖关系的维护是有成本的。每多一条依赖，就多一个需要跟踪的节点，多一个可能失效的假设。当你把依赖数量控制在 30 条以内时，每条依赖都能被认真对待；当你建了 200 条，没有人会真正看。

2. 取舍二：不是所有依赖都要精确到天

跨团队依赖和外部依赖需要精确到天，因为要对外承诺。团队内部依赖精确到"半天"或"上午/下午"就足够，精确到小时只会增加维护负担而没有实际收益。

我曾经在一个项目里要求所有依赖精确到小时，结果是每天要花 20 分钟更新依赖表，而且大部分更新在第二天就作废了。过度精确会消耗团队的注意力预算。

3. 取舍三：不是所有团队都要上重工具

我见过一些 15 人的团队上了完整的企业级项目管理平台，结果用了三个月，只有 4 个人在真正使用，其他人在飞书群里同步。这不是工具不好，是工具和团队复杂度不匹配。

判断标准很简单：如果你每周需要更新依赖关系的任务少于 20 条，就不要上重工具。当你发现"靠人和文档已经同步不过来"时，才是上工具的时机。PingCode 主要服务中大型企业及 100 人以上组织，15 人团队用它，大概率是浪费。

十、总结：依赖关系的本质是提前暴露不确定性

回到最初那个支付联调空等六天的故事。这件事之后我最大的变化，不是我学会了画依赖图，而是我开始把"依赖识别"当成排期的一部分，而不是排期之后的补充。

我在这里给一个可能和主流说法不同的判断：依赖管理的核心价值不是让项目更快，而是让项目更可预测。你不会因为做了依赖管理就减少总工作量，但你会在问题发生前两周就知道它会发生在哪里。

这个"提前两周知道"的能力，就是产品经理相对于项目助理的真正分水岭。项目助理负责记录进度，产品经理负责预判风险。

如果你现在只打算做一件事，我建议是从最小动作开始：在下次版本启动会上，给每条任务加一句"它的开始依赖于谁在什么时间交付什么"。60 分钟，一张表，你会发现至少有 3 条依赖是你之前没意识到的。

如果你想再往前走一步，把下面这份清单直接复制到你的项目文档里，逐条填空即可：

• 本迭代所有任务的交付物是否明确到可以被验证？
• 每条依赖是否写清了责任人、交付物、验收标准三件套？
• 是否存在循环依赖？如果有，打破方案是什么？
• 关键路径上有哪些任务？它们的浮动时间分别是多少？
• 有几条跨团队依赖？责任人是否已当面确认？
• 有几条外部依赖？各自是否有降级方案？
• 缓冲时间是集中分配还是分散分配？集中在哪些风险点上？
• 依赖密度是否超过 1 : 1.5？如果超过，哪些是伪依赖？
• 上次复盘发现的漏标依赖，这次是否补上了检查动作？

填完这九条，你对这个版本的掌控力会明显不一样。下次版本复盘的时候，你也终于能回答那个最难的问题：延期到底是因为没做好，还是因为一开始就没看清。