很多项目的交付节奏在排期表上看起来是完整的：开发任务有截止时间，测试有窗口，发布有日期。但真正临近交付时，问题往往不出在已经列出的任务上，而出在那些从未被当成正式事项管理的依赖上。比如接口提供方迟迟未给出联调环境、生产防火墙策略还在审批、短信签名审核超过预期、第三方证书只在工作日特定时段可验证。于是出现一个常见结果：任务按时完成，项目仍无法交付。
这不是执行力问题，而是依赖识别和跟踪机制缺失。任务管理回答“我们做了什么”，依赖管理回答“我们还在等什么，谁来解除等待，等不到时怎么办”。后者如果没有台账和检查点，就只能靠个人记忆和临时追问，越临近交付越被动。
依赖台账要登记什么
依赖台账不是风险清单的扩展，也不是把所有“可能影响项目的事”都写进去。它只记录会直接阻塞交付、且不由当前团队单方面完成的事项。登记范围过宽会让台账失去可跟进性，过窄又会漏掉关键等待项。
建议每项依赖至少包含以下字段：
- 依赖名称：用一句话说明需要什么，例如“支付网关生产环境回调地址开通”。
- 依赖类型：外部接口、环境资源、权限审批、验证窗口、第三方排期等。
- 影响范围：阻塞哪个模块、哪个发布节点或哪个验收动作。
- 依赖方：提供资源、审批或配合验证的具体团队或个人。
- 责任人：项目侧负责跟进该依赖的人，不是依赖方的人。
- 期望确认时间：希望最晚在什么时间点拿到明确答复。
- 验证方式：怎样判断依赖已真正解除，而不是“对方说可以了”。
- 升级条件：超过什么时间或出现什么情况时，需要上升到更高层级。
- 当前状态：已识别、跟进中、已确认、有风险、已阻塞。
依赖类型值得单独定义，因为它决定了跟进节奏和升级对象。外部接口依赖通常需要尽早锁定联调窗口；权限审批依赖要识别审批链长度和审批人不在岗风险；验证窗口依赖则必须倒排，因为错过一个窗口可能直接推迟数天。
用状态定义把台账变成动作
台账最常见的失败方式，是状态只有“未完成”和“已完成”。这种二分法无法反映等待过程中的风险变化，也无法指导下一步行动。
建议把依赖状态细化为五个值，让每个状态都对应一个明确动作：
已识别：刚登记，尚未与依赖方确认。下一步动作是确认对方是否知情、可行性和时间预期。
跟进中：已联系依赖方，正在等待答复或处理。需要明确下一次追问时间，而不是“等对方回复再说”。
有风险：对方答复含糊、时间可能超出预期，或中途出现变化。需要通知项目负责人，并准备备选方案或调整排期。
已阻塞：超过升级条件或对方明确无法按原时间满足。需要升级决策，不能再停留在执行层追问。
已确认：依赖已实际解除，且通过验证方式确认，不再是口头承诺。
状态的价值在于区分“等待中的正常状态”和“等待中的风险状态”。很多项目直到依赖方正式说“不行”才意识到阻塞，但风险信号往往早在一两周前就通过延迟答复、含糊承诺、审批人不明确等形式出现过。状态定义的意义，就是让这些信号有地方被记录和被看见。
检查点与升级条件
依赖台账只有在固定检查点被过一遍，才会从文档变成机制。检查点不需要多，关键是每个检查点都要产出明确结论和行动项。
周会检查：每周一次，逐项过一遍所有“已识别”和“跟进中”状态的依赖。只问三个问题：上次承诺的时间是否兑现？当前状态是否发生变化？下一步谁在什么时间做什么？
里程碑检查：在关键里程碑前一周，对里程碑路径上的全部依赖做一次完整确认。这里不是过状态，而是重新评估每个依赖是否仍然成立、验证方式是否仍然有效。里程碑检查的输出应包括：哪些依赖已实际解除、哪些需要升级、哪些需要调整里程碑时间。
升级条件要写得具体到“时间点加现象”，不能只写“无法满足时升级”。例如：
- 期望确认时间已过三天，且依赖方未给出新的明确时间；
- 依赖方两次承诺时间均未兑现；
- 验证时发现对方提供的环境、权限或数据与需求不符，需要更换方案；
- 现状已确定影响发布窗口，且项目侧无法通过调整顺序消除影响。
升级不是把问题抛出去，而是把决策权转移到有资源解决问题的人手上。升级时应带上依赖台账中的完整信息：等待什么、等多久了、影响什么、需要谁做什么决定。这样接收方不需要重新了解背景，就能直接进入决策。
让检查产生可执行输出
每次检查依赖台账，都要以“变更了什么”作为结束，而不是“都说了一遍没问题”。有效的检查输出包括三类：状态更新、行动项变更、升级发起。
具体操作上，依赖台账可以保持一个恒定的维护节奏：新增依赖在启动会或周会上登记，状态变化随时更新，每周检查时清理已确认项和重新评估风险项。已确认的依赖不要急着删掉，至少要保留到交付完成后，因为有时“已确认”的依赖会在后续验证中暴露出问题，需要回溯当时的确认依据。
对于由外部团队控制的依赖，台账还承载一个额外作用：积累证据。当交付延迟需要复盘或向上升级时，台账能展示依赖是何时识别、何时跟进、何时升级的，避免“你为什么没提前说”变成无解争论。
依赖管理的最终目标不是消除所有依赖，而是让每一个等待都有明确边界：谁在跟进、等到什么时候、等不到怎么办。这套机制建立之后，项目排期才能从“任务排期”变成“交付排期”，团队也不会再被那些看似小事、实则卡住交付的依赖反复绊倒。
发布者：jacky，转转请注明出处：https://kubiyun.com/archives/4593
评论列表（8条）
把“等对方回复”也定个追问时间，确实很关键。
@海纳百川：对，最好顺手写明谁在什么时间追问，不然一句“等回复”很容易就没下文了。
验证方式那条写得挺实在，口头说可以了真不算数。
@巴黎圣母院：对，最好再实际走一遍验证流程，不然只是把口头承诺换成了文档。
审批人不在岗这类情况，确实得提前纳入排期。
依赖别什么都往里塞，不然台账很快就没人看了。
依赖方和项目侧责任人分开写，这点很容易被忽略。
@阿鹏：这两个角色一混，最后很容易变成“等对方处理”，却没人盯下一步。