后置任务最佳实践：产品经理任务依赖效率提升，常见问题

“后置任务延期，几乎从来不是后置任务的问题。”这句话是我做完一次迭代复盘后，写进团队周报里的。那次延期的任务叫“埋点数据看板 v2”，在迭代看板上整整挂了 9 天没动，负责的同事每天在站会上说“等上游字段”，而上游同事说“我以为他们不急”。往前追溯 11 天，需求评审会上出现过一句“字段先这样做，后面再定”。没人记录，没人跟进，也没人觉得那是风险。

那次之后我做了一件有点笨的事：把团队连续 6 个迭代、共 417 条带依赖关系的任务归档记录翻了一遍，逐条标注延期的第一触发原因。结论比我预想的更极端，将近九成的后置任务延期，第一次出错的位置都不在后置任务本身，而在前置任务的交付定义、触发信号或者责任交接上。后置任务只是那个把问题暴露出来的地方，它不是问题本身。

这篇文章不讲“什么是任务依赖”，也不堆工具推荐。我把这几年在中大型团队里踩过的坑、改过的规则、用过的判断逻辑完整写出来，包括哪些做法我没坚持下去、哪些做法在什么规模下才成立。如果你正在为“后置任务总被拖”头疼，可以对着往下看。

一、核心结论：后置任务的效率，在前置定义那一刻就已经决定了

先把我的核心判断放在最前面，后面的内容都是围绕这几条展开的。如果你只读这一段，也应该能拿到可用的结论。

1. 后置任务是因变量，不是自变量

后置任务在项目管理里通常指依赖上游产出才能启动的下游节点：接口联调依赖接口文档定稿，数据看板依赖埋点上线，上线验收依赖测试报告出具。它的开始时间、可执行程度、返工概率，全部由上游交付质量决定。

所以后置任务的执行者其实是最没有权限改变结果的人。你盯着他催，等于让一个下游的人去解决上游的问题。这是很多团队效率卡死的根本原因。

正确做法是把管理动作从“盯后置任务”前移到“定义依赖接口”。后置任务不需要被管理，需要被管理的是它和前置任务之间那个接口。

2. 依赖效率 = 契约清晰度 × 信号可靠性 ÷ 协调损耗

我把依赖效率拆成一个可讨论的结构。契约清晰度指前置任务的交付物、负责人、时间、验收标准是否明确；信号可靠性指上游状态变化能不能被下游及时感知；协调损耗指为了对齐这件事本身花掉的时间。

这三项里，前两项是乘法关系。任何一项接近零，整体效率就接近零，契约再清楚，上游延期了两周没人知道，后置任务照样停摆。第三项是除法项，协调损耗越大，实际产出效率越低。

这个结构解释了一个常见现象：有些团队把站会从 15 分钟加到 40 分钟，依赖问题反而更多。因为他们增加的是协调损耗，没有改变契约清晰度和信号可靠性。

3. 不要管理“依赖”，要管理“依赖的接口”

依赖这个词太抽象，抽象的东西没法执行。我一般要求团队把它翻译成三个可回答的问题：谁在什么时候，把什么东西，交给谁。能回答这三个问题的依赖才是可执行的依赖，回答不了的都只是风险提示。

这也是我判断一个团队依赖管理水平高低的最快方式：随便挑一条跨团队依赖，问“交付物是什么、谁负责、什么时候交、不交怎么办”，如果对方能立刻答上来，说明机制在跑；如果对方要去翻聊天记录，说明这个依赖只存在于人的记忆里。

二、背景与真实场景：为什么今天后置任务变得这么贵

后置任务一直存在，但它的成本在最近几年明显变高。原因不是工具变差了，而是组织形态变了。

1. 组织形态的变化，让依赖从“内部协调”变成“跨团队协商”

十年前一个产品线可能就是一个 20 人的团队，需求、开发、测试、数据分析在同一个汇报关系里。依赖出问题，走两步路就能解决，协调成本极低。

现在典型的形态是：一个用户可见的功能，需要 4 到 6 个团队协作，业务中台出接口、算法团队出模型、数据团队出指标口径、客户端做展示、测试做验证、安全做合规审核。任何一个团队的后置任务，前面都排着三四个不属于自己管辖的前置任务。

汇报关系不再覆盖协作关系，这是所有依赖问题的结构性根源。你没法给隔壁团队的人排优先级，只能靠协商。而协商是有损耗的。

2. 任务依赖的三种类型，处理方式完全不同

