前置任务最佳实践：项目成员任务依赖协同管理，常见问题

2025 年 3 月的一次项目复盘会上，我让团队把一个延期了 47 天的项目任务清单导出成 Excel，按"前置任务"字段做了一次统计：1,860 个任务，470 条依赖关系。其中 132 条依赖指向的任务已经关闭超过 30 天，61 条依赖首尾相连绕成了闭环，还有 88 条依赖的"完成方"是一个没有任何负责人的人名占位符。当时负责交付的总监看着这张表说了一句话："我们不是被技术难题拖垮的，是被这些线拖垮的。"

这句话成了我后来做依赖治理的起点。这篇文章不讲"什么是前置任务"这种百科内容，我只回答一件事：当项目成员真实地在一条依赖链上协作时，哪些做法是有效的，哪些坑是几乎必然踩到的，以及不同规模的团队该做哪些取舍。文中的数据和案例来自我参与复盘的三个中大型项目（累计参与人数约 268 人），样本量有限，结论仅供参照，但每一条坑都有具体的触发场景。

一、先给结论：依赖是承诺，不是连线

1. 三条核心结论

如果只让我说三句话，我会把前置任务治理的所有经验压缩成下面三条。它们看起来朴素，但在实际项目里能同时做到三点的团队，我见过的不到两成。

• 结论一：绝大多数项目不需要那么多依赖。把那 470 条依赖逐条过一遍之后，我们最终只保留了 163 条，剩下的 307 条里，有 189 条是"顺手连的"、有 76 条是"怕出问题多连的"、还有 42 条是重复的传递依赖（A 等 B、B 等 C，于是 A 也去连了 C）。
• 结论二：依赖不是一条线，是一份承诺。一条有效的前置任务关系，至少要说清四件事：交付物是什么、谁负责交、什么标准算交付完成、什么时候必须交。缺任何一项，这条线在下游成员眼里就是噪音。
• 结论三：依赖管理的主要工作量在变更，不在初始化。我们在复盘时统计过，一个项目里依赖关系的初始设置平均耗时 4 小时，而后续因计划调整产生的依赖变更处理累计耗时超过 60 小时，后者是前者的 15 倍。

很多团队的注意力全部花在"怎么把依赖连对"上，实际上真正吃掉项目时间的是"连完之后没人管变化"。一个依赖关系在创建时再完美，只要它不再反映现实，它就从协作工具变成了误导工具。

2. 四种依赖类型的适用边界

做计划的人几乎都知道 FS、SS、FF、SF 这四种类型，但知道和会用是两件事。在复盘的三个项目里，FS（完成-开始）占了全部依赖关系的 91%，SS（开始-开始）占 7%，FF 占 2%，SF 几乎为零。这个分布本身就是问题，不是因为 FS 用得太多，而是因为很多本该用 SS 的场景被硬塞进了 FS，导致排期被人为拉长。

我建议每个项目经理都做一次自查：把当前计划里所有"可以并行但排成了串行"的任务对找出来，改用 SS 或直接去依赖。在我们修复的那个项目里，仅这一项调整就让关键路径上的任务数从 61 个降到了 34 个。

3. 一条判断线：这条依赖是承诺还是猜测

在决定要不要连一条前置任务之前，我只问一个问题：这条依赖背后，有没有一个具体的人，愿意为某个具体的交付物，在某个具体的时间点做出承诺？如果答案是"大概会吧""应该差不多"，那它就不是依赖，是猜测。

承诺和猜测的差别，直接决定你应该把它放哪里。承诺应该进入系统、设成正式的前置任务、纳入变更跟踪；猜测应该留在风险清单里，指定一个人去把它变成承诺或者证伪，而不是污染任务依赖图。我们把 470 条依赖按这条线筛过一遍之后，有 76 条被降级成了风险条目，它们本来就不该出现在甘特图里。

二、真实场景：一个 268 人项目的依赖失控与修复

1. 项目背景与失控信号

这个项目是一家制造企业的核心系统升级，涉及甲方 IT、业务部门、乙方实施团队和两家第三方供应商，累计参与 268 人，其中全职投入的核心成员 42 人。项目 2024 年 9 月立项，原计划 2025 年 1 月上线，实际验收时间是 3 月中旬，延期 47 天。

延期发生后，我被拉进去做复盘。第一周我没有看任何进度报告，只做了两件事：把任务依赖关系全部导出，以及找 12 个核心成员各聊 30 分钟。结果非常一致，没有人是在抱怨技术难度，所有人都在抱怨"等待"和"不知道什么时候轮到我"。

