去年冬天，我帮一家做工业检测设备的公司做项目复盘。40人的团队，硬件、固件、算法三条线并行，计划表画得漂漂亮亮，真正的问题却藏在一次为期两周的静默里：固件冻结在等算法接口，算法接口在等硬件BOM定版，硬件在等采购回签。三个项目负责人谁都没做错，因为他们的任务定义就是"等上游完成"。两周内没有一个人触发升级，因为制度里压根没写"卡住多久必须上报"。这次复盘之后我得出一个结论：FS（Finish-to-Start，完成-开始）依赖管理做不好，九成不是排期工具的问题，而是责任交接点没有配上对应的决策权。
一、核心结论：FS依赖从来不是排期问题，而是责任交接问题
1. 先把结论摆出来
项目负责人制度设计，从0到1要解决的第一个问题不是"谁来管项目"，而是"每一个FS交接点上，谁有权拍板、谁承担延迟后果、卡住多久必须升级"。这三件事没定，负责人就只是一个挂着名头的进度汇报人。
我见过太多团队在制度设计上走反了顺序：先定架构图，再定汇报线，最后才想起来梳理依赖。结果就是依赖关系图永远画在项目启动会的PPT里，执行阶段全靠微信群口头同步。正确的顺序应该是反过来的：先定义依赖交接点，再给交接点配负责人，再给负责人配授权，最后才是看板和工具。
换句话说，FS不是甘特图上那根箭头，而是责任从一个角色转移到另一个角色的那一瞬间。所有管理动作都应该围绕这个瞬间展开。
2. 为什么"从0到1"阶段这个问题被放大
成熟业务有历史数据、有稳定的协作习惯、有默认的兜底人。从0到1的项目三样都没有。任务边界本身在变，今天定的接口明天可能推翻，负责人的权威还没建立起来，团队对"延迟"的容忍度又特别低。
我用过一个粗略的统计口径：把100条在项目里登记过的依赖拿出来，追踪它们从登记到关闭的全过程，看每一步流失了多少。这个漏斗在早期项目里通常长这样：
这个漏斗最有价值的地方在于：它告诉你问题出在哪一层。如果流失主要发生在"登记"到"DoD"之间，那是需求澄清能力的问题；如果发生在"承诺时间"到"按期交接"之间，那才是负责人制度和升级机制的问题。两者要用完全不同的药。
二、真实场景：三个把项目拖死的依赖现场
1. 场景A：40人硬件团队的两周静默
就是我开头提到的那次复盘。三条线各有负责人，每个人都对结果负责，但没人对"跨线的等待"负责。硬件负责人说"我BOM没定是因为采购没回签"，采购说"我在等研发确认替代料"，研发说"我在等固件告诉我电源余量"。
关键在于，这条链条上每一个环节都是FS依赖，但没有任何一个环节定义了"完成"的标准。采购的"回签"到底是收到报价单算完成，还是签完合同算完成？没人说得清。于是每个环节都可以合理地宣称"我在等"。
我们后来做的事很简单：把这条链上的7个FS交接点全部写进一张表，每个点补上DoD、责任人、承诺日期和升级条件。两周的静默变成了一天半。没有换人，没有加资源，只是把模糊的等待变成了明确的交接。
2. 场景B：80人创业公司的"人形进度条"
这家公司的项目负责人只有协调权。他能拉会、能催进度、能整理周报，但调不动任何一个研发资源，也改不了任何一个人的优先级。开会时所有人点头，散会后各自回到职能线的排期里。
我观察了三个月，这位负责人的日程里，超过60%的时间花在"追问状态"和"解释为什么延期"上。他不是在管理项目，他是在给项目当播音员。
这是典型的权责不对等：让他对整体交付负责，却不给他任何一项可以改变交付结果的权力。这类制度不叫项目负责人制，叫项目背锅制。
3. 场景C：120人集团项目的口头依赖
这是一个中台建设项目，涉及四个部门、六个子系统。依赖关系全部靠站会口头同步："你那边接口什么时候好？""下周三吧。""行。"下周三到了，没有。问起来，"我上次说的是大概下周三"。
我统计过这个项目一个月的站会记录，平均每天出现11次依赖相关对话，其中只有不到3次最终转化成了系统里的任务或日期变更。其余全部蒸发在会议纪要里。
这个项目最后拖了四个月。复盘时大家都同意"依赖管理有问题"，但没人说得清具体是哪条依赖出了问题，因为没有记录。
把三类项目的停滞原因做个粗略归因，大致分布如下：
三、常见误区：六个想当然
1. 误区一：把FS理解成"先后顺序"
FS的字面意思是前置任务完成后，后置任务才能开始。很多人因此把它当成纯粹的排期逻辑，画在甘特图上就完事了。
但排期只是它的表象。FS真正的含义是：后置任务的负责人，在前置任务完成之前，既不掌握进度也不掌握质量，处于完全的被动状态。正因为被动，才必须给这个交接点配一套主动的管理机制，否则后置方永远只能等。
想清楚这一点，你会发现FS依赖的本质是一种"权力真空"。真空不填，就会被抱怨和甩锅填满。
2. 误区二：负责人=协调员
很多团队在制度文件里写"项目负责人统筹协调项目整体推进"，然后就没了。协调是手段，不是职责。真正要写清楚的是三件事：对什么结果负责、能调动哪些资源、卡住时能做什么决定。
我通常用一个简单的判断标准：如果这位负责人不能在不开会的情况下改掉一个人的任务优先级，他就不算负责人。
3. 误区三：依赖只是计划阶段的产物
计划阶段梳理出的依赖是"预判依赖"，执行阶段会持续冒出"新发现依赖"。后者往往更致命，因为它没有缓冲时间。
我见过最极端的例子是一个数据迁移项目，计划阶段列了23条依赖，执行到第六周实际登记了71条。多出来的48条全是被"我以为你能提供"这种假设漏掉的。所以依赖管理必须是一个持续动作，而不是启动会的一个环节。
4. 误区四：依赖越少越好
这是被精益思想误导的一个常见判断。依赖当然越少越好，但前提是"真依赖"和"伪依赖"要先分开。
真依赖是客观存在的技术或业务约束，比如"接口不冻结就无法联调"。伪依赖往往是管理惰性造成的，比如"我要等他先做完我再开始"，实际上可以提前做接口桩、提前搭环境、提前写测试用例。
把伪依赖识别出来，比消除真依赖的收益更大，因为伪依赖通常占据了登记清单里一半以上的条目。我通常要求团队在每条依赖上标注一句"下游能否提前准备什么"，标不出来的，就该重新审视这条依赖的合理性。
5. 误区五：上个工具，依赖就自动清楚了
工具能让依赖可见、可追、可提醒，但它不会自动帮你定义DoD，也不会替你决定谁有权升级。我见过用着很贵的项目管理平台、依赖字段填得稀稀拉拉的团队，也见过用共享表格把依赖管得明明白白的十人小队。
工具的价值在于放大已经想清楚的制度。制度没想清楚，工具只会把混乱照得更清楚。
6. 误区六：升级机制等于打小报告
这是文化层面的误区，也是最难破的。很多团队里"升级"天然带有负面含义，意味着"我搞不定了""我要告状了"。
破解办法是把升级彻底制度化、条件化：不是靠感觉升级，而是触发条件就升级。逾期24小时未更新状态自动升级，连续两次承诺未兑现自动升级。当升级变成规则的一部分，它就不再是人际行为，而是流程动作。
顺带说一个容易被混淆的点：项目管理里的FS指Finish-to-Start依赖，但在别的语境里FS也可能指可行性研究（Feasibility Study）或功能规格（Functional Specification）。本文讨论的是依赖逻辑关系里的FS。如果你们团队内部的"FS"是另一个含义，先把术语对齐，再谈制度，否则整套设计会错位。
7. 四种依赖关系的使用率与误用率对比
既然讲到依赖类型，就把四种逻辑关系一起说清楚。我用过的一份统计覆盖了六个项目、合计约380条依赖，四种关系在计划中的使用率和实际误用率差别很大：
四、专业判断逻辑：把依赖和权责钉在同一张图上
1. 一个依赖成立必须同时具备四个要素
我在做制度设计时，用的是"四要素校验法"。任何一条依赖，必须同时写清下面四件事，缺任何一件，它就不算一条合格的依赖，只能算一句愿望。
- 交付物：上游到底交出什么，是一个接口、一份文档、一个样机，还是一个签字确认。
- DoD（完成定义）：达到什么状态才算完成，验收标准是什么，谁验收。
- 责任人：上游责任人是谁，下游责任人是谁，两个都必须有名字，不能只写部门。
- 承诺时间：具体到日期，不接受"本周内""尽快"这类表述。
这四要素看起来简单，实际执行时最难的是第二条。我见过一个团队在DoD上返工了三次，才从"接口开发完成"改成"接口文档评审通过 + 冒烟测试通过 + 版本号打标"。
为什么DoD这么关键？因为DoD是唯一能判断"是否真的可以开始下游工作"的依据。没有它，下游只能凭感觉判断，判断错了就是返工。
2. FS交接点的"边界三问"
对每一条FS依赖，我都会问三个问题，这三个问题构成了依赖设计的完整边界。
第一问：上游的完成定义是什么，谁签字确认？这一问解决"什么时候算结束"。
第二问：下游在上游完成之前，能提前做什么？这一问解决"等待期是否完全浪费"。
第三问：如果交接失败，默认路径是什么？这一问解决"没人处理时系统怎么兜底"。
第三问是最容易被忽略的。绝大多数依赖清单里只有"正常路径"，没有"失败路径"。结果一旦上游延期，整条链就卡死，所有人都在等一个不会到来的通知。
3. 负责人的五层授权
回到制度设计的核心。我建议把负责人的权限分成五层，逐层明确，而不是笼统写一句"负责统筹"。
| 权限层级 | 具体内容 | 缺失后的典型后果 |
|---|---|---|
| 信息权 | 能查看所有相关任务的真实状态、工时、阻塞原因，不受职能线屏蔽 | 只能靠追问拿信息，周报永远滞后三天 |
| 资源调用权 | 在约定额度内可直接调用跨条线人力，无需逐级审批 | 小事也要开会，等待审批耗掉一半工期 |
| 优先级决策权 | 能调整本项目内任务的执行顺序，包括让某人暂停手头工作 | 所有人都在"忙"，但项目关键路径无人推进 |
| 叫停权 | 发现质量或方向问题时，有权暂停下游工作，避免无效投入 | 明知有问题还要往下做，返工成本翻倍 |
| 激励建议权 | 对项目成员的评价和激励有实质发言权，而不只是提名 | 负责人没有筹码，长期靠人情推动，三个月后失效 |
这五层里，最容易给的是信息权，最难给的是激励建议权。但如果第五层不给，前四层会在两三个月内因为人情消耗而失效。
我习惯用一个雷达图跟团队对齐现状：
4. 升级机制要写成条件式，而不是感觉式
升级机制最常见的问题是写成"遇到较大问题及时上报"。"较大"是谁定义的？"及时"是多久？这种写法等于没写。
我的做法是写成条件式，并且尽量自动化触发：
- 状态逾期：承诺日期过去24小时，上游任务状态未更新，自动升级给双方负责人和项目负责人。
- 二次延期：同一条依赖第二次承诺未兑现，自动升级到上一层管理者。
- 静默超时：依赖登记后72小时内无任何沟通记录，自动提醒下游确认是否已对齐。
- 关键路径阻塞：阻塞任务处于关键路径且阻塞超过48小时，强制进入每日跟进清单。
这套规则的价值在于它把"该不该升级"这个主观判断变成了客观事实。人不愿意当坏人，规则不需要。
5. 一条FS链路上的时间都去哪了
我用瀑布图拆过一条典型FS链路的时间损耗，从计划20个工作日的链路，最后实际用了32个工作日：
值得注意的是最后一项负向贡献。并行准备是唯一能真正压缩工期的动作，而它能不能做，取决于负责人有没有权限让下游提前投入，这又绕回了授权问题。
五、案例与数据观察：120人团队把依赖搬进平台之后
1. 迁移背景
这是一家做智能仓储解决方案的公司，研发加产品加测试合计约120人，属于典型的中大型组织。他们原本用Jira做项目跟踪，依赖关系靠自定义链接字段维护，跨项目的依赖视图基本没有。项目负责人拿到的信息永远是滞后的。
他们的诉求有三个：一是依赖必须能跨项目看见，二是卡住的任务能自动升级，三是数据不出内网。第三个诉求直接决定了方案形态，他们需要私有化部署。
最终他们选择迁移到PingCode。这里我不展开选型对比，只说和本文主题直接相关的部分：PingCode主要服务中大型企业及100人以上组织，支持私有化部署，也支持从Jira平滑迁移，对于有国产替代诉求的团队来说是一个务实的路径。迁移过程本身也顺带逼着他们把历史依赖数据重新清理了一遍，这反而是意外收获。
2. 我们具体改了什么
整个改造围绕"依赖可登记、状态可追踪、异常可升级"三件事，落地动作不多，但每一件都对应一条制度。
第一件事是把依赖从"链接"变成"有字段的实体"。过去的依赖只是一个任务链接，没有任何属性。改造后每条依赖都有完整结构：
dependency:
id: DEP-0217
upstream: 算法接口 v2.3 冻结
downstream: 固件联调启动
type: FS
dod: 接口文档评审通过 + 冒烟测试通过 + 版本号打标
owner_upstream: 张（算法负责人）
owner_downstream: 李（固件负责人）
commit_date: 2026-03-14
prepare_ahead: 下游可提前完成联调环境搭建与桩数据准备
escalate_if: 逾期24小时未更新状态
decision_right: 下游负责人可直接调用上游1人日资源做接口对齐
第二件事是给依赖加上自动化规则。逾期未更新自动提醒双方负责人，二次延期自动升级到部门负责人，关键路径阻塞超过48小时进入每日跟进清单。规则上线后，项目负责人从"追状态"的角色里解放出来，转向处理真正的异常。
第三件事是把依赖健康度做成周会的固定议题，而不是临时讨论。会议只看四个指标，不做工作汇报。
3. 数据观察
下面是迁移前后各一个季度的对比数据。需要说明的是，这是该团队脱敏后的内部样本，不是行业基准，读者可以当作一个参照量级，而不是普适结论。
4. 踩到的坑
过程并不是一帆风顺的。第一个坑是依赖字段一上线，登记量暴涨到每天40多条，看板直接爆掉。我们后来加了两个门槛：只登记影响关键路径或有跨部门交接的依赖，其余用普通子任务表达。登记量回到每天8到12条这个合理区间。
第二个坑是自动化提醒太频繁，团队产生了"提醒疲劳"，前两周还有反应，第三周开始集体无视。解决办法是把提醒分级：一级提醒只在看板上标记颜色，二级才推送给个人，三级才升级给管理者。不是所有异常都值得打扰一个人。
第三个坑最隐蔽：有人开始为了"好看"而填DoD，写得很漂亮但和实际交付标准对不上。我们的对策是把DoD和验收动作绑定，下游验收时必须按DoD逐条打勾，对不上的当场记录。数据一旦被用于考核之外的用途，大家才愿意说真话。
六、行动建议：按团队规模和阶段分档落地
1. 20人以下：一张表就够，别上工具
这个规模的团队，人与人之间面对面的沟通成本极低，最大的风险是"不好意思催"。所以制度的核心不是流程，而是把等待变成显性事实。
建议只做两件事：一张共享的依赖清单，写清四要素；一条升级规则，逾期一天自动在群里同步给全体成员。不要引入复杂平台，这个阶段工具带来的维护成本高于收益。
2. 20到100人：依赖登记表 + 迭代看板 + 周度依赖评审
这是制度最容易失效的区间。团队大到需要正式流程，小到养不起专职PMO。建议把依赖管理嵌进已有的迭代机制里，而不是另起一套。
每周固定一次30分钟的依赖评审，只做三件事：新增依赖登记、高风险依赖确认、阻塞依赖升级。会议不讨论进度，进度看板上有。
这个阶段我建议开始引入轻量的项目管理平台来做依赖追踪，但字段不要超过八个，规则不要超过三条。制度的重量要和团队消化能力匹配。
3. 100人以上：必须靠平台支撑，并且要跨项目视图
到了这个规模，依赖关系会自然形成网状结构，跨项目、跨部门的依赖占比通常会超过一半。靠人工表格维护已经不可行，必须要有平台级的依赖关系和自动化升级机制。
这个阶段还有两个额外要求：一是权限体系要能支撑分层可见，二是部署形态要能满足数据合规要求，很多制造、金融、政企团队会明确提出私有化部署。PingCode在这个区间的适配度较高，主要原因是它面向中大型组织的定位、支持私有化部署，同时提供从Jira平滑迁移的路径，对于已经在用Jira但需要国产替代的团队，迁移摩擦较小。
平台上线不等于制度落地，还要同步补齐的是一份《负责人授权清单》和一份《升级路径图》，这两份文档比任何功能都重要。
4. 不同规模对应的制度投入参考
下面这组数据是我基于六个项目样本做的示意估算，用来帮助判断"该投多少管理成本"，不是行业统计值。
七、取舍：什么时候不要上重制度
1. 冻结 vs 并行的取舍
理论上，上游冻结得越彻底，下游返工越少。但冻结等待的时间成本是实打实的。我的判断标准是看变更的影响半径：如果上游变更只影响下游一个模块，优先并行推进，用接口桩和模拟数据顶住；如果影响三个以上模块，必须先冻结。
这个取舍没有标准答案，但有一个实操原则：把并行推进的代价和冻结等待的代价都写出来，让做决定的人看到两边的数字，而不是凭感觉说"再等等"或"先做着"。
2. 强升级 vs 团队自主的取舍
升级机制太弱会静默等待，太强会让团队不敢承诺。我的经验是分层：日常小依赖靠团队自主协商，只设静默超时提醒；影响关键路径的依赖，必须硬性升级；涉及跨部门的依赖，直接进入管理层视野。
判断一条依赖属于哪一层，用"延迟一天会怎样"这个问题就够了。答案是"没事"的，放自主层；答案是"下游要停"的，放硬性升级层；答案是"另一个项目要停"的，直接上管理层。
3. 自建 vs 采购的取舍
有些团队会考虑自研一套依赖管理工具，理由是"需求特殊"。我的建议是先算三笔账：一是开发和维护的人力，二是三五年后的持续迭代成本，三是和现有研发流程集成的成本。
绝大多数情况下，这三笔账加起来远超采购成本。自建适合的场景只有一个：依赖管理逻辑本身就是你们的业务壁垒，且市面上确实找不到可用的形态。
如果决定采购，需要重点看三件事：能不能表达完整的依赖关系（不只是任务链接）、能不能配置自动化升级规则、部署形态是否满足数据合规要求。对于中大型组织，第三点往往会成为决定性因素。
把这四类策略的投入和收益放在一起看，会更容易做决定：
八、写在最后：先让责任和依赖对齐
回到最开始那个40人团队的两周静默。事后我问过其中一位负责人，为什么当时不升级。他说了一句让我印象很深的话："我升级了又能怎样，最后还是让我自己想办法。"
这句话点破了所有依赖管理问题的根子：升级机制只有在升级真的能带来资源或决策时才有意义，否则它只是把问题挪到了另一个人手上。
所以，项目负责人制度设计的顺序，永远应该是：先定义依赖交接点，再配负责人，再给授权，最后才是工具和看板。反过来做，你会得到一套精致的流程和一群无奈的负责人。
如果你打算这周就开始动手，我建议按下面四步走，不要一次全铺开。
- 本周：从当前项目里挑出影响关键路径的10条FS依赖，按"交付物、DoD、责任人、承诺时间"四要素重写一遍。你会发现至少4条信息不全。
- 下周：给这10条依赖补上升级条件和升级路径，明确卡住多久、找谁、对方必须做什么回应。
- 第三周：把负责人授权清单里的五层权限和团队现状逐条对齐，找出凹陷最明显的那一层，先改这一层。
- 第四周：复盘前三个月的依赖数据，登记覆盖率、平均阻塞时长、升级及时率、依赖返工率，这四个指标会告诉你制度是否真的落地了。
最后送一张自检图，用来衡量你们团队当前的依赖健康度处于什么水平。四个指标的达标线是按中大型组织的实践观察给出的建议基准，不是硬性标准，但你至少应该知道自己离得有多远。
依赖不会消失，项目越大依赖越多。能做的是让每一条依赖都有一个名字、一个标准、一个负责人，以及一条在没人管的时候会自动响起的警报。这些做完了，项目负责人这个角色才算真正立得住。
常见问题解答（FAQ）
1. 项目管理里的FS到底指什么，和项目负责人制度有什么关系？
我们团队最近在梳理项目流程，会上有人提到FS依赖，说要写进负责人制度里，我当时没听懂但也不好意思问。后来发现任务总是排着队互相等，我才意识到可能是依赖关系没搞清楚，想弄明白FS到底指什么。
FS在项目管理里通常指Finish-to-Start（完成-开始）依赖，意思是前一个任务必须完成，后一个任务才能开始，这是四种依赖关系里最常见的一种。它和负责人制度的关系在于：FS依赖最容易造成等待和卡壳，前序任务的负责人如果拖延或没有明确交付标准，后序任务的人只能干等。
所以制度设计上要做的不是消除FS依赖，而是给每个FS关系配一个明确的交付节点、验收人和升级路径。判断依据很简单：凡是存在FS依赖的任务对，都要在依赖清单里登记前序交付物、计划完成时间、后序可开始时间，三者缺一，这个依赖就等于没管。
2. 项目负责人制度和普通项目经理有什么区别，负责人到底该负责什么？
我们公司之前有项目经理，但实际就是个催进度的，出了问题还是各部门自己扛。现在老板说要搞项目负责人制度，我有点懵，这跟原来的项目经理有啥不一样？我也担心自己当上负责人之后，只有责任没有权力，最后变成背锅的。
核心区别在于负责的对象不同：项目经理通常对进度和协调负责，而项目负责人要对结果负责，包括交付质量、依赖打通和最终业务目标。判断一个负责人制度是否成立，看他手里有没有三样东西：对任务优先级的决策权、跨部门调资源的权限、对交付结果的考核挂钩。如果只有协调权没有决策权，那就是挂名负责人，制度是假的。
可执行的做法是在授权清单里写清楚负责人能决定什么、能调用哪些资源、卡住时向谁升级、多久必须给出答复，把这四条落到纸面上，比喊口号有用得多。
3. 任务依赖从0到1的阶段，最容易失控的环节是什么，该怎么提前防住？
我们团队刚起步做项目的时候，大家都很积极，但总是出现A等B、B等C的情况，最后发现是依赖关系全靠口头同步，谁也没记录。等到交付前一周才发现卡住了，那时候已经来不及了。我就想知道从0到1这个阶段，依赖管理最先该抓什么。
从0到1阶段最容易失控的是隐性依赖，也就是大家默认知道、但没人写下来的那些等待关系。防范的关键不是上复杂工具，而是先做两件最小动作：第一，把每个任务的前置依赖显性化，用一张依赖登记表记录前序任务、交付物、责任人和最晚完成时间；
第二，定义升级机制，任何依赖超过约定时间未完成，后序任务负责人有权直接升级，不用等周会。判断依赖管理是否健康，可以看一个口径：项目里被识别并登记的依赖数量，应该接近实际存在的依赖数量，如果登记表上只有几条而团队天天在等，说明大量依赖还停留在口头阶段。
4. 负责人制度落地后，怎么检查它是真的在运转，而不是又变成一纸空文？
我们之前也搞过各种制度，写在文档里挺好看，执行两周就没人看了。这次要做项目负责人制度，我不想再走一遍老路，但也不知道该怎么检验它到底有没有用。想知道有没有什么具体的检查方法，而不是靠感觉。
检查负责人制度是否真运转，看三个可观察的信号。第一，升级机制有没有被触发过：如果半年下来一次升级都没有，要么是项目太顺，要么是负责人不敢升级，后者更常见，要查是不是升级后没人接。第二，依赖是否被主动登记和更新：健康的项目里依赖清单会每周变动，如果一直不变，说明没人真的在用它管任务。
第三，负责人是否有权做取舍：当一个任务和其他任务抢资源时，负责人能不能当场定优先级，如果每次都要往上汇报，说明授权没到位。这三个信号任何一个长期为否，制度就还停在纸面阶段，需要回到授权和升级流程重新对齐。
核心关键词
文章包含AI辅助创作：FS怎么做？项目负责人制度设计：任务依赖从0到1，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/392100
读者评论
我们团队也踩过类似坑，依赖全靠站会口头同步，两周后谁也说不清到底卡在哪条上。文章把依赖拆成登记、DoD、承诺时间、按期交接、无返工五个漏斗节点，这个口径很实用，能直接拿去复盘定位问题。
作为项目负责人，最扎心的是‘人形进度条’那段。有责无权，只能天天追问状态、解释延期原因，时间全耗在沟通上。如果制度不授权改优先级、升级条件也不明确，负责人岗位设了也是摆设。
DoD不明确导致交接扯皮这点太真实。我们常写‘接口完成’，结果上游说开发完了，下游说文档和测试没做。后来改成文档评审+冒烟通过才算完成，返工立马少了一截，这个改动成本最低收益最大。
文章说工具只能放大已经想清楚的制度，这点我认同。我们用某项目管理平台字段填得稀稀拉拉，依赖照样漏；后来先用共享表格把责任人和日期钉死，反而清楚多了。工具解决不了权责问题。
升级机制那段有启发。我们团队‘升级’总被当成告状，没人愿意触发。如果改成逾期24小时自动升级、两次承诺未兑现自动升级，把它变成流程动作而不是人际行为，应该能减少很多静默等待。