任务执行阻塞教程：产品经理制度设计，避坑指南

去年我复盘了一个 62 人研发团队连续 6 个月的任务数据：2347 条任务里，有 419 条经历过至少一次阻塞，平均阻塞时长 3.7 天，折算下来相当于 1550 人天被"挂"在半空中。真正让我意外的不是这个总量，而是阻塞的原因分布，68% 的阻塞，执行者本人根本无权解决。

这个数字把我的注意力从"执行层"硬生生拉回到"制度层"。如果一个团队里三分之二的阻塞都不是执行者能自己拆掉的，那么再强调责任心、再开更多的站会、再让产品经理去群里催，本质上都是在错误的地方使劲。

这篇教程讲的不是"怎么催得更凶"，而是产品经理怎么用制度设计，把任务执行阻塞从"靠人救火"变成"靠机制自动暴露、限期结清"。我会先给结论，再拆真实场景和常见误区，然后给出一套我实际跑过的制度框架，包括工具层面的具体配置、上线前后的数据变化，以及不同团队规模该做的取舍。如果你正带着一个 50 人以上的交付团队，或者你自己就是那个天天在群里问"这个到底卡在哪"的人，这篇可以当操作手册看。

一、先给结论：阻塞是制度产物，不是执行态度问题

1. 五条我反复验证过的结论

先把结论摆在前面，后面所有内容都是围绕这五条展开的。

1. 阻塞的根因大多在上游制度，不在执行者的态度。需求准入不严、验收标准缺失、依赖关系没在计划阶段声明清楚，这三类问题制造了绝大多数阻塞，而它们在任务被领取之前就已经注定了。
2. 制度的目标不是消灭阻塞，而是让阻塞早暴露、可计价、限期结清。一个零阻塞的团队通常不是健康，而是没人在如实上报。
3. 没有阻塞分类字典的团队，复盘出来的永远是"沟通不畅"。分类不是形式主义，它直接决定了谁能解阻、多久必须解掉、算谁的成本。
4. 唯一值得挂考核的指标是阻塞时长，不是阻塞数量。一旦考核数量，隐瞒行为会在两周内出现，数据立刻失真。
5. 产品经理是阻塞的第一责任人，不是协调员。"协调员"这个自我定位，会让你天然地把责任推给"他们不配合"，然后制度永远建不起来。

2. 先定义清楚：什么才算"阻塞"

我在每个团队推行阻塞管理的第一步，都是把"阻塞"的门槛说死，因为这个词太容易被滥用。有人把"我今天不想做"也叫阻塞，有人把"这个需求有点难"也叫阻塞，最后阻塞清单变成垃圾桶。

我的判定标准是三条同时成立才算阻塞：任务在当前执行路径上无法继续推进；继续推进必须依赖执行者职权之外的人或事；执行者在可预期时间内无法自行消除这个依赖。

只满足前两条、第三条不成立的情况，我叫它"等待"，不叫阻塞。比如等一份测试报告，你知道明天上午十点它一定会来，这就是等待，不需要升级、不需要占用管理注意力。而"等上游团队确认接口字段，但对方没有承诺任何时间"，这才叫阻塞。

还有一类叫"风险"，指任务目前还能推进，但按当前趋势未来大概率会被卡住。风险不进阻塞清单，进风险清单，由产品经理在迭代评审时处理。这三类混在一起，是你后面所有报表失真的源头。

3. 为什么这套制度该由产品经理设计，而不是别人

很多团队把阻塞管理交给项目经理或者研发负责人，我观察下来效果都不如交给产品经理。原因很直接：阻塞的四大来源，需求、优先级、范围、验收标准，全部握在产品经理手里。

研发负责人能解决技术类阻塞，但对"需求没冻结"这种阻塞无能为力；项目经理能推动流程，但没有权力决定砍掉哪个需求来释放资源。只有产品经理同时握有需求准入权、优先级排序权和范围调整权，这三项权力恰好是清除阻塞时最常用的工具。

所以我的判断是：产品经理在阻塞管理中的角色不该是"记录者"或"协调者"，而应该是"制度所有者"。你负责定义什么叫阻塞、谁负责解、多久必须解掉、解不掉时砍什么。

