任务依赖后置任务全流程：PMO协同管理与一文讲清

一个后置任务延期 11 天，追责追到最后发现执行人只用了 2 天，剩下 9 天全耗在等前置确认、等跨部门回话、等一个没人定义清楚的“完成”上。这种情况我在过去五年的项目复盘里见过太多次。任务依赖和后置任务管理，绝大多数团队的问题不在甘特图画得对不对，而在于：没有人把“前置任务何时算完成、由谁确认、后置任务何时解锁”写成一条可执行的规则。这篇文章把这件事从头到尾拆开讲清楚：依赖怎么识别、怎么登记、怎么触发后置任务、PMO 在中间承担什么角色、用什么指标证明协同有效，以及不同规模的组织该怎么取舍。

一、先讲核心结论：依赖不是属性，是契约

我把话放在前面。任务依赖管理失败的组织，通常不是缺工具，而是缺三样东西：可验证的完成条件、明确的责任人、被授权的仲裁机制。工具只是把这三样东西承载下来，它无法凭空创造。

1. 后置任务延期中，真正的执行拖延占比很低

我做过一次不完全统计。把过去三年经手的 7 个中大型项目里的延期后置任务拉出来，逐个归因，样本大约 180 条。结论很不客气：被明确判定为“执行人主观拖延”的占比只有 11% 左右，剩下的接近九成，问题都出在依赖链的上下游，完成标准模糊、隐性依赖没登记、跨部门排队、变更没同步、系统状态和业务实际不一致。

这意味着什么？意味着你开十次“加快执行”的会，可能只解决了一成的问题。

2. PMO 的角色是规则制定者、仲裁者和度量者

很多 PMO 干着干着就变成了“高级催办员”。每天在群里问“这个好了吗”“那个什么时候给”，看起来很忙，但依赖问题每个月都在同一个地方复发。

我的判断是：PMO 在依赖协同中最不该做的是催办，最该做的是三件事，制定依赖登记和触发规则、在跨部门冲突时做仲裁并推动升级、用指标度量协同效果并驱动机制迭代。催办是结果，不是职责；一旦 PMO 把催办当主业，项目组就会把依赖管理的责任外包出去。

3. 自动化只能解决状态流转，解决不了“真的完成了吗”

系统可以根据“前置任务状态=已完成”自动解锁后置任务，这在工程上很容易。但“状态被点成已完成”和“交付物真的可用了”之间，往往隔着一整个验收流程。

所以我在设计触发规则时始终坚持一条底线：状态类触发可以自动，交付类和质量类触发必须有人确认。否则你会收获一个漂亮的项目看板，和一个业务上根本跑不通的项目。

二、真实场景：一个后置任务为什么卡了 11 天

讲个具体案例。我参与复盘过一个制造企业的 MES 系统上线项目，涉及 IT、生产、质量、供应链四个部门，团队规模 140 人左右，属于典型的中大型项目。其中有一个后置任务叫“产线端数据回传联调”，计划工期 5 人天，实际用了 16 人天，延期 11 天。

表面看是执行太慢。把时间轴摊开，完全不是这么回事。

1. 依赖失灵的四种典型表现

这个案例不是孤例，它几乎完整包含了依赖管理的四类典型失败。

第一种是完成标准模糊。IT 部门的“接口已交付”指代码提交并部署到测试环境，生产部门的“接口已交付”指数据能正确回传并在业务侧可读。两个部门都没错，但定义不在一张纸上，就等于没有定义。

第二种是隐性依赖未登记。质量部门的验证人员是一个隐性资源依赖，项目计划里从来没出现这条依赖，直到需要验证时才发现人被别的项目占走了。

第三种是升级路径缺失。问题在项目组内部循环了三天，没有人知道该往哪升、升上去之后多久必须响应。

第四种是变更未同步。数据字段在项目中期调整过一次，变更记录在 IT 侧的文档里，但没有同步到依赖清单，后置任务的负责人并不知情。

2. 为什么“前置任务已完成”经常是假的

这是我最想强调的一点。在依赖链上，前置任务的“完成”有三种状态，很多团队只认第一种：

• 状态完成：任务负责人在系统里点了“已完成”。这是最弱的一种。
• 交付完成：交付物已经产出并放置到约定位置，但还没被下游验证。
• 验收完成：下游确认交付物可用，并给出明确的接收结论。这才应该触发后置任务。