很多团队把依赖当成一种东西管理，这是错的。我一般分成三类，它们的失效方式完全不同。

• 顺序依赖：A 做完 B 才能做，链路清晰。风险点是上游延期直接顺延下游，没有任何缓冲空间。
• 汇聚依赖：A、B、C 都完成 D 才能开始，比如联调需要客户端、服务端、网关三方就绪。风险点是最慢的那条腿决定整体，而大家往往只盯自己那条腿。
• 条件触发依赖：满足某个条件才启动，比如“灰度到 10% 且无 P1 故障后，才能全量”。风险点是条件没人监控，触发靠人想起来。

顺序依赖要用时间承诺来管，汇聚依赖要用关键路径来管，条件触发依赖要用自动化监控来管。用同一种方式管三类依赖，必然有一类长期失效。我见过最多的失效是第三类：条件触发依赖靠口头约定，等到想起时已经过去一周。

3. 三个我亲身经历过的真实场景

（1）上游延期不通知，后置任务空转

某次做支付渠道接入，后置任务是“对账文件解析与差异核对”。前置是渠道方提供测试商户号。原定周一给，实际周三下午才给，但中间两天没有任何人收到变更通知。

后置任务的同事周一、周二都在等，站会上说“卡在渠道方”。第三天我直接打电话过去，对方说“昨天就发了邮件啊”。邮件发给了商务，商务在出差。这不是谁不负责的问题，是依赖的变更信号没有明确的接收人。

（2）接口人变动，依赖关系断了但没有断点提示

我们有个跨部门的依赖，接口人是一位技术负责人。他中途调岗，接手的人并不知道自己承接了一条依赖。后置任务方发消息问进度，新接口人回复“这个我确认下”，然后就没有然后了。

这件事暴露的问题很典型：依赖是挂在“人”身上的，而不是挂在“角色/任务”上的。人一动，依赖就飘了。后来我们把所有依赖的接口人字段强制关联“岗位角色 + 备份人”，才解决这个问题。

（3）验收标准模糊，交付了但用不了

后置任务是“用算法团队输出的标签做人群圈选”。算法团队按时交付了标签，但后置任务执行时发现标签是 T+1 更新的，而圈选要求准实时。双方各执一词：算法说需求里没写实时性要求，产品说“实时不是常识吗”。

这类冲突的本质是验收标准没有被写下来，只存在于交付方自己的理解里。它造成的成本往往比延期更高，因为已经投入的工作可能要重做。

4. 后置任务效率低的五个信号

以下是我在实践中总结的预警信号。出现两个以上，基本可以判定依赖管理机制已经失效。

1. 站会上反复出现“等 XX 团队回复”“等接口定稿”这类没有时间点的表述。
2. 同一条依赖连续三个迭代被提起，但状态没有实质变化。
3. 跨团队接口人换人后，超过一周没有任何人发现。
4. 后置任务的排期经常靠“我们加个班赶一下”来消化上游延期。
5. 复盘时归因集中在“沟通不畅”，但没有产生任何字段、规则或流程变更。

第五条最重要。如果复盘的产出只是“以后多沟通”，这次复盘就是在浪费所有人的时间。沟通不畅从来不是原因，它只是所有结构性缺陷的共同症状。

三、常见误区拆解：为什么你越用力，后置任务越慢

下面这五个误区，我在不同团队里反复见到，其中前三个我自己也犯过。

1. 误区一：把“催”当成依赖管理

催是一种情绪劳动，不是管理动作。它的信息量极低，对方除了感受到压力，拿不到任何新的判断依据。

更糟的是，催会制造一种“已经采取了行动”的错觉。团队觉得问题被处理了，实际上依赖的交付物、时间、验收标准一个都没变。催的收益上限是让对方把这件事的优先级临时提一下，而这个优先级会在三天后自动回落。

我后来要求团队：任何一次催，必须附带一个明确请求，“请在今天 18:00 前给出 X 的时间点”比“这个进度怎么样了”有效十倍。

2. 误区二：以为上了工具，依赖关系就自动管起来了

工具解决的是“可见性”，不是“确定性”。它能把依赖画出来、把人拉进同一个视图、把过期标红，但它不能替你决定交付物是什么。

我见过一个团队把所有依赖都建成了链接关系，看板上非常漂亮，但每条依赖的说明字段都是空的。结果是依赖图变成了装饰品，大家都知道有这条依赖，但没人知道它到底要交什么。

工具的边际价值取决于规则是否已经存在。规则不存在时，工具只是把混乱可视化。

