依赖关系管理指南：研发团队如何做好任务依赖，协同管理全流程

去年第三季度，我带的一个12人研发小组做了一个看似简单的功能迭代：给订单系统增加一个"部分退款"能力。排期时说好两周完成，最后拖了整整六周。复盘时我们发现，真正写代码的时间只有9天，剩下的时间全耗在等待上，前端等后端接口联调、后端等支付网关的沙箱环境、测试等一个第三方对账系统的权限开通、产品等法务确认退款文案的合规性。这些等待没有一条被提前登记在排期表里，也没有一条在每日站会上被当作"阻塞"来跟进。

它们就那样静静地躺在每个人的脑子里，直到某天有人发现"哦，原来我需要等的东西还没好"。

这件事之后，我开始系统地研究研发团队的任务依赖管理。我发现一个反常识的结论：大多数研发团队的延期，不是因为任务本身难做，而是因为依赖关系从未被当作一等公民来管理。我们把精力花在拆任务、估工时、排优先级上，却默认依赖关系是"排期时顺便想一下"的附属品。但依赖关系有自己的生命周期：它会被识别、被登记、被可视化、被同步、被预警、被复盘。任何一个环节断裂，都会在交付时以"阻塞"的形式加倍奉还。

这篇文章不会重复"什么是强依赖弱依赖"的教科书定义，也不会给你一份工具推荐清单。我会按依赖关系的全生命周期六个阶段，把每个阶段的具体动作、判断标准和常见误区拆开讲。我还会引入一个我自己在用的概念，"依赖负债"，用来量化那些被忽视的依赖关系如何在暗处累积成交付风险。如果你带研发团队、做项目管理或负责研发效能，这套框架可以直接用在下一个迭代。

一、核心结论：依赖管理是信息同步机制，不是排期附属品

在展开六个阶段之前，我想先把结论摆在前面。这个结论决定了你后面所有动作的方向。

第一，依赖管理的本质是信息同步，不是进度控制。很多团队把依赖管理理解为"在甘特图上画一条箭头"，这是把手段当成了目的。依赖关系之所以成为问题，根本原因是它存在于某个人的脑子里，而没有被同步到需要它的人那里。排期表上的箭头只是同步的一种载体，不是同步本身。

第二，依赖关系的生命周期比任务本身更长。一个开发任务可能3天就完成了，但它引入的依赖关系从需求评审时就存在，到上线后可能还在（比如对某个第三方接口的依赖会持续存在）。用管理任务的方式管理依赖，必然遗漏。

第三，依赖管理的收益不是"不延期"，而是"延期可预期"。没有任何机制能保证所有依赖都按时就绪。好的依赖管理让你在依赖出问题的早期就知道，从而有时间调整范围、调配人力或重新谈判交付时间。它管理的是不确定性，不是确定性。

第四，"依赖负债"会复利。一个未被登记的依赖，会导致站会上的信息缺失，进而导致排期失真，最终导致交付延期。而延期又会引发新的依赖调整，产生新的未登记依赖。这个循环一旦启动，团队会陷入"永远在救火"的状态。

第五，机制先于工具，透明度先于控制感。如果你还没有让团队养成"识别依赖、登记依赖、每日同步依赖状态"的习惯，先不要买工具。工具会放大你已有的机制，机制好则效率翻倍，机制差则混乱加倍。

这五条结论贯穿后面的所有内容。下面进入具体的场景和拆解。

二、真实场景：依赖阻塞在研发团队中如何发生

我在过去三年里观察过七个不同规模的研发团队，从8人创业团队到200人的企业研发中心。依赖阻塞的表现形式不同，但发生机制高度一致。

1. 三种典型的依赖阻塞场景

场景一：接口依赖的"最后一天才联调"。前端和后端约定好接口字段，各自开发。前端用Mock数据开发完了所有页面，后端也自测通过。但在联调当天发现，双方对某个字段的类型理解不一致，后端返回的是数字，前端按字符串处理。这个差异在Mock阶段完全看不出来，联调时集中爆发，修复花了三天。