把“状态完成”直接等同于“验收完成”，是自动化依赖触发中最常见的隐患。系统跑得很顺，业务上却处处返工。

三、拆解四个常见误区

1. 误区一：甘特图上画了箭头，就等于管住了依赖

甘特图上的连线只表达时间先后关系，不表达任何管理承诺。一条箭头能告诉你 B 在 A 之后，但它不会告诉你 B 在等什么、等到什么程度算等到、谁来确认 A 真的完成了。

我在复盘时经常做一个测试：把甘特图上所有依赖连线遮住，只留任务名称和时间，让项目组成员说出每个后置任务的具体解锁条件。能说清楚的一般不到三分之一。这说明箭头只存在于项目经理的文件里，没有进入执行人的认知。

2. 误区二：完成标准交给执行人自己定义

让前置任务的负责人自己写完成标准，听起来很民主，实际上很危险。因为人天然倾向于把标准写得对自己有利、可轻松达成。

正确的做法是：完成标准由前置任务负责人起草、后置任务负责人确认、PMO 备案。三方签字的意义在于，验收争议在任务开始前就解决了，而不是在任务结束后扯皮。

3. 误区三：PMO 越勤快，依赖闭环越快

恰恰相反。PMO 催得越勤，项目组越倾向于把依赖状态维护的责任推给 PMO，反正有人盯着。“等 PMO 来问”会逐渐成为一种默认行为模式。

更健康的状态是：依赖状态由责任人主动维护，PMO 只在异常和升级节点介入。PMO 的存在感应该体现在规则和仲裁上，而不是消息数量上。

4. 误区四：上了协同工具，依赖问题就自动消失

工具解决的是可见性和流转效率，解决不了语义分歧和责任真空。我见过用着很先进的协同平台、依赖登记表却空空如也的团队，也见过用一张共享表格就跑通依赖闭环的团队。

差距不在工具，在于有没有人认真定义过“这条依赖什么时候算闭环”。

四、专业判断逻辑：依赖的三个属性和四种类型

1. 依赖必须具备三个属性，缺一不可

我判断一条依赖是否“可管理”，只看三个属性是否齐全：

这三条里，“条件”是最容易被省略、也最致命的一条。方向靠沟通能补，承诺靠催办能推，唯独条件不写清楚，后面所有的自动化和度量都是建在沙子上。

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

标准的依赖类型分四种，但很多团队把它们当成术语背下来，从来没在真实项目里做过选择。

我的经验是：一个项目里 FS 占比超过 80% 就要警惕，说明团队没有认真寻找并行空间；而 SS 和 FF 加起来超过 40%，往往说明依赖没有收敛点，后置任务的“完成”变得很难判定。

3. 判断一条依赖该不该登记的标准

不是所有先后关系都值得登记成正式依赖。登记太多，清单会变成噪音；登记太少，隐性依赖会在后期集中爆发。

我用的判断标准是三条任一满足即登记：

1. 跨部门或跨团队的交付关系，涉及两个以上责任人；
2. 后置任务处于关键路径，或延期会直接影响里程碑；
3. 前置任务的完成标准存在解释空间，需要提前对齐。

反过来，同一个人、同一个团队内部、标准毫无歧义的先后关系，可以不登记，避免清单膨胀。

五、全流程地图：六大环节与角色分工

1. 六个环节的输入与输出

把依赖管理从概念落到流程，我建议按六个环节走。每个环节都要有明确的输入和输出物，否则流程就只是口号。

2. 四个角色各管什么

用 RACI 的方式把角色说清楚，能避免大量“这不该我管”的争论。

这张表里最关键的是 PMO 的两处 A：登记的最终确认权和升级的最终推动权。这两项权力如果不给 PMO，PMO 就只能靠人情去协调，依赖管理必然退化成催办。

3. 每个环节的失败模式

我按环节列一下最常见的失败方式，这些几乎构成了依赖管理问题的全集：

• 识别环节：只看了任务清单，没看接口清单和资源计划，隐性依赖全部漏掉。
• 登记环节：登记了依赖名称，但没写完成标准和承诺时间，等于没登记。
• 触发环节：前置任务一被点完成就自动解锁，没有验收环节，假完成流入下游。
• 执行环节：后置任务负责人不知道自己在等什么，也不主动上报异常。
• 升级环节：问题在项目组内部循环，缺乏升级触发条件和响应时限。
• 复盘环节：只追责到人，不追责到机制，下个项目原样重演。