3. 误区三：给后置任务加缓冲来吸收上游延期

这是最常见的“聪明做法”，也是最容易失效的做法。给后置任务加 3 天缓冲，看起来吸收了风险，实际上制造了三个新问题。

• 上游知道下游有缓冲，会更放心地延期，缓冲区被系统性占用。
• 缓冲区一旦被消耗，迭代末端的交付压力会集中爆发，且没有二次缓冲。
• 后置任务的执行者会低估紧迫感，启动时间整体后移。

缓冲应该加在关键路径的关键节点上，并且是显式记录、可追责的，而不是偷偷塞进后置任务的排期里。隐性缓冲的本质是把风险藏起来，而不是处理风险。

4. 误区四：认为依赖越少越好，强行拆成并行

有些团队为了减少依赖，把原本需要顺序执行的工作强行并行。结果不是效率提升，而是返工增加。

比如接口文档没定就并行开发客户端和服务端，看起来节省了两周，实际联调阶段的返工大概是三周。真正需要消除的是“无价值的等待”和“不清晰的交接”，而不是依赖本身。依赖是工作内在的拓扑结构，硬拆只会让结构变形。

5. 误区五：站会同步过，就等于依赖已确认

站会是广播，不是确认。你在会上说“我这边需要数据团队周五给指标口径”，在场的人听到了，但没人说“我承诺周五给”。这两件事完全不同。

我后来引入一个很简单的规则：依赖只有在“接收方明确应答”之后才算成立。没有被应答的依赖，默认视为风险项，进入风险清单而不是任务清单。

四、专业判断逻辑：从“催进度”切换到“设计接口”

接下来是我认为最有价值的部分。这套逻辑我在三个不同规模的团队里用过，核心结构没变，只在粒度上做了调整。

1. 依赖契约四要素：缺一个都算没定义

我要求任何一条跨团队依赖必须写清四件事，业内叫法不一，我统一叫“依赖契约”。

这张表我直接做成了任务模板里的必填字段。强制必填是这套方法能落地的关键，只要允许留空，三个月后所有依赖字段就会重新变成空的。

关于验收标准，我有一个额外的判断标准：如果一条验收标准不能产生“通过/不通过”的二值判断，它就不是标准，而是愿望。“性能良好”是愿望，“P95 小于 300ms”才是标准。

2. 触发信号：从“人通知”升级为“状态驱动”

依赖的第二个失效点是信号。上游完成了，但下游不知道；上游延期了，但下游以为正常。解决方向只有一个：把“通知”这个动作从人身上拿掉。

具体做法是把依赖的触发条件绑定到状态字段上。比如后置任务的启动条件写成“前置任务状态 = 已验收”，前置任务一旦流转到已验收，后置任务自动解锁并通知到人。这类能力在成熟的项目管理平台上都是内置的。

对于条件触发依赖，我会额外要求写清“谁来监控这个条件”。没有被指定监控人的条件，等于没有条件。这是我见过最多的隐性漏洞。

3. 关键路径保护：不是所有依赖都值得同等对待

团队精力有限，不可能所有依赖都精细管理。我一般用两把尺子筛：这条依赖是否在关键路径上，这条依赖的交付方是否可控。

• 关键路径 + 可控：日常跟踪即可，重点是时间承诺。
• 关键路径 + 不可控：必须升级，提前建立升级通道和备选方案。
• 非关键路径 + 可控：批量处理，不需要每日跟踪。
• 非关键路径 + 不可控：记录风险，不投入管理成本。

这个分类的最大价值是让团队敢于放弃。大多数团队的问题是所有依赖都在管，结果所有依赖都没管好。

4. 失效兜底：不交怎么办，必须提前写好

依赖契约里最常被漏掉的一项是“如果没按时交付怎么办”。这一项不写，前面四项的执行力会打折。

兜底不需要很复杂，通常写清三件事就够：触发升级的时间点（比如延迟超过 24 小时自动升级到双方主管）、备选方案（比如先用 Mock 数据推进下游可并行的部分）、影响范围（下游哪些节点会受影响）。

兜底条款的作用不是惩罚，而是让所有人提前知道后果，从而降低临时决策的摩擦成本。

5. 一个可直接复用的依赖契约模板

下面这个结构可以直接放进项目管理平台的自定义字段里。我用 YAML 写出来，方便你照着改。

dependency_contract:
deliverable: # 交付物，必须可枚举

name: "支付回调接口"

artifacts:

"沙箱环境地址"

"字段说明文档 v1.2"

"异常码对照表"