这个场景的核心问题不是技术问题，而是依赖的验证时机太晚。依赖关系在需求评审时就被识别了（前后端需要联调），但没有被登记为一个需要提前验证的节点。

场景二：环境依赖的"以为别人已经准备好了"。测试团队需要在预发布环境验证退款功能，但预发布环境的支付网关配置一直没人更新。测试以为运维会处理，运维以为后端在部署时会顺带更新配置，后端以为这是测试环境的事。三方都"知道"这个依赖存在，但三方都以为别人在跟进。

这个场景的核心问题是依赖的责任人缺失。依赖关系被识别了，但没有指定谁负责推动它就绪。

场景三：外部依赖的"不可控但可预期"。团队要接入一个新的第三方风控服务，对方承诺"两周内提供测试账号"。两周过去了，账号没来。团队只能等，因为没有替代方案。但事后复盘发现，对方在第五天就发了一封邮件说"需要你们先签署一份数据使用协议"，这封邮件被淹没在某个人的收件箱里。

这个场景的核心问题是依赖的预警机制缺失。外部依赖的延迟几乎必然发生，但团队没有设置"如果第X天还没就绪就升级"的规则。

2. 一个可以量化的观察

我让这七个团队分别统计了自己最近一个季度的迭代延期原因。虽然各团队的分类口径不同，但有一个共性：在"延期超过3天"的迭代中，平均有62%的延期天数可以归因于依赖未及时就绪，而非任务本身的工作量低估。这个数字因团队而异，最低的团队是41%，最高的团队是78%。

需要注意的是，这个统计来自我自己的样本观察，不是行业研究报告，样本量和统计口径都有局限。但它指向的方向与多个研发效能报告一致：跨团队依赖和外部依赖是研发延期的主要根因之一。具体的行业百分比数据因报告口径差异较大，引用时需注明来源和年份。

3. 为什么依赖问题在研发场景中特别突出

研发工作有三个特性，使得依赖管理比其他职能领域更难。

• 依赖的不可见性高。销售团队的依赖通常是"等客户回复"，这是可见的。研发团队的依赖可能是"等某个服务部署到某个环境"，非技术人员看不懂，甚至不同角色的研发人员也未必清楚。
• 依赖的变更频率高。需求一变，接口就变；技术方案一调，依赖关系就变。依赖关系不是静态的，它需要被持续维护。
• 依赖的验证成本高。两个模块是否真的能对接，只有实际联调才能确认。这意味着依赖的"就绪"不是一个时间点，而是一个需要验证的过程。

这三个特性决定了：研发团队的依赖管理不能靠"排期时想一下"，必须有一套贯穿全流程的机制。

三、常见误区：为什么你的依赖管理没有效果

在讲具体方法之前，我先拆解六个我反复看到的误区。这些误区有一个共同特征：它们看起来都在做依赖管理，但都没有触及依赖关系的生命周期。

1. 误区一：把依赖管理等同于画甘特图

甘特图上的依赖箭头只能表达"A完成之后B才能开始"这种简单的前后关系。但研发场景中的依赖远不止于此：A的某个接口字段需要和B对齐、A的测试需要B提供特定数据、A的上线需要B的环境先就绪。这些依赖无法用一条箭头表达。

判断标准：如果你的依赖管理只发生在排期阶段，排期之后就不再更新，那它本质上不是依赖管理，只是排期的一个步骤。

2. 误区二：依赖登记后不更新

我见过一个团队建了一个很规范的依赖台账，Excel表格，字段齐全。但三个月后打开一看，状态列还停留在登记时的"待处理"。问起来，负责人说"后来太忙就没更新了"。

依赖台账的价值不在于登记，而在于状态更新。一个不更新的台账，比没有台账更危险，因为它会给人"依赖已经被管理了"的错觉。