2. 失控的三个信号

回头看，这个项目的依赖失控在很早之前就已经出现了信号，只是当时被当成了正常波动。

1. 信号一：依赖数量增长速度远超任务数量增长速度。立项时 320 个任务、58 条依赖；两个月后 1,240 个任务、391 条依赖。任务涨了 3.9 倍，依赖涨了 6.7 倍。依赖增速超过任务增速，通常意味着有人在"用连线代替沟通"。
2. 信号二：依赖的"接收方"比"输出方"更关心这条线。我抽查了 40 条跨组依赖，其中 34 条只有接收方在自己的看板上关注，输出方团队的周会里从未提过这些交付物。一条依赖只有一方在意，它一定会断。
3. 信号三：同一批任务反复出现在多个依赖链上。有个数据迁移任务被 11 个下游任务同时依赖，成了事实上的超级瓶颈，但项目周报里从未把它标注为风险项。

3. 三周修复：从 470 条到 163 条

修复过程并不复杂，但需要纪律。我们用了三周，每周做一件固定的事，规则对所有团队一致，没有例外。

• 第一周：全量清洗。逐条过 470 条依赖，每条必须在 60 秒内给出判断，保留、降级为风险、或删除。判断标准就是前面那条线：背后有没有具体的人和具体的交付物承诺。
• 第二周：补齐依赖描述。保留下来的依赖，统一按五要素补全：交付物、输出方、接收方、验收标准、承诺完成日。补不齐的，说明它还不是一条合格的依赖。
• 第三周：建立变更规则。约定任何一条依赖的承诺完成日变化超过 1 个工作日，必须在系统内更新并在对应协作群里同步，两者缺一不可。这条规则后来被证明是收益最大的。

依赖描述标准模板（我们最终固化下来的写法）
[交付物] 用户中心 SSO 接口联调完成

[输出方] 后端组 / 张工

[接收方] 前端组 / 李工（同时抄送测试组）

[验收标准] 开发、测试、预发三套环境各跑通 1 次全链路登录；

接口文档 v1.2 已冻结并归档

[依赖类型] FS（完成-开始）

[依赖强度] 硬依赖

[承诺完成日] 2025-01-18

[缓冲设置] 接收方预留 3 个工作日

[变更规则] 承诺日变化≥1 个工作日，需系统更新 + 群内同步双动作

4. 修复后的数据变化

三周之后，依赖数量从 470 条降到 163 条，关键路径上的任务数从 61 降到 34。更值得注意的是后续两个月的表现：平均任务顺延天数从 9.4 天降到 2.6 天，按时交付率从 62% 升到 87%。

需要说明的是，这些数字不能简单归因于"依赖次数减少"。真正起作用的变量有三个：依赖数量下降、每条依赖的信息完整度上升、变更同步机制建立。如果只做第一条而忽略后两条，你得到的只是一个更干净但同样会断的依赖图。

三、九个高频误区：它们几乎必然出现

1. 误区一：为了保险，什么都设成前置

这是出现频率最高的误区。心态很好理解，多连一条线，出问题的时候可以甩锅，看上去也更"严谨"。但代价是计划完全失去弹性：当所有任务都被锁死在依赖链上，成员就失去了自主调节顺序的空间，任何一个环节的轻微延迟都会顺延整条链。

在我们抽查的项目里，被称为"保险型依赖"的关系占清洗总量的 40%。它们的典型特征是没有明确的交付物，只有一个模糊的任务名。修正动作很简单：问一句"如果这条依赖不存在，最坏会发生什么"，如果回答不出具体后果，就删掉。

2. 误区二：把阻塞项当成前置任务

前置任务是计划内的顺序关系，阻塞项是计划外的障碍，两者混用会直接导致优先级判断失误。前置任务应该出现在排期里，因为你可以提前安排、可以协商日期；阻塞项应该出现在风险清单里，因为它需要的是解决问题而不是等待。

常见的混淆场景是"等安全部门审批"。如果审批流程是固定的、周期可预估的，那它是前置任务；如果审批结果本身不确定、可能被驳回并导致方案返工，那它是阻塞风险，你应该准备 Plan B，而不是把它排成一条时间线然后祈祷。

3. 误区三：默认 FS，从不评估 SS 和 FF