二、背景与真实场景：一个 60 人团队的阻塞账本

1. 我拿到的那份原始数据长什么样

这个团队做的是企业级 SaaS 交付，62 人，分为 5 个研发小组、1 个产品组、1 个测试组，同时并行 3 条产品线。工具层面他们用的是某项目管理平台，任务、缺陷、迭代都在里面，但阻塞完全靠微信群口头同步。

我从平台里导出 6 个月的任务变更记录，用任务状态停留时长反推阻塞。原始数据有几个特征让我印象很深。

• 阻塞任务占比 17.8%。每 5.6 条任务就有 1 条经历过阻塞，这个比例在交付型团队里属于中等偏高。
• 平均阻塞时长 3.7 个工作日，但中位数只有 1.2 天。这个巨大的差值说明存在少数超长阻塞在拉高整体，最长的一条阻塞挂了 34 天。
• 跨团队依赖类阻塞的平均时长是团队内部阻塞的 4.3 倍。内部阻塞通常 1 天内就能解决，跨团队的平均要 5 天以上。
• 只有 23% 的阻塞在任务记录里留下了文字说明。剩下 77% 的状态变化没有任何原因记录，只能靠人去回忆。

最后一条是最致命的。没有原因记录，就意味着这个团队每个季度都在重复解决同一批问题，因为没人知道上一批问题到底是什么。

2. 阻塞是怎么长出来的：四个真实现场

现场一：需求验收标准缺失。产品经理写了需求标题和大致描述，但没有写验收标准。开发做到一半发现不知道"做完"长什么样，回头去问，产品经理在开会，一等就是一天半。这类阻塞在这 6 个月里出现了 61 次。

现场二：接口依赖没有在计划阶段声明。A 组的任务依赖 B 组的接口，但这件事在迭代规划会上没人提。A 组做到第 3 天才发现接口还没有，去问 B 组，B 组说这个接口排在下个迭代。这一卡就是 6 天。

现场三：决策悬空。一个涉及数据权限的设计方案，需要在两个部门之间做出取舍。产品经理觉得自己没权限拍，往上推；上级觉得这是产品经理该拍的，往下压。任务就在这个循环里挂了 11 天，最后是 VP 用 5 分钟拍完的。

现场四：测试环境被抢占。测试环境只有一套，两个组同时要用，谁先谁后没有制度。结果是先提交的那个组用上了，另一个组等着，平均每次等 1.8 天。这个问题的本质是资源排队制度缺失，而不是环境不够。

这四个现场对应四类完全不同的制度缺口。如果不做分类，你在复盘会上得到的结论只会是"要加强沟通"，这句话没有任何可执行性。

3. 我做的第一件事不是催进度，是建字典

接手之后我做的第一件事，是花了两个下午把历史上所有能追溯原因的阻塞重新分类，建立了一份七类阻塞字典。分类标准是"按解阻主体分"，不是按现象分。

这一点很多人会做错。按现象分会分出"接口问题""设计问题""环境问题"这种分类，看上去很细，但每一类的解阻主体都不唯一，分类做完还是不知道该找谁。

按解阻主体分，每一类都天然对应一个责任人角色。这是我后面所有制度设计的基石。

这份字典最大的作用是把"这个卡住了"变成了"这是依赖类阻塞，产品经理 24 小时内要给承诺时间"。前者是一句抱怨，后者是一条可执行、可考核的规则。

三、六个常见误区：产品经理最容易踩的坑

1. 误区一：把阻塞当异常事件，不做分类

很多产品经理的处理方式是：看到阻塞就冲上去解决，解决完就过去了，不做记录、不做分类。结果是同一个类型的阻塞每个迭代都在发生，但每次都当成新问题处理。

我算过一笔账，这个团队在制度上线前，产品经理每周花在"临时救火"上的时间平均是 9.5 小时，占了他周工作时间的近四分之一。不做分类的代价，是产品经理被永久锁死在救火模式里，没有时间做真正的产品判断。

2. 误区二：用每日站会代替制度