3. 误区三：站会上把依赖问题淹没在进度汇报中

典型的每日站会是这样：每个人说"我昨天做了什么、今天做什么、有什么阻塞"。依赖问题通常被归入"阻塞"，但站会的时间限制（通常15分钟）和发言顺序（按人头轮流）导致依赖问题被一笔带过。

更糟的是，有些依赖问题甚至不被视为"阻塞"，"我在等后端接口，但我可以先做别的"，这种"软阻塞"在站会上根本不会被提及，直到它变成硬阻塞。

4. 误区四：只管理团队内部的依赖，忽略跨团队和外部依赖

团队内部的依赖，靠站会和口头同步还能勉强应付。但跨团队依赖和外部依赖，超出了团队日常沟通的范围，如果不建立专门的机制，几乎必然出问题。

一个经验判断：当一个迭代中包含超过3个跨团队依赖时，仅靠站会同步已经不够了，需要专门的依赖对齐会。

5. 误区五：认为引入工具就能解决问题

工具能做的事是：让依赖关系可视化、让状态变更可追踪、让预警自动触发。但工具不能做的事是：让团队养成识别依赖的习惯、让责任人主动更新状态、让管理者在预警触发时做出决策。

工具是机制的放大器，不是机制的替代品。先有机制，再用工具固化机制。

6. 误区六：依赖管理只在上线前才被重视

很多团队在迭代末期才发现依赖问题，然后集中救火。但依赖管理的黄金时间是在需求评审和技术方案评审阶段，那时依赖关系刚刚形成，调整成本最低。

越晚发现依赖问题，解决成本越高。一个在需求评审时发现的接口依赖，调整成本可能只是改一句话；一个在联调时发现的接口依赖，调整成本可能是三天返工。

四、专业判断逻辑：依赖全生命周期的六个阶段

把依赖关系当作一个有生命周期的对象来管理，是我认为最有效的框架。这个生命周期分为六个阶段：识别、登记、可视化、同步、预警、复盘。每个阶段有明确的动作和判断标准。

1. 阶段一：识别依赖，从隐性到显性

核心动作：在需求评审、技术方案评审、迭代计划会三个时机，强制识别依赖关系。

依赖的类型不止"强依赖"和"弱依赖"两种。在研发场景中，我建议至少区分六种：

常见误区：只识别"人"的依赖，忽略"系统"和"环境"的依赖。很多团队会记得"等张三提供接口"，但不会记得"等预发布环境的支付网关配置更新"。

判断标准：每个任务至少标注一个依赖方和依赖类型。如果一个任务被标注为"无依赖"，需要负责人明确确认，而不是默认跳过。

2. 阶段二：登记依赖，建立统一的依赖台账

核心动作：建立一个所有依赖关系都能被记录和查询的台账，避免依赖散落在聊天记录、邮件和口头承诺中。

依赖台账的最小字段应该包括：依赖方、被依赖方、依赖内容描述、期望就绪时间、实际状态、接口人、升级路径。其中"实际状态"必须支持定期更新，建议至少每周更新一次，关键依赖每日更新。

登记责任需要明确：由任务负责人登记依赖，由项目经理或Scrum Master审核台账的完整性。不要让项目经理替所有人登记，那样会变成"项目经理一个人的台账"。

常见误区：登记后不更新，台账变成"一次性文档"。解决方法是把台账更新嵌入到已有的站会流程中，而不是作为一个额外的任务。

判断标准：任何一个依赖关系，都能在30秒内从台账中查到它的当前状态和接口人。如果做不到，说明台账没有真正运转起来。

3. 阶段三：可视化依赖，让阻塞看得见

核心动作：用看板连线、甘特图依赖箭头或依赖矩阵，把依赖关系从隐性变为显性。

三种可视化方式各有适用场景：