FS 是默认选项，因为最符合直觉。但很多真实工作是可以并行推进的：开发开始后测试用例编写就可以开始，数据迁移开始后校验脚本就可以开始，需求评审完成后架构设计就可以启动。这些场景如果用 FS 表达，会凭空产生几天的等待。

我做过一个粗略估算：在一个 6 个月的项目里，如果有 20 个任务对能从 FS 改成 SS，平均能压缩出的等待时间大约是 15 到 30 个工作日。这个量级已经足以影响一次交付节点。

4. 误区四：依赖关系创建之后就没人再管

依赖是有保质期的。任务拆分方式变了、人员换了、优先级调了，原来的依赖关系可能早就不成立。我们抽查的 200 条依赖里，有 63 条对应的前置任务已经完成但依赖仍未解除，有 27 条依赖的两个任务其实已经不在同一个发布批次里。

修正动作是建立"周度依赖巡检"：每周固定 30 分钟，只看三件事，已过期未解除的依赖、承诺日临近但无进展的依赖、下游已开始但上游未完成的依赖。这个动作便宜、可执行，收益却很高。

5. 误区五：只设依赖，不设验收标准

很多团队的依赖描述只有任务名，比如"接口开发完成"。可下游成员拿到这个信号后要做什么？如果接口字段和文档不一致怎么办？如果只覆盖了部分场景怎么办？这些没有约定，依赖就算"完成"了，下游仍要花时间返工。

我的建议是：每条依赖都要写清"什么状态下，接收方可以直接开工不再回头"。这句话通常包含环境范围、文档版本、覆盖场景、验收方式四个要素。写这句话的成本大概 2 分钟，但它能省下的返工时间通常是小时级的。

6. 误区六：跨部门依赖和组内依赖用同一套规则

组内依赖可以靠口头同步、靠站会解决，因为双方共享上下文、沟通成本极低。跨部门依赖完全不同：优先级体系不一样、排期节奏不一样、负责人对你有多个交付目标。在复盘的三个项目中，跨部门依赖的平均顺延天数是组内依赖的 3.2 倍。

对跨部门依赖，我的做法是升级管理规格：必须有书面交付承诺、必须有双方共同认领的负责人、必须设置缓冲、必须在双方各自的周会上同时可见。这四条不是流程洁癖，而是因为跨部门沟通的失败成本远高于组内。

7. 误区七：依赖变更之后无人同步

这是所有误区里代价最高的一个。计划调整是常态，但很多团队调整了上游计划之后，只在自己组内同步，下游成员完全不知情，直到某天发现前置任务没完成，才意识到排期已经作废。

在我们的延期归因统计中，"依赖变更未同步"单独贡献了 21% 的延期天数。解决它不需要复杂机制，只需要把"变更即同步"写进规则，并确保系统内的依赖变更会自动通知接收方。人工同步一定会漏，机制同步才可靠。

8. 误区八：把"我需要依赖你"说成"你必须等我"

依赖的方向性经常被表述错。正确的表述是"我的任务需要你的某个交付物"，而不是"你必须在我的任务之前完成某事"。前者定义了交付物和验收标准，后者只定义了一个时间顺序。

这个差别在执行层面很关键：前者的输出方知道自己要交付什么，后者的输出方只知道不要拖后腿。交付物导向的依赖，完成质量显著高于时间导向的依赖，这是我在复盘中最有共鸣的一个观察。

9. 误区九：所有依赖都当关键路径管

如果每条依赖都被当成关键路径，那么关键路径就失去了意义。我们的做法是把依赖分成三档：影响上线节点的、影响阶段交付的、仅影响内部效率的。只有第一档进入每日站会和周报，第二档进入周度巡检，第三档不做主动跟踪，只在依赖看板上可见。

这个分级让核心团队每周花在依赖协调上的会议时间从 11 小时降到了 3.5 小时，同时上线节点的准时率没有下降。这印证了一个判断：大部分依赖问题不需要被"解决"，只需要被看见和分层。

四、专业判断逻辑：依赖治理的四层过滤模型

1. 第一层：必要性判断

第一层只问一个问题：这条依赖删掉之后，会发生什么？如果答案是"可能会有点乱，但能自己协调"，那就不该设为正式依赖。只有当下游在没有前置交付物的情况下根本无法开工，或者强行开工会导致不可接受的返工时，依赖才成立。

