依赖比工时更影响日期
同一套系统在两家企业上线，差出一个月的原因往往是接口审批与网络策略。怎么做：把每个外部依赖列成一行，写明对接方、所需材料、预计审批时长与最晚启动日，再倒排进整体计划。
先找关键路径
关键路径是决定总工期的那条链，可能是数据授权而不是编码。如何识别：把任务按前后置关系连线，找出没有浮动时间的最长链；优化时只压缩关键路径上的环节，动其他环节不会提前一天。
浮动时间要写出来
给每段留出浮动时间并在计划里显式标注，评审时据此判断风险敞口。为什么必须写出来：没有标注浮动的计划看起来紧凑，一遇审批延期就整体顺延，最后要么压缩测试要么跳步上线。
按决策点对外沟通
对管理层报三个决策点：可行性确认、可用性确认、放量确认，每点附判据与不通过时的处置。为什么不用总工期承诺：任何依赖变更都要重新解释，按决策点沟通，讨论的是判断依据。
有些依赖只能提前不能压缩
等保测评、数据出境评估、供应商合同评审都有法定或内部流程时限，压缩空间很小。边界在于：这些环节可以并行准备材料、提前预审，但不能跳步；把希望寄托在加急上，通常换来的是退回重做。
适用与不适用
适合谁
- 依赖多个外部供应商或内部审批的系统
- 有明确上线窗口、无法整体顺延的项目
- 需要向管理层定期汇报进度的交付
不适合谁
- 单机部署、无外部依赖的内部试验
- 范围与时点随时可调的探索型项目
典型场景
某医药流通企业计划上线订单异常识别，原排期十二周。项目组把依赖摊开后发现，数据授权与两家上游系统的接口排期合计占去五周，且与开发之间没有前后置关系。调整后把这两项提前到第一周启动，开发与调参并行，最终按原窗口上线，测试反而多出三天。
可执行步骤
- 把全部外部依赖列成一行一项，写清对接方、所需材料与最晚启动日期
- 画出任务之间的前后置关系，找出没有浮动时间的最长链作为关键路径
- 在计划里显式标出每段的浮动时间，评审时用它向管理层解释风险敞口
- 把审批类工作提前到第一周启动，与开发、调参并行推进，不设前后置
- 按三个决策点向管理层汇报，每点附判据与不通过时的具体处置方案
常见坑
- 按开发工作量倒推上线日期，忽略审批与接口排期，计划第一次评审就被推翻，团队信誉受损。
- 所有任务都排满负荷、不留浮动，任何一次审批延期都会整体顺延，最后只能压缩测试赶回日期。
- 把等保测评、数据出境评估当成可加急事项，临到上线才发现无法压缩，窗口整段作废并需重排。
- 业务高峰与上线时间重叠，问题被流量放大，值班人力不够，故障处置时间成倍增加，日志也被淹没。
自检与验收清单
- 外部依赖是否逐项写明对接方、所需材料与最晚启动日期
- 关键路径是否标出，优化动作是否只落在关键路径上
- 每段任务是否显式标注浮动时间与超期后的处置
- 审批类工作是否已提前启动，而不是排在上线前的后段
- 对外汇报是否按决策点组织，而非承诺一个总工期
常见问题
排期能不能先给个总工期？
可以给区间，但要说明假设：依赖按时到位、范围不变、评审一次通过。把这些假设写进排期说明，比给一个精确日期更负责；一旦假设变化，讨论就回到依赖本身，而不是纠结谁当初答应了哪一天。
审批加急有用吗？
取决于环节性质。内部流程在资料齐全时通常可以协调加快，法定评估类则有明确时限，加急空间很小。做法是提前把材料准备到可提交状态，减少退回次数；只催办而不补材料，往往反复退回，反而更慢。
依赖方一直不给排期怎么办？
先把影响量化：这项依赖延期一周，总工期顺延几天、影响哪个决策点，写成一句话发给对方与共同上级。多数时候对方并非不配合，而是不知道自己的拖延会传导到哪一步；量化之后，协调比反复催问有效。