• 看板连线：适合迭代内的任务级依赖，能直观看到"谁在等谁"。优点是与日常站会结合紧密，缺点是跨迭代的依赖难以展示。
• 甘特图依赖箭头：适合跨迭代、跨团队的依赖，能展示时间线上的前后关系。缺点是无法表达"非时间型"依赖（如数据依赖、决策依赖）。
• 依赖矩阵：适合展示团队之间的依赖关系全貌，能快速识别"依赖集中度"。缺点是不够直观，需要一定的解读成本。

对于大多数研发团队，我推荐迭代看板加依赖泳道的组合。在看板上增加一条"等待中"泳道，任何被依赖阻塞的任务卡片移入该泳道，并在卡片上标注依赖方和接口人。这样每天站会时，等待中的任务一目了然。

关键提醒：可视化不是目的，同步才是。如果看板上的依赖泳道没人看，那它只是一个装饰。

判断标准：任何人在任何时候都能看到"谁在等谁"。如果你需要问三个人才能搞清楚一个依赖关系的当前状态，说明可视化没有做到位。

4. 阶段四：同步依赖，建立接口人、站会、同步会三层机制

核心动作：建立三层同步机制，对应不同范围和频率的依赖。

第一层：接口人机制。每个依赖方指定一个对接人，负责信息同步和进度对齐，避免多头沟通。接口人不是"传话筒"，而是有权协调本方资源、对依赖就绪时间给出承诺的人。

第二层：站会依赖环节。每日站会设置专门的"依赖阻塞"环节，限时2分钟，只过依赖泳道中的卡片。每张卡片只回答三个问题：依赖方是谁、期望就绪时间是什么、当前状态是否有变化。

这个环节的关键是与进度汇报分离。不要让依赖问题混在"我昨天做了什么"的汇报中，那样它会被淹没。

第三层：迭代同步会。每个迭代至少一次跨团队依赖对齐会，参与方是所有有跨团队依赖的接口人。会议输出是一份更新后的依赖台账和明确的升级事项。

常见误区：站会变成汇报会，依赖问题被淹没在进度汇报中。解决方法是把依赖环节放在站会的最后，单独计时，并且只讨论"状态有变化"的依赖。

判断标准：依赖阻塞在24小时内被识别并进入处理流程。如果一个问题在站会上被提及但连续三天没有进展，说明同步机制失效了。

5. 阶段五：预警依赖，从被动响应到主动干预

核心动作：设置明确的预警触发条件和升级路径，让依赖问题在变成危机之前就被处理。

预警的触发条件应该包括：

• 时间触发：距离期望就绪时间还有X天，但状态仍为"未开始"或"进行中"。
• 进度触发：依赖方的进度明显滞后于计划，且没有给出新的承诺时间。
• 变更触发：依赖内容发生变更，需要重新评估影响。

预警方式分为工具自动提醒和人工升级机制。工具可以做时间触发和变更触发的自动提醒，但进度触发和升级决策需要人工判断。

升级路径必须提前定义：接口人无法推动时，升级到项目经理；项目经理无法解决时，升级到团队负责人；涉及跨部门时，升级到更高层的协调机制。每级升级应该有明确的时间阈值，比如"接口人沟通两次无果后，24小时内升级"。

常见误区：预警触发后没有人响应。这通常是因为升级路径不明确，或者升级后被当作"告状"。团队文化上需要明确：升级依赖问题是正常的工作流程，不是对个人的指责。

判断标准：依赖阻塞在24小时内被识别并进入处理流程；超过48小时未解决的依赖，必须出现在更高层的协调会议上。

6. 阶段六：复盘依赖，度量、归因、改进

核心动作：在迭代复盘时，专门分析依赖管理的效果，度量三个核心指标，并归因到具体环节。

三个核心度量指标：

• 依赖阻塞次数：一个迭代中，因依赖未就绪导致任务停滞的次数。这个指标反映依赖管理的"量"。
• 平均阻塞时长：每次阻塞从发生到解除的平均时间。这个指标反映依赖管理的"质"。
• 依赖变更频率：一个迭代中，依赖关系发生变更的次数占总依赖数的比例。这个指标反映需求和技术方案的稳定性。