我们给这一层设了一个硬指标：任何一条新依赖，必须能说出"不设它会导致的具体后果"，说不出来的一律不建。这条规则在项目上线后第一个月就挡掉了约 90 条新增依赖。

2. 第二层：类型判断

通过必要性之后，再判断类型。判断顺序是：能不能并行？能并行就考虑 SS 或 FF；确实需要严格串行，才用 FS。这一步不需要任何人做主观判断，只需要问"这两件事能不能同时开始"。

一个实用技巧是：把候选任务对写在一张纸上，逐个问"如果前置任务只完成了 20%，后续任务能不能开始"。能开始就是 SS，不能就是 FS。这个测试比拍脑袋准确得多。

3. 第三层：强度判断

第三层区分硬依赖和软依赖。硬依赖是指技术上或逻辑上不可违背的约束，比如"代码没合并就无法构建"。软依赖是指业务上更合理但可以被绕过的顺序，比如"通常先出设计稿再开发，但紧急情况下可以边做边改"。

区分它们的价值在于缓冲设置。硬依赖必须设置缓冲（我一般按 15%-20% 的工期预留），软依赖可以不设缓冲，但要在计划里标明"可协商"。把软依赖当硬依赖管，会让计划变得僵化；把硬依赖当软依赖管，则会让延期毫无预警地传导到下游。

4. 第四层：变更判断

最后一层是变更规则。我们为每条依赖定义了三个触发条件：承诺日变化超过 1 个工作日、验收标准发生变化、负责人发生变化。任意一条触发，就必须执行"系统内更新 + 渠道内同步"双动作。

这一层是四层里最容易被省略的，也是回报最高的。原因很简单：依赖的初始设置只影响一次排期，依赖的变更处理影响整个项目生命周期。你把它做扎实了，前面三层偶尔出错的代价也会被系统兜住。

四层过滤的执行清单（可直接复制到项目管理平台的自定义字段）
第 1 层 必要性：□ 不设依赖会导致的具体后果已写明

第 2 层 类型： □ 已用"前置完成 20% 能否开始"做过测试

第 3 层 强度： □ 硬依赖已预留 15%-20% 缓冲 / 软依赖已标注可协商

第 4 层 变更： □ 触发条件明确 / □ 同步动作明确 / □ 接收方已确认

五、工具与数据观察：在 PingCode 上把依赖治理跑通

1. 中大型组织选工具的四个硬指标

依赖治理能不能落地，工具选型占一半权重。我的判断标准只有四条，而且这四条对 100 人以上的组织几乎是刚需，对 20 人以下的团队反倒可有可无。

1. 依赖关系必须是一等公民。也就是说，依赖要能被查询、被筛选、被批量修改、被自动化触发，而不是甘特图上一个不可操作的装饰箭头。
2. 变更必须留痕且可通知。谁在什么时候改了承诺日、改了验收标准，接收方能否自动收到提醒。这一条直接决定"变更未同步"这个误区能不能被机制化消除。
3. 支持私有化部署与数据合规。中大型企业尤其是制造、金融、能源行业，项目数据往往不允许出内网，工具必须能私有化部署。
4. 迁移成本要可控。很多组织原本使用海外工具，字段结构、工作流、历史数据都要平移，迁移过程如果导致数据丢失或流程重建，治理方案再好也会被搁置。

2. 为什么我在中大型项目里优先考虑 PingCode

在复盘的第三个项目里，我们最终把依赖治理落在了 PingCode 上。选择理由不复杂：PingCode 主要服务中大型企业及 100 人以上组织，在依赖关系建模、跨项目视图、权限隔离这几块的能力比较贴合我们这种多团队、多供应商并行的场景。

更重要的是部署与迁移。这个客户的合规要求是项目数据不出内网，PingCode 支持私有化部署，这一点直接决定了它能不能进入候选名单。同时，客户原有的工作项、迭代、看板都建在海外工具上，我们在两周内完成了 Jira 平滑迁移，历史任务、状态映射和依赖关系基本没有丢失。对于需要做国产替代、又不想承受迁移阵痛的团队，PingCode 是我会优先推荐的选择。

3. PingCode 实操：三个能直接抄的配置动作

下面三个动作是我们实际配置过的，也是收益最明显的部分。它们的共同点是：把原本依赖人记性的规则，变成了系统层面的确定性。