站会能发现阻塞，但站会不能解决阻塞。这句话我强调过很多次。

站会是暴露机制，不是解决机制。一个团队如果没有分类字典、没有责任人映射、没有响应时限，站会上暴露出来的阻塞，散会之后依然是那句"我下午去问问"。下午问完之后呢？没有人知道。

更糟的是，站会会让阻塞管理变成"表演"。执行者知道每天要报进展，于是倾向于把阻塞拖着不报，等到实在拖不下去才说，这时候留给解决的窗口已经非常窄了。

3. 误区三：让执行者自己追依赖，产品经理只做记录员

这是我最常见到的错误。产品经理在站会上听到"我在等 B 组的接口"，然后说"那你跟进一下"，接着把这条记在自己的小本子上，之后就没了。

执行者追依赖的成功率天然低，因为他没有筹码。一个普通开发去问另一个组的开发"你这个接口什么时候能给我"，对方完全可以回答"我这边排期很满"。这个对话里没有优先级冲突的裁决者，也没有跨团队资源调配的权力。

产品经理去问就完全不同，因为他可以拿"这个需求是 Q3 的客户承诺"或者"那我们把 X 需求往后挪两周"作为交换条件。追依赖本质上是资源置换谈判，谈判需要筹码，而筹码在产品经理手上。

4. 误区四：只上报不结清，养出僵尸阻塞

我在数据里发现过一个很典型的模式：某些任务的阻塞状态持续了 20 天以上，但在这 20 天里，任务其实已经被绕过去了，要么换了实现方案，要么需求被砍了，要么有人偷偷做完了。

问题是任务状态没有更新。这些我称之为"僵尸阻塞"。它们不影响交付，但严重污染数据。当你要用阻塞数据做复盘时，这些僵尸条目会把平均值拉得很难看，让你误判问题严重程度。

治理方法很简单：任何区块阻塞状态超过 72 小时未更新，自动打标签并强制在周会上确认一次。要么结清，要么明确说明为什么还在阻塞。不允许"挂着不管"这个中间态存在。

5. 误区五：用阻塞数量考核个人

这一条几乎一定会发生，而且后果最严重。

我见过一个团队把"阻塞数量"作为研发的负面指标，本意是鼓励大家少制造阻塞。结果两周之内，系统里的阻塞数量下降了 60%，但交付周期没有任何变化，跨团队延期反而变多了。

原因很简单：阻塞数量是一个可以被隐藏的指标，而阻塞时长才是一个相对难以伪造的指标。你可以不报阻塞，但你没法让任务凭空完成。所以考核导向必须放在"解阻速度"和"重复阻塞率"上，而不是放在数量上。

6. 误区六：把"等待"和"阻塞"塞进同一个状态

很多工具的状态流里只有一个"阻塞"或者"挂起"状态，所有不能推进的任务都往里面放。结果看板上永远有一堆红色卡片，但其中大部分是正常等待，真正需要升级的可能只有两三张。

这会直接导致管理注意力被稀释。当所有卡片都是红色的时候，红色就不再是信号。我在后面第四部分会专门讲怎么把这三个状态拆开。

四、专业判断逻辑：阻塞制度设计的五件套

1. 分类字典：先让阻塞可命名

字典是整套制度的地基。我在第二部分已经给出了一份按解阻主体分类的字典，这里补充三个容易被忽略的设计细节。

第一，分类必须互斥且穷尽。一条阻塞只能落在一个类型里。如果一条阻塞既像依赖类又像决策类，说明你的分类维度混了。我通常会把"需要别人做决定"归为决策类，"需要别人做事"归为依赖类，边界就清楚了。

第二，每一类必须绑定一个第一责任人角色，而不是具体人名。绑定人名会在人员变动时失效，绑定角色则可以在组织架构调整后继续生效。

第三，分类数量控制在 6 到 8 类。少于 6 类粒度太粗，指导不了行动；多于 8 类，一线记不住，实际填报时就会乱填。我试过 12 类的版本，填报准确率从 84% 掉到了 51%。

2. 状态机：把阻塞、等待、风险三态拆开