六、阶段一：依赖识别与登记，把隐性依赖显性化

1. 六个必须扫一遍的依赖来源

识别依赖靠灵感是不行的，必须有清单式的扫描路径。我通常按六个来源逐一过一遍：

1. WBS 拆解：工作包之间的先后关系，这是最基础的一层。
2. 里程碑节点：每个里程碑前必须完成的前置动作。
3. 交付物清单：每个交付物由谁产出、交给谁、谁验收。
4. 系统接口清单：跨系统联调类依赖，这类依赖的完成标准最容易模糊。
5. 资源计划：共享人员、共享设备、共享测试环境的占用排期。
6. 合规与审批：外部窗口期、审批周期，这类依赖不可压缩，必须前置锁定。

其中第 4、5、6 类是隐性依赖的高发区。我做过统计，一个中型项目里，最终暴露出来的隐性依赖有七成来自这三类，而它们恰恰不在任务清单里。

2. 依赖登记表的字段设计

登记表不需要花哨，但字段必须完整。下面是我一直在用的一套字段结构，可以直接照搬到协同平台的自定义表单里。

依赖登记表字段结构
{

"依赖ID": "DEP-2024-0137",

"前置任务": "数据中台接口开发",

"前置责任人": "张工（数据平台组）",

"后置任务": "产线端数据回传联调",

"后置责任人": "李工（生产IT组）",

"依赖类型": "FS（完成，开始）",

"完成标准": "接口在测试环境可用，返回字段与《数据字典V2.3》一致，抽样100条无异常",

"验收方式": "后置方抽样验证 + 书面确认",

"承诺完成时间": "2024-06-18",

"实际完成时间": "",

"当前状态": "进行中",

"影响评估": "延期1天导致里程碑M3顺延1天，影响上线窗口",

"降级方案": "先提供CSV离线导入通道，保障联调不中断",

"升级阈值": "超期2个工作日自动升级至PMO",

"上次更新": "2024-06-11 17:20"

}

这里面有三个字段是大部分团队会漏掉但极其关键的：

验收方式，它回答了“谁来确认完成”这个责任问题。降级方案，它让依赖在超期时不至于完全阻断后置任务，是保障项目节奏的缓冲阀。升级阈值，它把升级从“凭感觉”变成“按规则自动触发”。

3. 依赖粒度控制在什么程度

粒度太粗，问题看不清；粒度太细，清单变成负担。我观察过不同粒度下的问题提前发现率，结论是存在一个明显的甜点区间。

七、阶段二：触发规则设计，什么可以自动，什么必须人工

1. 四类触发条件及其可靠性

后置任务被解锁，本质上需要一个触发信号。我把常见的触发信号分成四类，可靠性差异很大。

我的实践建议是：把自动解锁的触发条件限定在“验收通过”“交付物签收”“审批通过”三类，且必须要求凭据存在。状态完成可以作为提示信号，但不能作为唯一解锁依据。

2. 自动化与人工确认的分工

哪些环节可以放心交给系统，哪些必须留人，我按经验总结成下面这张对照：

• 可以自动：状态流转通知、依赖超期提醒、超期自动升级、看板刷新、凭据完整性校验、升级 SLA 计时。
• 必须人工：完成标准是否达成、交付物质量是否合格、范围变更是否影响后置任务、降级方案是否启用、依赖是否可以关闭。

这条界线的判断标准很清晰：凡是需要业务判断的，都不自动；凡是纯粹的流程和计时，都可以自动。越过这条线，你得到的是效率，丢掉的是准确性。

3. 三类风险的控制手段

（1）假完成

前置任务被点了完成，但交付物实际不可用。控制手段是强制附凭证：验收记录、测试报告、签收单三者至少具备其一，否则后置任务不解锁。系统只做校验，判断权仍然给人。

（2）提前开始

后置任务负责人为了赶工，在前置条件未满足时就开始动工，结果做了一半发现输入变了。控制手段是把后置任务拆成“可提前准备部分”和“必须等待部分”，前者允许提前启动，后者严格锁定。

（3）范围蔓延

前置任务在执行过程中被追加需求，交付内容变了但依赖登记表没更新。控制手段是把依赖登记表与变更流程绑定：任何影响交付内容的变更，必须同步触发依赖表的复审。

八、阶段三：PMO 协同机制，跨部门依赖如何不靠催办