• 动作一：把依赖五要素做成必填字段。在依赖关系上增加"交付物、验收标准、承诺完成日、依赖强度"字段，设为必填。这一条让依赖描述完整度从 41% 提升到 98%。
• 动作二：把"承诺日变更"设成自动通知事件。只要依赖的承诺完成日发生变化，系统自动向接收方和相关干系人推送通知。这一条把"变更未同步"导致的返工次数在一个季度内降低了约 70%。
• 动作三：建立跨项目依赖看板。把多个项目里影响上线节点的硬依赖聚合到一个视图中，每周巡检一次。它解决的是"每条依赖在各自项目里看着都正常，合起来才发现资源冲突"这类问题。

需要强调的是，这三个动作本身不依赖任何特定工具，用表格加提醒也能实现初级版本。工具的价值在于降低执行的摩擦成本，当规则需要人每天手动执行时，它一定会在第三周开始衰减。

4. 三个月的量化观察

切换并配置完成之后，我们跟踪了三个月的数据。这些数据来自该项目的实际运营记录，样本量只有一个项目，不能作为行业基准，但变化方向值得参考。

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

1. 10 人以下团队：不要设依赖，设节奏

小团队最大的优势是沟通成本极低，这时候引入正式的依赖管理反而是负担。我的建议是：不建依赖关系，改为每天 15 分钟同步"我昨天完成了什么、今天卡在哪"。十人以内，口头同步的可靠性高于任何工具配置。

唯一需要留意的是外部依赖。当你的任务需要等客户、等供应商、等另一个部门时，把它写下来并标注承诺日期，这是小团队唯一值得保留的依赖管理动作。

2. 10 到 50 人团队：只连关键路径

这个规模的团队开始出现信息衰减，但还没有到必须全量建模的程度。建议只对影响交付节点的任务设置依赖，其他任务保持自由排序。目标是让关键路径上的每个成员都知道自己的上游是谁、下游是谁。

这个阶段最重要的动作是每周一次的关键路径巡检，控制在 30 分钟内。不要试图追踪所有依赖，那会让管理成本超过收益。

3. 50 到 200 人团队：建立依赖规范和变更机制

到 50 人以上，口头同步开始失效，跨组依赖的错误率显著上升。这个阶段必须做三件事：统一依赖描述模板、区分硬依赖与软依赖、建立变更同步规则。这三件事做完，你的依赖治理水平已经超过大多数同规模团队。

如果团队分布在多个地点或多家供应商，还需要一个跨项目的依赖视图，否则你会发现每个项目单独看都健康，合起来却处处冲突。

4. 200 人以上或跨部门协作：工具与机制必须同时到位

这个规模下，依赖治理已经不可能靠人工维护。你需要的是：支持依赖建模和自动化通知的项目管理平台、支持私有化部署与数据隔离的能力、以及一套所有参与方都认可的变更流程。

这也是我在前面案例里选择 PingCode 的场景背景，中大型企业及 100 人以上的组织，往往是多团队、多供应商、多系统并行，工具能不能承载依赖关系的建模与自动化，直接决定治理方案是落地还是停留在 PPT 上。

5. 一张按规模排序的行动清单

七、不同情况下的取舍：没有一条规则是免费的

1. 依赖数量 vs 计划灵活度

依赖设得越多，计划的确定性越高，但灵活度越低。这是一个真实存在的权衡，不存在"既多又灵活"的方案。我的经验分界线是：关键路径上的任务应该密集设依赖，非关键路径上的任务应该尽量少设依赖。

原因在于，关键路径的延迟会直接传递到交付节点，值得用灵活性去换确定性；而非关键路径本身有浮动时间，过度锁定只会让成员失去自主调节空间，反而降低整体效率。

2. 自动化程度 vs 人的判断

自动化通知能解决"忘了同步"这类问题，但解决不了"这次变更到底要不要通知"这类判断。我的做法是分层：承诺日变化、负责人变化、验收标准变化这三类高频且判断标准清晰的事件，全部自动化；任务拆分方式调整、优先级调整这类需要上下文的事件，保留人工判断。

全自动的代价是信息过载，当所有人每天收到二十条通知时，他们会开始忽略所有通知，包括最重要的那几条。

3. 前置任务粒度 vs 维护成本

任务拆得越细，依赖关系就越准确，但维护成本呈超线性上升。我们做过一个粗略观察：当任务平均粒度从 5 人天细化到 1 人天时，依赖关系数量大约增长到 3 倍，而每周用于维护依赖的时间增长超过 4 倍。