归因分析要回答：是识别遗漏（依赖根本没被发现）、同步不及时（发现了但没同步）、还是排期不合理（依赖识别了也同步了，但就绪时间本身不现实）。

改进动作应该具体到流程变更：更新依赖台账模板、优化站会依赖环节的时间分配、调整接口人机制、或者在上游的需求评审阶段增加依赖识别检查项。

引入"依赖负债"概念：未及时管理的依赖会像技术负债一样累积。每一条未登记的依赖、每一次未更新的状态、每一个未升级的阻塞，都会增加未来的交付风险。把"依赖负债"作为一个复盘指标，可以帮团队量化依赖管理的收益。

五、具体案例：一个30人研发团队的依赖管理改造

下面这个案例来自我深度参与的一个30人研发团队，他们的业务是中大型企业级项目的定制开发。我选择这个案例，是因为它足够复杂，既有团队内部依赖，也有跨团队和外部依赖，能完整展示六个阶段的应用。

1. 改造前的状态

改造前，这个团队的迭代按期交付率大约是54%。他们的排期方式是：产品经理在项目管理工具中创建任务，指定负责人和截止日期，但任务之间的依赖关系完全没有记录。

每日站会是标准的"三问题"模式，每个人轮流说。依赖问题偶尔被提及，但从未被系统跟进。跨团队依赖靠Slack群和私聊解决，经常出现"我以为他跟进了"的情况。

2. 改造动作

我们分三步推进了改造。

第一步：建立依赖台账。在项目管理工具中新增了一个"依赖"任务类型，要求每个依赖关系都创建一条独立记录，字段包括依赖方、被依赖方、依赖内容、期望就绪时间、接口人、当前状态。这一步的阻力最大，"多此一举"是团队的第一反应。

第二步：改造站会。把站会分为两段：前10分钟做常规进度同步，后5分钟专门过依赖台账中状态为"未就绪"的条目。每个条目的接口人简要更新状态，没有变化就跳过。

第三步：设置预警规则。在项目管理工具中设置自动提醒：如果一条依赖距离期望就绪时间还有3天但状态仍为"未开始"，自动通知接口人和项目经理。对于外部依赖，时间阈值设为7天。

他们使用的项目管理平台支持自定义任务类型和自动化规则，同时支持私有化部署，能满足这家企业对数据安全的要求。工具的选择要服务于机制，而不是反过来。

3. 改造后的数据

连续三个迭代后，我们统计了核心指标的变化。

值得注意的是，站会时长增加了3分钟，但迭代按期交付率提升了25个百分点。这个权衡在大多数团队看来是值得的。

另一个值得注意的数据是依赖变更频率只下降了9个百分点。这说明依赖变更的主要来源是需求和外部环境本身，流程优化能缓解但无法消除。不要期待依赖管理能消灭依赖变更，它的目标是让变更的影响可预期。

4. 可复用的经验

• 依赖台账要嵌入已有工具流，不要另起炉灶。用Excel单独维护的台账，几乎必然被遗忘。把依赖作为项目管理工具中的一种任务类型，是保证持续更新的关键。
• 站会依赖环节要限时。不限时的依赖讨论会挤占进度同步时间，最终导致整个站会被放弃。
• 外部依赖的预警时间要提前。外部依赖的延迟概率远高于内部依赖，需要更早的预警阈值和更激进的升级路径。
• 把依赖管理效果纳入复盘。如果复盘只谈"做了什么功能"，不谈"依赖管理得怎么样"，机制会慢慢退化。

六、行动建议：不同阶段团队的落地路径

依赖管理不是一次性工程，需要根据团队当前的成熟度分阶段推进。下面给出三种典型情况的建议。

1. 情况一：团队没有依赖管理机制（0到1阶段）