1. 例会与看板：把风险前置暴露

依赖问题最怕的不是解决不了，而是发现得太晚。我设计的例会议程里，依赖永远是第一个议题，而不是最后一个。

具体的做法是：会前由系统自动生成三张清单，本周新增依赖、本周超期依赖、未来两周即将到期的依赖。会议只讨论第二张和第三张，第一张走异步确认。这样一场 30 分钟的会能处理的事情，比原来 90 分钟的进展汇报还多。

看板上我建议分三层：项目层看关键路径依赖，部门层看本部门的对外承诺，组织层看跨项目集的资源冲突。三层看的是同一批数据，视角不同。

2. 升级机制：黄灯、红灯与响应 SLA

升级机制必须事先定义，事后临时商量就等于没有机制。我通常设三级：

这里最容易被忽视的是响应时限。没有时限的升级只是通知，不是升级。我在项目里会用一条硬规则：橙灯以上升级如果超时未响应，自动进入更高一级，不等人。

3. 变更管理：依赖变更后的影响评估

依赖是动态的。前置任务的范围、时间、交付标准都可能变，一变就要评估对后置任务的连带影响。

我的做法是给每条依赖设两个字段：“下游影响数”和“变更敏感度”。前者指这条依赖如果失效，会影响几个后置任务；后者指它在本项目中的稳定性。两者相乘高的依赖，纳入每周重点盯防清单。

变更发生时的处理顺序是：先评估影响范围，再判断是否需要启用降级方案，最后决定是否调整后置任务的时间或范围。顺序不能反，先调时间再评估影响，等于把风险往后推。

九、阶段四：执行监控与度量，用指标证明协同有效

1. 过程指标：看协同机制有没有真的转起来

过程指标的作用是早期预警，它不直接反映结果，但能提前告诉你哪里要出问题。我常用的有六个：

• 依赖登记率：已登记依赖条数 ÷ 实际存在的依赖条数。低于 70% 说明隐性依赖严重。
• 完成标准完备率：写清可验证完成标准的依赖 ÷ 全部依赖。这个指标低于 85% 的项目，后期返工率明显偏高。
• 验收凭据覆盖率：附有验收凭据的依赖 ÷ 全部依赖。
• 按时闭环率：在承诺时间内闭环的依赖 ÷ 全部依赖。
• 后置任务平均等待时长：从依赖到期到后置任务实际解锁的平均时长，单位人天。
• 升级及时率：在 SLA 时限内完成升级的依赖 ÷ 应升级的依赖。

2. 结果指标：看项目最终有没有受益

结果指标数量要少，多了会分散注意力。我一般只看三个：里程碑达成率、交付周期、返工率。这三个指标能回答一个核心问题：依赖协同投入了这么多管理成本，项目到底有没有更快更稳。

3. 看板设计：按项目、部门、依赖方分层

同一份数据，不同角色要看不同切片。项目经理看关键路径上的依赖健康度，部门负责人看本部门对外的承诺兑现情况，PMO 看跨部门的资源冲突和升级分布。用一张大一统的看板给所有人看，等于给所有人都不看。

4. 工具落地：以 PingCode 为例的依赖与后置任务配置

讲完机制，必须落到工具上，否则一切都是纸面方案。前面提到的那些字段、触发规则、升级 SLA，如果没有工具承载，靠人工维护很快就会崩掉。

我在服务 100 人以上组织时，比较常用的是 PingCode 这类面向中大型企业的研发项目管理平台。它让我认可的地方不在功能多，而在于几件和中大型组织真实痛点直接相关的事。

一是支持私有化部署。中大型企业尤其是制造、金融、能源行业，项目数据往往不允许放在公有云上，跨部门依赖信息又涉及大量内部排期和资源分配，私有化部署几乎是硬性前提。

二是支持 Jira 平滑迁移。很多组织原有的依赖关系和任务层级都在 Jira 上，迁移最怕的就是结构丢失，如果依赖关系在迁移中被打散，历史数据对依赖链管理就没有价值了。PingCode 在保留工作项层级和关联关系上做得比较完整，这让依赖登记表可以在迁移后继续沿用。

三是作为国产替代方案，在协同配置上更贴合国内组织的管理习惯。比如多级审批、按部门分层的看板、自定义字段的开放性，这些在落地阶段比功能清单更重要。

具体到依赖与后置任务的配置，我的落地路径是这样的：