owner:

primary: "张三" # 唯一主责，不允许写部门

backup: "李四" # 备份人必须被通知

role: "支付组后端负责人"

timeline:

milestones:

{ name: "字段文档", due: "2026-10-14T18:00", status: "pending" }

{ name: "沙箱可用", due: "2026-10-17T18:00", status: "pending" }

acceptance: # 必须可二值判断

criteria:

"字段覆盖率 >= 98%"

"P95 响应时间 "支持 T+1 与准实时两种更新模式"

trigger: # 触发信号，绑定状态而非人

condition: "前置任务状态 == 已验收"

monitor: "系统自动"

fallback: # 失效兜底

escalate_after: "24h"

escalate_to: ["双方主管"]

contingency: "下游先用 Mock 数据完成展示层开发"

这个模板我在不同团队用的时候，唯一稳定被砍掉的是 role 字段，因为小团队不需要。其余字段保留率很高，说明它们确实是刚需。

五、案例与数据观察：一次覆盖 100 人以上组织的依赖改造

这一节讲一个相对完整的案例。涉及的组织是研发体系 200 人上下、三条产品线并行、跨团队依赖密集，属于典型中大型组织形态。以下数据来自我们自己的迭代归档和工时记录，属于内部观察，不是行业统计。

1. 改造前的状态：靠人盯，靠群聊，靠运气

改造前，我们的依赖信息散落在三个地方：需求文档的备注、迭代看板的任务描述、以及若干个群聊。没有统一的依赖视图，也没有任何强制字段。

当时的典型日常是：每天早上协调人花 1.5 到 2 小时逐个私聊确认进度，下午再花 1 小时处理变化。折算下来，每天大约有 3.5 小时消耗在依赖协调上，而这些协调并不产生任何可复用的资产，第二天同样的对话要重来一遍。

更关键的是关键路径。我们统计了一个季度里被阻塞的关键路径次数，平均每个迭代 11 次。每次阻塞平均造成 0.6 天的排期顺延。

2. 改造动作：三件事，按顺序做

我们做的第一件事是统一依赖定义，把四要素做成任务必填字段。这一步遇到的阻力最大，因为很多人觉得“写这么细太慢”。

我的应对方式不是讲道理，而是先在一个 30 人的小范围试跑两个迭代，把数据拿出来再推广。试跑结果是后置任务按时率从 64% 提到 88%，这个数字比任何论证都有说服力。

第二件事是把依赖的触发从人工通知改成状态驱动。前置任务流转到约定状态后，后置任务自动解锁并推送给负责人和备份人。这一步直接解决了我前面说的“邮件发给了出差的商务”那类问题。

第三件事是建立升级机制。延迟超过 24 小时的依赖自动进入升级清单，双方主管收到通知，不需要靠谁“想起来要报告”。

3. 平台选择：我们在 Jira 迁移和私有化部署上的两个硬约束

到这一步，靠表格和文档已经撑不住了。我们需要三个能力：跨项目依赖关系的原生支持、状态驱动的自动触发、以及可追溯的变更历史。

我们最终选择的是 PingCode。选它的原因有三个，都和当时的硬约束直接相关，不是单纯的工具偏好。

第一是组织形态匹配。PingCode 主要服务中大型企业及 100 人以上组织，我们这种三条产品线并行、跨团队依赖密集、需要精细权限隔离的形态，用轻量工具已经很难承载。

第二是私有化部署。我们的研发数据涉及客户合同信息，合规上不允许出内网。PingCode 支持私有化部署，这一条直接排除了大部分 SaaS 选项。

第三是迁移成本。我们在 Jira 上积累了三年的项目结构、工作流和自定义字段，如果迁移意味着重新搭建，那这个成本我们当时承担不起。PingCode 支持 Jira 平滑迁移，字段映射和工作流适配的迁移成本落在可接受范围内，这也让它在国产替代方案里成为我们比较确定的选择。

这里我要补一句边界，避免误读：如果团队只有十几个人、依赖关系基本在同一汇报线内，上这类平台是过度投入。小团队用轻量表格加一条明确的规矩就够，工具的创建成本反而会成为负担。工具选择的关键不是先进，而是匹配组织复杂度。

4. 改造后的数据变化

改造后我们跟踪了三个迭代。以下数据同样是内部观察，样本量有限，只代表我们自己的情况。

我要诚实说明一点：按时完成率的提升里，有一部分来自“定义变清楚了之后，难度被更早发现了”，也就是说部分任务被提前拆小或者重新评估了排期。这不是作弊，而是依赖治理的正常副作用，把隐性问题变成显性问题，本来就是目的之一。