这是我在工具层面做的最重要的一件事。原来的状态流里，任务只有"进行中"和"阻塞"两种非完成态，所有人都往"阻塞"里塞。我把它拆成了四个状态。

• 进行中：任务正在被推进，这是默认状态。
• 等待中：暂不能推进，但已有明确的承诺时间点，且承诺时间在 3 个工作日以内。这个状态不需要升级，系统只做记录。
• 阻塞中：不能推进，且没有明确承诺时间，或承诺时间已过。进入这个状态必须填写阻塞类型和阻塞责任人。
• 有风险：目前还能推进，但按趋势预计会延期。这个状态只用于预警，不进阻塞报表。

拆开之后，效果是立竿见影的。制度上线前，看板上处于"阻塞"状态的卡片平均有 41 张；拆分之后，真正处于"阻塞中"的稳定在 8 到 12 张之间，其余都归入了等待中。管理注意力从 41 张收敛到 10 张，产品经理才有可能真正把每一张都处理掉。

这里还有一个关键机制：从"阻塞中"转到"等待中"需要填写承诺时间，且系统会自动校验这个时间是否超过 3 个工作日。超过的，不允许转，必须走升级流程。这就堵死了"随便填个时间糊弄过去"这条路。

3. 升级阶梯：给每一级设定响应时限

升级机制的关键不是"能升级"，而是"什么时候必须升级"。如果全靠人的判断，一线永远倾向于再等等，而等待正是阻塞时长的主要来源。

我用的是一套四级的时限触发机制，全部写在系统自动化规则里，不靠人记。

1. 第 0 到 4 小时：执行者自主处理。执行者在任务里 @ 依赖方，写明需要什么、什么时候要。这个动作必须留在任务记录里，不许私聊。
2. 第 4 到 24 小时：产品经理介入，转为谈判模式。产品经理作为持有优先级筹码的一方，去和依赖方谈一个明确的交付时间，或者调整本方范围。24 小时内必须产出明确结论。
3. 第 24 到 72 小时：进入部门级阻塞清单。这个清单在每个部门的周会上必过，由部门负责人对每一条给出处理意见或资源承诺。
4. 超过 72 小时：升级到项目集或管理层。触发条件是强制的，同时必须回答一个问题：是砍需求、加资源，还是调整交付时间。不允许出现"继续跟进"这种处理结论。

这套阶梯最关键的设计是每一级都有明确的时限和明确的产出物。第 2 级的产出物是一个承诺时间，第 4 级的产出物是一个取舍决定。如果某一级的产出物缺失，任务不允许停留，自动向上一级流转。

我在实施时发现一个反常识的现象：真正被用到的升级，80% 集中在第 2 级。也就是说，绝大多数阻塞在 24 小时内由产品经理通过优先级谈判就解决了。第 3、4 级更像是威慑，它们存在的意义不是被频繁使用，而是让第 1 级的执行者知道"再拖下去会有人来问"。

4. 责任映射：谁解阻，谁兜底

责任映射要回答两个问题：谁负责解，谁负责在解不掉的时候承担后果。很多团队只回答了第一个。

我的做法是每一类阻塞都配一个"第一责任人"和一个"兜底责任人"。第一责任人负责在时限内推进；如果时限到达仍未结清，兜底责任人必须接管，且这次接管会被记录在案，进入个人的月度复盘。

举例来说，需求类阻塞的第一责任人是产品经理，兜底责任人是产品负责人。如果产品经理在 4 小时内没有补充验收标准，产品负责人必须在 8 小时内补上，这条记录会出现在产品负责人的月度复盘里。这个设计的效果是，兜底责任人会主动去盯第一责任人，制度就产生了自我运转的动力，而不是所有压力都压在项目负责人一个人身上。

5. 度量：只挂三个指标

指标越多，越没人看。我给这套制度只设计三个核心指标，加上两个辅助观察项。

其中阻塞再发率是最有价值、也最少被使用的指标。它衡量的是"你上次解决了这个阻塞，但有没有从根上解决"。如果依赖类阻塞的再发率高达 40%，说明你每次都在做临时协调，而没有去改上游的计划机制。