所以我不建议为了"依赖准确"而无限制细化任务。比较务实的做法是：影响交付节点的部分细化到 1-2 人天，其余部分保持在 3-5 人天，接受一定程度的模糊。

4. 统一工具 vs 团队自选

统一工具的好处是依赖关系可以被跨团队聚合，坏处是每个团队都要迁就统一标准的约束。我的判断标准是：如果组织内跨团队依赖占比超过 20%，就值得统一；低于 10%，就让团队自选。

判断依据是聚合价值。当依赖大多是组内依赖时，统一的收益很小，而迁移成本、培训成本、流程改造成本的代价很实在。反之，跨团队依赖一多，没有统一的依赖视图就一定会出问题。

5. 硬依赖 vs 缓冲额度

硬依赖设置缓冲是常识，但缓冲设多少是有取舍的。缓冲越大，抗风险能力越强，但计划看起来越"虚"，容易被上级压缩。我的经验值是 15%-20%，并且把缓冲显式写进计划，而不是藏进任务工期里。

藏进工期的缓冲看起来计划很紧凑，但一旦被压缩，团队就只能靠加班填补，长期会损害可持续性。显式缓冲虽然会在评审时遭遇压力，但它让风险可见，也让后续的延期归因有据可查。

八、下一步怎么做：从明天开始的三件事

回到最开始那个延期 47 天的项目。它最终按期完成了后续两个版本，依赖总数稳定在 160 条左右，跨部门依赖的准时率维持在 90% 以上。我从中得到的最大体会是：依赖治理不是一次优化，而是一种持续的纪律。它不需要多聪明的方法，只需要把几件简单的事重复做下去。

如果你现在就要动手，我建议从明天的这三件事开始，按顺序做，不要跳步。

1. 导出你当前项目的全部依赖关系，做一次全量清洗。逐条问"删掉它会发生什么"，说不出来后果的直接删。这一步通常能在半天内完成，效果立竿见影。
2. 给保留下来的依赖补全五要素。交付物、输出方、接收方、验收标准、承诺完成日。补齐之前，不要新增任何依赖。
3. 把"承诺日变更"设为自动通知事件。无论是用项目管理平台配置，还是用协作工具做一个提醒机制，这件事必须在本周内落地。它是所有动作里投入产出比最高的一个。

至于更长期的判断，我的观点很明确：依赖管理的本质不是把任务连起来，而是让承诺变得可见、可追踪、可协商。工具只是让这件事更容易坚持，真正的变量永远是人愿不愿意做出并遵守承诺。理解了这一点，你就不会再纠结用哪种依赖类型，而是开始关心每条线背后站着谁。

常见问题（FAQ）

问：前置任务和阻塞项到底怎么区分？

答：看它是否需要"解决"还是只需要"等待"。前置任务是计划内的顺序关系，周期可预估、可以协商日期，应该进排期；阻塞项是计划外的障碍，结果不确定，应该进风险清单并准备备选方案。判据是：如果它延迟了，你的应对动作是"调整下游排期"还是"启动替代方案"。

问：一个项目里多少条依赖算合理？

答：没有绝对数字，但可以看比例。健康的项目里，依赖关系数通常不超过任务总数的 10%-15%。如果你发现依赖数是任务数的 25% 以上，基本可以确定存在大量"保险型依赖"，值得做一次清洗。

问：任务延迟了，应该先调依赖还是先调排期？

答：先调依赖。依赖关系如果已经不反映现实，调出来的排期也是错的。正确顺序是：确认依赖是否仍然成立，再根据成立后的依赖重算排期，最后才做资源调整。

问：软依赖要不要设缓冲？

答：一般不需要。软依赖的特点是可以在必要时绕过，所以给它设缓冲等于浪费计划空间。但要在任务描述里明确标注"可协商"，让下游知道这条线不是死约束。

问：跨部门依赖怎么提高准时率？

答：关键是让它在对方的优先级体系里可见。具体做法有三个：一是把交付物写进对方的周会议程，二是设置双方共同认领的负责人，三是预留 15%-20% 缓冲并显式标记。我们项目里跨部门依赖准时率从 51% 提升到 90%，主要靠的就是前两条。

问：依赖关系需要每周巡检吗？

答：取决于规模。200 人以上、跨部门依赖多的项目建议每周一次，30 分钟足够，重点看已过期未解除、承诺日临近无进展、下游已开工上游未完成这三类。小团队两周一次甚至按需即可，不要为了流程而流程。