1. 建立独立的「依赖」工作项类型，把前面那张登记表的字段全部自定义进去。
2. 用关联关系把「依赖」工作项与前置任务、后置任务双向绑定，保证任一方向都能查到。
3. 设置自动化规则：依赖状态变为「已验收」且「验收凭据」字段非空时，自动将后置任务从「未开始」置为「待启动」。
4. 设置超期规则：依赖超过承诺时间 2 个工作日，自动变更状态为「黄灯」并通知项目经理与 PMO。
5. 配置三层看板：项目关键路径依赖视图、部门对外承诺视图、PMO 升级视图。

整个过程我不建议一次性全上。先跑依赖登记和自动提醒这两条最基础的规则，稳定两周后再加自动触发和升级 SLA。一次性上全套规则，团队会因为不理解规则逻辑而绕过系统，最后工具变成摆设。

十、阶段五：复盘与机制固化，从单项目到组织级能力

1. 复盘只问四个问题

依赖复盘最忌讳开成追责会。我通常只问四个问题，每个问题都必须有事实支撑：

1. 这条依赖为什么会失效？是识别漏了、标准模糊、资源冲突，还是变更没同步？
2. 升级是否及时？如果及时，问题会不会更早解决；如果不及时，卡在哪一级？
3. 现有规则是否能覆盖这类问题？如果不能，缺哪一条？
4. 下个项目的依赖模板需要改哪个字段或哪条规则？

第四个问题是关键。前三个问题回答完，经验还是留在个人脑子里；只有第四个问题有明确产出，经验才变成组织资产。

2. 知识库沉淀什么

我建议沉淀三类内容：依赖模式（常见依赖的标准写法和完成标准模板）、风险清单（本行业本组织高发的依赖失效类型）、升级案例（典型升级过程和处理结论）。这三类内容能让新项目的依赖登记从零开始变成从模板开始。

3. 工具化的边界

最后再强调一次工具边界。可以自动化的：状态流转、超期提醒、SLA 计时、看板刷新、凭据校验。不能自动化的：完成标准是否达成、质量是否合格、范围变更是否影响后置任务、依赖是否可以关闭。

把不能自动化的部分强行自动化，是依赖管理中最贵的错误之一。它省下的是操作时间，付出的是返工成本和信任成本。

十一、不同情况下的行动建议

1. 100 人以下的组织：先解决登记，不要碰自动化

这个规模的项目，依赖关系通常不超过 20 条，靠一张结构化的表加每周一次的对齐会就能跑通。我的建议是先建登记表，把完成标准和责任人写清楚，暂不引入复杂的自动触发规则。这个阶段最大的收益来自“把隐性依赖写下来”，而不是“让系统自动流转”。

2. 100 至 500 人的组织：登记 + 触发规则 + 单层看板

这个规模开始出现跨部门资源竞争，PMO 的仲裁角色必须建立起来。建议配置依赖登记表、触发规则和一张项目层看板，先把关键路径上的依赖管住。升级机制从二级开始（黄灯、橙灯），不必一上来就设三级。

3. 500 人以上的组织：机制 + 度量 + 分层看板 + 平台承载

到这个规模，靠人工维护依赖已经不可能。必须上平台，必须做分层看板，必须有完整的度量指标体系。这个阶段我通常建议同步推进两件事：一是把依赖管理写入项目管理制度，二是把依赖健康度纳入 PMO 的考核范围。没有制度背书，跨部门仲裁很难真正落地。

4. 多项目并行的项目集：优先解决资源依赖

项目集层面的依赖，主要矛盾往往不是交付物依赖，而是共享资源依赖，同一个测试环境、同一批专家、同一条产线。这时候要做的不是任务级依赖登记，而是资源排期表与依赖表的联动，任何资源占用变化都要触发依赖复审。

十二、不同情况下的取舍

1. 自动化程度与准确性的取舍

自动化程度越高，流转越快，但假完成流入下游的概率也越高。我的取舍原则是：在关键路径依赖上，宁可慢一天，也要保住准确性；在非关键路径依赖上，可以更多依赖自动化，用人工抽检兜底。

2. 依赖粒度与维护成本的取舍

粒度越细，问题越早暴露，但登记和维护成本呈非线性上升。前面那张折线图已经说明，超过 50 条之后收益反而下降。所以取舍点是：只登记跨责任人、影响关键路径、或标准有歧义的依赖，放弃对同团队内部先后关系的登记。