五、案例与数据观察：把制度落到工具里

1. 为什么制度一定要落到工具层面

我在第一个团队推行这套制度时，用的是文档加周会的方式，坚持了两个月就退了。原因很实际：制度依赖人记，就一定会在忙碌的时候被跳过。

要让制度自运转，必须满足三个条件：阻塞不能随手挂；挂了必须填字段；超时必须自动提醒。这三件事人做不到稳定，工具可以。所以从第二个团队开始，我把整套制度全部配进项目管理工具里。

2. 我在 PingCode 里的具体配置

这里以 PingCode 为例说明我实际配置的过程，因为它支持自定义工作项类型、状态流和自动化规则，比较适合把上述制度固化下来。需要说明的是，PingCode 主要服务中大型企业及 100 人以上组织，中小企业用它的完整能力可能偏重。

第一步是改状态流。我在任务和缺陷这两类工作项里，把非完成状态从原来的"进行中/阻塞"改成四态：进行中、等待中、阻塞中、有风险。并在"阻塞中"状态上挂了必填字段校验。

第二步是加自定义字段。我加了四个字段：阻塞类型（单选，七个选项）、阻塞责任人（人员字段）、承诺解除时间（日期时间字段）、阻塞根因描述（多行文本，必填）。

第三步是配自动化规则。这是整套配置里最关键的一步，因为它是让制度"活"起来的部分。我配了三条核心规则。

规则一：状态进入"阻塞中"时
条件：工作项状态 = 阻塞中

动作：

校验阻塞类型、阻塞责任人、阻塞根因描述是否已填写
→ 未填写则拒绝状态变更
自动 @ 阻塞责任人，并写入一条评论："已在 {当前时间} 进入阻塞，请于 24 小时内给出承诺解除时间"
自动打标签 blocked
规则二：阻塞超过 24 小时未结清

条件：状态 = 阻塞中 且 停留时长 > 24 小时

动作：

自动 @ 产品经理和部门负责人
将工作项加入"部门级阻塞清单"视图
在周会看板上标记为红色高亮
规则三：阻塞超过 72 小时未结清

条件：状态 = 阻塞中 且 停留时长 > 72 小时

动作：

1. 自动升级至项目集负责人
2. 强制要求填写"处理结论"字段，选项为：砍需求 / 加资源 / 调整交付时间
3. 自动生成一条记录到月度阻塞复盘报表

第四步是配报表。我做了三张视图：按阻塞类型分组的条数分布、按阻塞时长排序的明细列表、按责任人分组的超时未结清统计。这三张视图每周一自动推送给产品和研发负责人。

3. 从 Jira 迁移过来的团队要注意什么

这个团队原本用 Jira，迁移到 PingCode 的过程中有几个坑我踩过，值得提前说。

第一个坑是"阻塞"语义的映射。Jira 里的 Flagged 是一个布尔标记，它既被用来表示阻塞，也被用来表示"重点关注"。直接映射过来会导致大量误报。正确做法是迁移时不分状态，先全部标记为普通任务，然后人工过一遍历史阻塞记录，只把有明确阻塞事实的重新打标。这个过程花了我 3 天，但值得。

第二个坑是状态流的差异。Jira 的工作流和 PingCode 的状态流配置方式不同，如果直接按原状态一对一映射，很容易出现"等待中"和"阻塞中"合并的情况。我的做法是迁移前先在 PingCode 里把四态状态流建好，再按语义映射，而不是按名称映射。

第三个坑是历史数据的字段缺失。原来的任务没有阻塞类型、承诺时间这些字段，迁移后这些字段全为空。不要试图去补全历史数据，那是无底洞。我的做法是给历史任务打一个"迁移前"标签，在报表里默认过滤掉，只用迁移后的数据做度量。等新数据积累满 3 个月，再考虑是否合并分析。

PingCode 支持 Jira 数据的平滑迁移，也支持私有化部署，这对数据敏感的中大型企业来说是比较关键的一点，阻塞数据和任务数据往往包含客户信息和交付细节，能不能落在自己的服务器上，很多时候是选型的硬门槛。

4. 上线 90 天后的数据变化