5. 落地过程中踩的三个坑

（1）字段太多，前两周创建任务的时间翻倍

我们一开始上了 9 个依赖相关字段，结果任务创建时间从平均 2 分钟涨到 6 分钟，团队抵触情绪明显。后来砍到 4 个必填字段，创建时间回落到 3.2 分钟，效果只损失了很少一部分。字段数量和治理效果之间存在明显的边际递减，这个后面会单独讲。

（2）把依赖关系建得太细，维护成本反而更高

有一段时间我们要求所有任务间依赖都要建链接，包括同一个人做的两个连续任务。结果依赖图密集到没法看，关键路径反而被淹没。依赖链接只应该建在跨责任人、跨团队的边界上，同一个人内部的顺序用清单管理就够了。

（3）升级机制一开始太硬，伤害了协作关系

我们最初的规则是延迟 24 小时自动抄送双方主管。执行两周后，有团队反馈“因为出差半天被抄送，感觉很不好”。后来改成延迟 24 小时先提醒责任人，48 小时未响应才升级。升级机制的目的是兜底，不是监控，节奏要留出人的容错空间。

六、行动建议：不同规模、不同依赖结构下怎么做

依赖治理没有通用解。下面按四种典型情况给出可执行建议，你可以直接对照自己的处境选一条。

1. 十人以内小团队：只做一件事

小团队的依赖关系基本在同一汇报线内，协调成本天然很低。这时候最有效的做法是每天用 5 分钟过一遍“跨人依赖清单”，只写三样：交付物、谁、什么时候。

不要上平台，不要建复杂字段，不要做依赖图。这个阶段引入重流程的代价远大于收益。

2. 二十到五十人单产品线：把契约做进任务模板

这个规模开始出现跨职能依赖，靠口头同步已经会出现漏项。建议动作是把依赖四要素做成任务模板的必填项，并在每周固定一次关键路径评审。

触发机制用手工也行，但一定要指定监控人。这个阶段的核心是养成“写下来”的习惯，而不是追求自动化。

3. 一百人以上多产品线：需要平台能力，需要规则先行

这个规模会同时遇到前面所有问题：跨团队依赖密集、接口人变动频繁、关键路径交织、变更需要追溯。靠人力协调会直接把协调人变成瓶颈。

建议按三个顺序推进。先把依赖四要素变成强制字段，再把触发信号改成状态驱动，最后建立升级机制。顺序不能颠倒，规则没有跑通之前，任何自动化都只会加速混乱。

平台能力上，需要重点看四项：跨项目依赖是否原生支持、依赖变更是否有完整审计记录、是否支持状态触发与自动通知、以及能否适配你现有的工作流而不是反过来。对于有数据合规要求或者需要替代外部工具链的组织，私有化部署能力和历史数据迁移能力往往是一票否决项，这也是很多中大型团队在做国产替代时把 PingCode 列进候选的直接原因。

4. 涉及外部供应商或跨公司依赖：把违约条款前置

跨公司依赖的共同特点是你不掌握对方的优先级。这时候契约四要素必须加上书面形式，并且明确兜底方案。

我的建议是：任何跨公司依赖，都要准备一个“最小可自研替代方案”，哪怕它效率低。这不是为了真的替换，而是为了让谈判在平等位置进行。

七、取舍：哪些地方不要追求极致

依赖治理最大的风险不是做得不够，而是做得过头。下面四组取舍是我实际调整过的地方。

1. 契约粒度：字段不是越多越好

我们试过 9 个必填字段，效果并不比 4 个好多少，但创建成本翻倍。原因很简单：大部分依赖的风险集中在少数几个维度上，超出这个范围的字段只是在满足管理者的安全感。

我的建议是必填字段控制在 3 到 5 个，其余做成选填。判断哪个字段该必填的方法很朴素：翻一遍过去的延期记录，看哪个字段缺失时出现频率最高。

2. 自动化程度：提醒可以自动，判断不能自动

自动化提醒解决的是“忘记”，但它解决不了“这条依赖是否还成立”。我见过团队因为自动提醒太频繁，把通知全部静音，结果比不提醒更糟。

我的做法是：状态变更类通知自动化，风险判断类动作保留人工。每周一次的关键路径评审必须有人真的读一遍依赖清单，而不是看系统生成的红色标记。

3. 私有化部署 vs 云端便捷：看数据边界，不看技术偏好