特征：依赖关系只存在于个人脑中，没有台账，站会不专门讨论依赖，延期后归因为"事情太多"。

建议动作：

1. 先做最小可行的依赖台账：只登记"外部依赖"和"跨团队依赖"两类，团队内部的依赖暂时靠站会。
2. 在站会中增加一个3分钟的"依赖阻塞"环节，只过台账中的条目。
3. 连续跑两个迭代后，根据实际情况扩展台账的覆盖范围。

不要做的事：不要一开始就要求所有依赖都登记。那会增加太多负担，导致机制被放弃。先从最痛的依赖类型开始。

2. 情况二：有基本机制但效果不稳定（1到2阶段）

特征：有依赖台账，但更新不及时；站会讨论依赖，但经常跑题或超时；依赖阻塞仍然频繁发生。

建议动作：

1. 把依赖台账的更新嵌入到已有流程中，比如站会依赖环节结束后，接口人立即更新状态。
2. 设置自动预警规则：距离期望就绪时间还有3天且状态未变，自动通知。
3. 定义清晰的升级路径和时间阈值，确保预警触发后有人响应。
4. 在迭代复盘中加入依赖管理指标（阻塞次数、平均阻塞时长）。

3. 情况三：机制成熟但缺少度量（2到3阶段）

特征：依赖管理已经融入日常流程，阻塞能及时发现和处理，但缺少系统的度量和持续改进。

建议动作：

1. 建立依赖管理的度量体系，跟踪阻塞次数、平均阻塞时长、依赖变更频率三个核心指标。
2. 在复盘时做归因分析，区分识别遗漏、同步不及时、排期不合理三类原因，针对性改进。
3. 引入"依赖负债"概念，把未及时管理的依赖量化，作为流程健康度的指标。
4. 考虑用支持依赖管理和自动化预警的项目管理平台来固化机制，特别是对于100人以上的中大型组织，工具的支撑作用会显著放大机制的效力。

4. 情况四：已有跨团队依赖大量存在的组织

特征：多个研发团队之间存在密集的依赖关系，跨团队同步成本高，依赖问题经常在交付末期集中爆发。

建议动作：

1. 建立组织级的依赖视图，展示团队之间的依赖集中度和关键路径。
2. 设立跨团队的接口人网络，每个团队指定一名依赖协调人。
3. 定期（如每两周）举行跨团队依赖对齐会，只讨论有风险的依赖。
4. 对于依赖关系复杂、跨团队协作频繁的中大型企业研发组织，可以考虑支持私有化部署和Jira平滑迁移的项目管理平台，以降低工具迁移成本并满足数据安全要求。

七、取舍：依赖管理的成本与边界

任何管理机制都有成本。依赖管理做得过度，会变成流程负担。下面讨论几个需要取舍的场景。

1. 台账详细度与维护成本的取舍

台账字段越详细，信息越完整，但维护成本越高。我的建议是：核心字段（依赖方、被依赖方、依赖内容、期望就绪时间、状态、接口人）必须齐全，扩展字段（如风险等级、影响范围）按需添加。不要为了"看起来规范"而添加没人看的字段。

一个判断标准：如果某个字段在连续三个迭代中都没有被查询或更新过，考虑删掉它。

2. 预警灵敏度与告警疲劳的取舍

预警阈值设得太松，依赖问题发现太晚；设得太紧，告警频繁，团队会产生"告警疲劳"，最终忽略所有告警。

我的经验值是：内部依赖的预警阈值设为3天，外部依赖设为7天，关键路径上的依赖设为5天。同时，预警应该分级，第一次触发只通知接口人，第二次触发通知项目经理，第三次触发才升级到团队负责人。

3. 依赖管理粒度与团队规模的取舍

小团队（10人以下）的依赖关系通常可以通过日常沟通解决，过度正式的依赖管理反而降低效率。建议小团队只管理外部依赖和跨团队依赖，团队内部依赖靠站会口头同步。