制度完整落在工具里之后，我跟踪了 90 天的数据。

• 平均阻塞时长从 3.7 天降到 1.4 天，降幅 62%。
• 超时未结清率从 34% 降到 9%。
• 阻塞原因记录完整率从 23% 提升到 91%。这一项主要靠必填字段，几乎不依赖人的自觉。
• 产品经理每周花在救火上的时间从 9.5 小时降到 3.2 小时，节省出来的时间被用在了需求前置评审上。
• 迭代交付准时率从 71% 提升到 88%。这一项不能全部归功于阻塞管理，但时间上高度相关。

有一个反直觉的发现：上线后的前 30 天，系统里记录的阻塞数量反而上升了 18%。这不是制度变差了，而是大量原来被隐瞒的阻塞开始被如实上报。这个阶段一定要顶住压力，如果这时候因为"数据变难看"就松绑，制度会立刻倒退回去，而且再也不会有人相信它。

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

1. 20 人以下团队：别搞完整制度，搞一个字段就够

20 人以下的团队，沟通成本本来就低，人少到"谁在等谁"一句话就能问清楚。这个阶段上完整的状态机、升级阶梯、报表体系，是典型的过度设计，维护成本会超过收益。

我的建议是：只在任务上加一个"阻塞原因"的文本字段，要求填写时写清楚"我在等谁、等什么、什么时候要"。三件事写清楚，80% 的问题当天就能解决。等到团队超过 30 人、开始出现跨组依赖的时候，再考虑升级到四态状态机。

2. 50 到 150 人团队：完整上四态状态机 + 升级阶梯

这个规模是阻塞管理制度收益最高的区间。人一多，跨组依赖成为常态，"谁在等谁"不再是一句话能问清的，靠人肉协调必然出现信息丢失。

落地的顺序我建议是：先建分类字典，再改状态机，最后配自动化规则。顺序不能反。我见过有团队直接从自动化规则开始配，结果因为字典没建好，规则触发了一堆误报，两周后整个团队都开始忽略系统通知，制度名存实亡。

在这个规模区间，如果要选工具，我会优先考虑支持自定义工作项类型、状态流和自动化规则的项目管理平台。像 PingCode 这类主要服务中大型企业和 100 人以上组织的平台，在自定义能力和私有化部署上有比较明显的适配性，也支持从 Jira 平滑迁移，适合原本就在用国外工具、现在要做国产替代的团队。

3. 300 人以上或多项目集：加一层项目集级阻塞视图

到 300 人以上，部门级阻塞清单会开始不够用，因为大量阻塞是跨项目集的。这时候需要在部门级之上再加一层项目集级阻塞视图。

我的做法是：项目集级视图只看三类阻塞，跨项目集依赖、超 72 小时未结清、影响里程碑的阻塞。其余的留在部门级处理。这样做的目的是控制项目集层级的会议信息量，让它只处理真正需要高层裁决的问题。

同时，这个规模下必须开始看"阻塞再发率"的部门分布。如果某个部门的再发率长期高于 35%，问题通常不在阻塞处理环节，而在该部门的迭代规划环节，他们习惯性地把没想清楚的依赖排进迭代。

4. 已经被阻塞拖垮的团队：急救顺序

如果你的团队现在正处于阻塞堆积、交付延期、天天救火的状态，不要想着一次性把制度建全。按下面的顺序做，两周内能看到明显改善。

1. 第一周第一天：把所有当前挂着"阻塞"的任务拉出来，逐条问"这条还阻塞吗"。我的经验是会有 30% 到 40% 是僵尸阻塞，直接结清或关闭。
2. 第一周第二天：把剩下的阻塞按解阻主体分成 4 到 6 类，逐条指派责任人和承诺时间。不要做复杂字典，先跑起来。
3. 第一周第三天到第五天：产品经理集中处理决策类和依赖类阻塞。这两类占剩余阻塞的七成以上，且产品经理有权解决。
4. 第二周：把"阻塞中必须填原因和责任人"配进工具。这一条是防止旧问题复发的关键。
5. 第二周之后：开始记录数据，一个月后再决定要不要上完整的升级阶梯。