3. PMO 干预强度与项目自主性的取舍

PMO 介入越多，跨部门问题解决越快，但项目组的依赖管理能力越难成长。我的建议是分层：黄灯级问题由项目组自行解决，PMO 只做记录；橙灯级 PMO 介入协调；红灯级 PMO 主导决策。让项目组在低级别问题上练手，才能在高级别问题上配合得更顺。

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

这是个老问题。我的判断很明确：先有规则，再上工具。在没有定义完成标准、没有升级机制的情况下引入平台，只会把混乱数字化，看板会变得很整齐，问题一个都不会少。

十三、避坑清单与常见问题

1. 十条避坑清单

1. 不要把甘特图连线当成依赖管理，它只是时间关系。
2. 不要用“任务已完成”作为自动解锁后置任务的唯一条件。
3. 不要让前置方单独定义完成标准，必须由后置方确认。
4. 不要让 PMO 承担催办职责，那会让依赖管理责任外包。
5. 不要把所有先后关系都登记成依赖，清单会变成噪音。
6. 不要设了升级机制却没有响应时限。
7. 不要把变更排除在依赖流程之外，变更不同步是隐形杀手。
8. 不要在依赖还没有降级方案时就让它成为唯一路径。
9. 不要只做复盘追责，不做模板更新。
10. 不要在没有规则的情况下先上工具。

2. 常见问题

（1）依赖条数多少算合理？

没有绝对数字，参照值是：中小型项目 6-15 条，中大型项目 16-30 条，复杂项目集 31-50 条。超过 50 条时要重新审视粒度，是否把可以合并的依赖拆得太细。

（2）后置任务负责人该不该参与依赖识别？

必须参与。后置任务负责人是最清楚“我需要什么才能开工”的人，把他排除在识别环节之外，遗漏率会明显升高。实践中的做法是：项目经理主导识别，后置方确认补充。

（3）依赖超期了但后置任务可以先做着，要不要解锁？

可以，但必须显性化。做法是把后置任务拆成两部分，允许提前启动的部分正常推进，依赖锁定的部分保持挂起，并在看板上标注“带风险执行”。不要因为“反正能做”就悄悄解锁，那会让风险失去可见性。

（4）PMO 人手不足怎么办？

优先级是：先保住依赖登记和超期提醒这两项最基础的功能，其余全部交给系统自动完成。人手不足时最不该做的是亲自催办，那是投入产出比最低的动作。

（5）跨部门依赖推不动，PMO 权限不够怎么办？

这是机制问题，不是能力问题。解法是把升级路径写进项目章程，并明确 PMO 在橙灯级别以上的协调权。如果连这个都争取不到，依赖管理会长期停留在靠人情推动的阶段。

结语：先定规则，再上工具

回到最开始那个卡了 11 天的任务。它真正缺的不是一个更厉害的工具，而是三样东西：一条写清了“接口可用、字段一致、抽样无异常”的完成标准，一个明确知道自己在等什么的负责人，以及一条“超期两天自动升级”的规则。

这三样东西加起来，成本不到半天。但它们能把 11 天的等待压缩到 2 天以内。

我见过太多团队把顺序做反了：先花三个月选型上平台，再花三个月发现没人认真登记依赖。正确的顺序是反过来的，先用一张表把规则跑通，再用工具把规则固化。工具的价值是让好规则跑得更省力，而不是替代规则本身。

如果你打算这周就动手，我建议按下面的清单走：

1. 第 1 天：把当前项目里所有跨责任人的交付关系列出来，形成候选依赖清单。
2. 第 2 天：给每条候选依赖补齐方向、完成标准、责任人、承诺时间四个字段，删掉不满足登记标准的条目。
3. 第 3 天：和每条依赖的后置方确认完成标准，双方对“什么算完成”达成一致。
4. 第 4 天：定义触发规则，明确哪些条件可以自动解锁、哪些必须人工验收。
5. 第 5 天：设定升级阈值和响应时限，把责任落到具体角色上。
6. 第 6-7 天：把规则配置到协同平台上，跑一遍历史依赖做验证，看看有多少会因为标准不完备而无法解锁。

这套动作做完，你会得到一个诚实但可能不好看的数字：真正写清了完成标准的依赖占比。这个数字通常比想象中低得多，但它是所有依赖管理的起点。看不见的问题无法被管理，先让它可见，再谈优化。