中大型团队（30人以上）的依赖关系复杂度和沟通成本显著上升，需要正式的依赖管理机制。对于100人以上的组织，跨团队依赖密集，依赖管理的收益远大于成本。

4. 工具投入与机制建设的取舍

先有机制，再用工具。如果团队还没有养成识别和登记依赖的习惯，引入再好的工具也不会有效果。反过来，当机制成熟后，工具能显著降低维护成本、提高预警的及时性。

在工具选型时，关注三个能力：是否支持自定义任务类型（用于登记依赖）、是否支持自动化规则（用于预警）、是否支持依赖关系的可视化（用于同步）。对于有数据安全要求的中大型企业，私有化部署能力也是一个重要考量。

八、关键判断标准速查

把六个阶段的核心判断标准汇总如下，方便你在实际工作中对照检查。

1. 识别阶段的判断标准

每个任务至少标注一个依赖方和依赖类型。如果任务被标注为"无依赖"，需要负责人明确确认。需求评审、技术方案评审、迭代计划会三个时机必须强制检查依赖。

2. 登记阶段的判断标准

任何一个依赖关系，都能在30秒内从台账中查到它的当前状态和接口人。台账状态至少每周更新一次，关键依赖每日更新。

3. 可视化阶段的判断标准

任何人在任何时候都能看到"谁在等谁"。不需要问任何人就能独立获取依赖关系的当前状态。

4. 同步阶段的判断标准

依赖阻塞在24小时内被识别并进入处理流程。如果一个问题在站会上被提及但连续三天没有进展，说明同步机制失效。

5. 预警阶段的判断标准

超过48小时未解决的依赖，必须出现在更高层的协调会议上。预警触发后，接口人必须在规定时间内响应。

6. 复盘阶段的判断标准

每个迭代复盘都有依赖管理的专项讨论，至少跟踪阻塞次数和平均阻塞时长两个指标，并能归因到具体环节。

九、结论与下一步行动

回到文章开头的那个案例。那六周的延期，如果有依赖管理的六个阶段在运转，会发生什么？需求评审时会识别出"法务确认"是一个决策依赖，提前两周启动；技术方案评审时会识别出"支付网关沙箱环境"是环境依赖，指定接口人跟进；站会依赖环节会发现"第三方对账系统权限"三天没有进展，触发升级；复盘时会归因到"外部依赖的预警阈值设置太晚"，并在下个迭代调整。

这不会让六周变成两周，但很可能让它变成四周，并且团队对延期有预期、有掌控。

我的核心判断是：依赖管理的价值不在于消灭延期，而在于把"不可预期的延期"转化为"可预期的风险"。研发工作本身充满不确定性，依赖关系是最主要的不确定性来源之一。管理它，不是为了让不确定性消失，而是为了在不确定性发生时，你有时间做出选择。

如果你准备开始做依赖管理，我建议从两件事入手，不需要任何工具投入，下一个迭代就能试。

第一件事：建一个最小依赖台账。只登记外部依赖和跨团队依赖，字段只要六个：依赖方、被依赖方、依赖内容、期望就绪时间、状态、接口人。用你团队已有的项目管理工具创建一个自定义任务类型，不要单独开Excel。

第二件事：站会加一个三分钟的依赖环节。放在站会最后，只过台账中状态为"未就绪"的条目，接口人只回答"状态是否有变化"。没有变化就跳过，有变化就说明下一步动作和时间。

连续跑两个迭代，然后在复盘中看两个数据：依赖阻塞次数和平均阻塞时长。如果这两个数据有改善，说明机制起效了，再考虑扩展台账覆盖范围和引入自动预警。如果没有改善，先检查是不是台账更新不及时、或者站会依赖环节被挤掉了。

依赖管理是研发协同的基础设施。它不像新功能那样显眼，但它决定了你的团队是在"可预期的节奏"中交付，还是在"随机阻塞"中挣扎。从一个台账、三分钟站会环节开始，你会看到变化。