七、取舍：制度越严越好吗

1. 三类必须付的成本

阻塞管理制度不是免费的，有三类成本你一定会付，提前想清楚比事后抱怨好。

第一类是填报成本。每挂一次阻塞要填 3 到 4 个字段，按一条阻塞 2 分钟计算，一个每月发生 80 条阻塞的团队，一年是 32 个小时。这个成本必须付，因为不填字段的阻塞数据没有任何分析价值。

第二类是误报成本。制度上线初期一定会有误报，有人把等待挂成阻塞，有人把风险挂成阻塞。我的经验是前两周误报率会到 20% 到 30%，需要通过复盘逐步校准。这段时间不要急着改规则，先让大家把习惯建立起来。

第三类是会议成本。部门级阻塞清单周会，每次大约 30 分钟。如果一个部门每周有 10 条阻塞要过，这个时间是必要的。但如果超过 20 条，说明前两级失效了，应该去查前两级，而不是延长会议。

2. 三种可以放弃的场景

不是所有团队都需要这套制度，有三种情况我建议直接放弃，把精力放在别的地方。

• 探索型项目、需求高度不确定。这种情况下阻塞是常态，每天的计划都可能变。上严格制度只会消耗团队精力。改用短周期交付和每周对齐即可。
• 团队人数低于 15 人且没有跨组依赖。前面已经说过，沟通成本低于制度成本。
• 组织决策链路本身超过 72 小时。如果你的公司从提出决策到拍板平均要 5 天，那你设的 24 小时升级阶梯注定形同虚设。这种情况下应该先去改决策链路，而不是在阻塞制度上加码。

3. 我自己的取舍原则

做了几年下来，我总结出一条自己的取舍原则：凡是能靠工具强制的，就不要靠人自觉；凡是需要人判断的，就给明确的判断标准和时限。

比如"阻塞必填原因"这是工具能强制的，就一定要做成必填，不要指望大家主动填。"这条阻塞该不该升级"是需要人判断的，那就给出明确的时限标准，超过 24 小时自动升级，把判断变成规则。

另一条原则是：宁可少一个指标，不要多一个没人看的指标。我见过太多团队的阻塞报表有十几张图，结果没有一张被真正用起来。三个核心指标，每周看一次，比十五个指标每月看一次有价值得多。

八、总结：阻塞管理的独特视角与下一步

回到最开始那组数据。2347 条任务、419 条阻塞、68% 的阻塞执行者无权解决，这三个数字合起来只说明一件事：如果你在用管理执行者的方式管理阻塞，你管理的是一个你控制不了的变量。

我想强调的独特观点有三个。第一个是，阻塞管理的核心不是"减少阻塞"，而是"缩短阻塞"。因为阻塞的绝对数量由业务复杂度和组织规模决定，你几乎无法显著降低它，但你完全可以把平均阻塞时长从 3.7 天压到 1.4 天。第二个是，产品经理的角色定位决定了制度的上限。把自己定位成协调员，你只能处理你碰得到的阻塞；把自己定位成制度所有者，你才能让整个系统按规则运转。

第三个，也是最容易被忽略的：制度上线后的第一个月，阻塞数据一定会变难看，这是好事，不是坏事。那 18% 的增长是过去被藏起来的问题终于浮出来了。这个阶段最需要的是顶住压力，而不是松绑规则。

下一步我会建议你做三件事，按顺序来。第一，把你团队现在所有挂着"阻塞"状态的任务拉出来，逐条确认是否真的还阻塞，先把僵尸阻塞清掉。第二，用一张表把剩下的阻塞按"谁有能力解"分成 4 到 6 类，给每一类指派一个责任角色和一个响应时限。第三，如果你在用项目管理工具，把"阻塞中必须填写原因和责任人"配成必填校验，这是整套制度里唯一一个不依赖任何人自觉性的环节，也是最小成本、最大确定性的一步。

做完这三步，你会得到一个比现在清晰得多的视图：你的团队到底被什么卡住，卡了多久，谁应该解。有这张图在手，后面无论是升级阶梯还是度量体系，都是水到渠成的事。