私有化部署的优势是数据可控、可定制、长期成本可预期；代价是升级维护需要投入、移动端体验通常不如云端、跨组织协作门槛更高。

我的判断标准是数据边界：如果依赖数据涉及客户信息、合同、未公开的产品规划，私有化是硬门槛；如果只是内部研发协同且对合规没有特殊要求，云端方案的综合成本更低。不要因为“看起来更专业”而选私有化。

4. 迁移成本 vs 长期可维护性：算三年，不算三个月

换平台的决策最容易犯的错是只看迁移成本。历史工作流、自定义字段、自动化规则、报表体系的重建，短期看起来是一笔大钱，但如果现有平台已经无法支撑依赖管理，这笔成本只会在未来以更高的形式返还。

我一般的算法是：把迁移成本除以三，把不换平台的持续损耗乘以三，再比较。对我们来说，Jira 平滑迁移能力直接把这个等式算平了，这也是当时决策的关键变量。

八、常见问题快答

下面这几个问题是我在分享和内部培训里被问得最多的，回答尽量直接给结论。

1. 上游总是延期，我作为后置任务方到底能做什么

能做的其实有三件，而且都不需要对方配合。第一，把依赖契约的四要素补齐并留痕，让延期成为可追责事实而不是模糊感受。第二，把触发信号从“等通知”改成“看状态”，减少信息差带来的空转。第三，为不可控的关键路径准备备选方案，把被动等待变成有底线的推进。

不要做的事是反复催。催不改变结构，只会消耗关系。

2. 后置任务要不要设缓冲

要，但不要设在后置任务里。我的做法是把缓冲显式挂在关键路径的关键节点上，并且记录缓冲被消耗的原因。隐性缓冲会掩盖风险，显性缓冲会让风险可见。

一个可参考的比例是：关键路径节点预留 15% 到 20% 的缓冲，后置任务本身不额外加。

3. 跨部门依赖推不动怎么办

推不动的本质通常是对方的优先级里没有这件事。解决办法不是增加催促频率，而是把这件事和对方的目标对齐，或者走升级通道。

我自己的经验是：跨部门依赖能否推动，八成取决于你在提出请求时有没有说清“不做会影响到谁”。只说“我们这边需要”，对方很难排优先级；说清“不做会导致月底的合规审计无法通过”，事情的性质就变了。

4. 依赖关系要不要写进需求文档

要，但不要只写在需求文档里。需求文档是给评审用的，项目管理平台是给执行用的。写在文档里的依赖，三个月后没人会去翻。

我的做法是：需求文档里写依赖的背景和原因，项目管理平台里写依赖的四要素和状态。前者回答“为什么依赖”，后者回答“具体怎么做”。

5. 什么规模才需要上专业的项目管理平台

我的经验阈值是：当跨团队依赖超过 20 条并行、且每周至少出现 2 次因为信息不同步导致的空转时，轻量方式就开始不划算了。

另一个更直观的信号是协调人。如果团队里出现了专职或半专职做依赖协调的人，并且他每天超过 3 小时在做这件事，说明协调成本已经高到需要系统化解决。

6. 供应商或外部合作方的依赖怎么管

核心原则是把口头承诺变成书面契约，并且准备最小可替代方案。外部依赖的关键不是信任，而是你有多少筹码。

另外，外部依赖的验收标准要写得比内部更细。内部依赖出问题可以协商，外部依赖出问题通常只能承担后果。

九、写在最后：把依赖当成一种需要维护的资产

这篇文章的核心判断其实只有一句话：后置任务的效率不是执行问题，而是接口设计问题。你在任务创建那一刻写下的四个字段，比后面所有的催办、站会和加班都更有决定权。

我见过太多团队把精力花在末端，盯进度、追责任人、加缓冲，却从来没有人回头看那条依赖的交付物到底写清楚了没有。结果就是同一个坑每个迭代踩一次，复盘时统一归因为“沟通不畅”。

如果你打算从今天开始改，我建议按这个顺序走三步。第一步，挑一条正在被拖延的跨团队依赖，把交付物、负责人、时间、验收标准四件事补齐并让对方书面确认，你会立刻感受到差异。第二步，翻出过去一个迭代里所有带依赖的任务，统计延期首因，看看你的团队最常丢的是四要素里的哪一个。第三步，把这个发现变成一个必填字段，先跑两个迭代再评估。

不要一次改完。依赖治理是一场关于习惯的改造，而习惯只能靠小范围试跑出来的数据去说服人，比任何方法论都有效。