任务执行阻塞教程：跨部门团队协同管理，避坑指南

去年第四季度，我陪同一家中型制造企业的PMO做项目复盘，翻出一个很典型的案例：一个跨研发、采购、质量三个部门的物料替代项目，计划周期4周，实际交付拖了11周。复盘会上大家的第一反应是"跨部门沟通不到位"。但把11周的等待时间逐条拆开之后，真正因为"没人回消息"浪费掉的时间不到2天，其余时间全部卡在三个点上，一次没人拍板的技术选型、一次采购预算被季度指标挤占、一次验收标准变更后没有重新确认责任人。

这三件事都不是态度问题，而是任务执行阻塞从来没有被正式命名过。

这个观察改变了我后来做跨部门协同的方式。我不再先谈"如何沟通"，而是先做一件事：把"卡住"这件事本身变成一个可以被记录、被归因、被升级、被闭环的管理对象。这篇教程就是这套方法的完整拆解，包含七类阻塞的诊断方式、四个结构性根因、启动期与执行期的防阻塞设计、四级升级阶梯、十个高频避坑点，以及三张可以直接套用的表格。

一、先给结论：跨部门任务卡住，多数不是"沟通问题"

1. 三条核心判断

在展开方法论之前，我先把最关键的判断放在前面，后面所有内容都是这三条判断的展开。

• 判断一：阻塞是可以分类的，延迟不能。把所有"进度慢"都归到"执行力不足"，等于放弃了对问题的归因能力。
• 判断二：绝大多数跨部门阻塞是结构性阻塞，不是个人意愿问题。目标不互认、权责不匹配、接口无主、缺升级机制，这四条覆盖了我见过的大部分反复卡点。
• 判断三：不建立升级机制的协同，本质上是在消耗人情。人情有额度，用完就没有了，而且不可复用。

2. 阻塞、延迟、拖延、冲突的边界

很多人把"任务没动"统称为阻塞，这是个浪费诊断机会的做法。我在实际项目里会严格区分四种状态，因为它们的处理动作完全不同。

把延迟当阻塞处理，会浪费升级资源；把阻塞当拖延处理，会把结构问题变成对人的指责。这是跨部门协同里最常见的一类错配。

3. 最小闭环：命名，归因，升级，闭环

我给跨部门任务设计的最小管理闭环只有四步，听起来简单，但真正做全的团队非常少。

1. 命名：用一句话写清"卡在什么上、卡在谁那里、卡了多久"。
2. 归因：判断属于七类阻塞中的哪一类，而不是笼统说"推进困难"。
3. 升级：到达预设阈值后，按阶梯触发决策，而不是继续催办。
4. 闭环：升级后必须产出决策记录、任务重排和风险同步，否则等于白升。

二、三个真实场景：任务是怎么一步步卡死的

1. 场景一：方案通过了，执行停摆三周

某消费电子公司做新品包装改版，跨市场、设计、供应链三个部门。评审会开完，方案通过，会议纪要发到群里，大家回复"收到"。然后三周没有任何实际进展。

我后来访谈各方才发现问题的真实结构：市场部认为设计部会出初稿，设计部认为市场部要先给文案定稿，供应链认为包装规格还没锁定所以没法询价。三个部门都在等别人先动，而会议纪要里没有一句话写明"谁在什么日期交付什么"。

这类阻塞的本质是"接口无主"。方案通过只是一个决策结果，不等于执行分工已经成立。决策和执行之间缺了一层"交付接口定义"，任务就会在所有人都不失职的情况下集体停摆。

2. 场景二：群里@了七次，没有人接

第二个场景来自一家SaaS公司的临时需求。运营侧提了一个数据看板需求，@了数据团队负责人七次，对方每次都说"这周排一下"。一个月过去，看板没做，运营侧的季度目标被拖黄。

表面看这是"响应不及时"。但把时间线拉出来，真正的原因有三层：数据团队季度OKR里没有这个需求；运营侧没有和苏说清这个需求影响的是哪条业务线指标；双方没有约定"如果排不进去，什么时候升级、向谁升级"。

这是一个典型的优先级阻塞叠加升级机制缺失。运营侧唯一的武器是反复催，而催办在对方优先级体系里根本不构成压力。

3. 场景三：审批链上的"隐形等待"

第三个场景更隐蔽。一家制造企业的采购变更流程需要经过4个审批节点，每个节点的平均停留时间是1.8个工作日。看起来每个节点都不慢，但整个流程平均耗时11.2天。

更麻烦的是，任何一个节点退回，链条就要重新走一遍。项目组感知到的是"流程卡、推进难"，但真正的瓶颈是审批链太长且不支持并行，而不是某个审批人不配合。

我把这三类场景里"被阻塞吃掉的时间占比"做了估算，结果很能说明问题。

三、拆解五个常见误区：为什么你的催办越催越无效

1. 误区一：把"沟通不足"当成通用解释

"沟通不到位"是跨部门复盘里出现频率最高的结论，也是最没有行动价值的一个。因为它既不指向具体的卡点，也不指向具体的责任人，更不指向具体的机制改动。

我的判断是：如果一个团队连续三个项目的复盘结论都是"沟通不足"，那问题一定不在沟通，而在这三个项目里有同一类结构缺陷没有被修。重复出现的阻塞，几乎都是机制问题，而不是人的意愿问题。

2. 误区二：把"催办"当成推进手段

催办的隐含假设是：对方知道该做什么，只是没做。但在跨部门场景里，更常见的情况是：对方不知道优先级、没有权限、或者根本不认这个目标。

这时候催办不仅无效，还有副作用，它把结构性矛盾转化成个人之间的压力，消耗的是关系，解决的是零问题。

3. 误区三：把"多人负责"当成安全垫

很多跨部门任务会安排"三方共同负责"或"各部门派一个对接人"，看起来责任覆盖了，实际上决策权没人承担。多人负责的直接后果是：出问题时没人第一时间站出来，需要拍板时所有人都在等别人先说。

我的经验是，一个跨部门任务只能有一个唯一的推进责任人，其余人都是支持角色。这个责任人不必是职级最高的，但必须是唯一对交付日期负责的人。

4. 误区四：把"升级"当成告状

很多人不愿意升级，是因为担心被同事解读为"打小报告"。结果是：卡点一直压在执行层，直到项目临期才引爆，这时候升级已经来不及了。

升级的本质是触发决策和资源，而不是评价某个人。如果升级材料里写的是"事实、影响、选项、建议、时限"，没有人会觉得这是告状；如果是"某某不配合"，那就是告状。区别不在行为，在材料。

5. 误区五：把"复盘"做成追责会

最后一个误区来自复盘环节。我见过太多复盘会开场第一句话是"这次是谁的责任"，然后整个会议变成防御性陈述，最后产出的结论是"下次加强沟通"。

有效的复盘应该先问：这次阻塞属于哪一类？当时有没有触发升级阈值？如果没有，是阈值没设，还是设了没人执行？把复盘对象从人转向机制，才不会每次都得出同一个无效结论。

四、阻塞诊断：七类卡点与判断逻辑

1. 决策阻塞：没人拍板、权限不清

症状：任务已经推进到需要选择方案的节点，但迟迟没有决议；或者说"要等领导定"，而领导一直没被正式告知。这类阻塞的表现往往是"沉默"，因为没有明确卡在谁身上。

常见误判：把它当成"推进节奏慢"，继续等。正确的做法是把它明确命名为决策阻塞，写清需要谁在何时做出什么决策。

处理动作：列出需要决策的事项清单、可选项、每项的代价和影响，附上决策截止日期，提交给有权限的人。

升级阈值：超过承诺决策日期2个工作日仍未决，即上升到上一级。

2. 依赖阻塞：上游未交付、接口未定义

症状：任务本身没问题，但它的启动依赖另一个团队或另一个系统的产出。上游没动，下游只能等。

常见误判：把等待当成"还没轮到"。正确做法是把上游交付物的具体定义、格式、日期写清楚，并确认上游认领了这个日期。

处理动作：建立依赖清单，标出上游责任人、交付物、承诺日期，以及上游本身被阻塞时的二级依赖。

升级阈值：上游承诺日期前1个工作日未给出进展信号，即触发一次明确确认，而不是等过期再催。

3. 资源阻塞：人力预算被抢占

症状：对方认这个任务，但抽不出人、批不下预算、排不进迭代。

常见误判：把资源问题当成态度问题，反复催人。正确做法是把资源问题交回优先级和预算决策层，因为资源调配不是执行人自己能解决的。

处理动作：把任务对业务的影响量化，提供给资源决策人，让资源分配变成一个有依据的选择题。

升级阈值：资源需求提出后1周未分配到具体人员，即上升一级。

4. 优先级阻塞：部门目标不一致

症状：这件事在你这儿是季度重点，在对方那儿是季度末的备选。

常见误判：认为"讲清楚重要性对方就会做"。如果双方指标本身冲突，再讲也无效，因为对方的考核压力没有变化。

处理动作：把两个部门的指标冲突摆到共同上级面前，让优先级在更上层被明确排序。

升级阈值：同一事项第三次被对方排到"下个迭代"，即触发升级。

5. 信息阻塞：口径、文档、数据不同步

症状：各方都在推进，但用的是不同版本的需求、不同的数据口径、不同版本的接口定义。

常见误判：以为"多开会就能对齐"。实际上信息阻塞的解药是唯一信息源，而不是更多会议。

处理动作：建立单一信息源，明确决策记录、变更记录的归档位置，并规定"未归档不算生效"。

升级阈值：同一事项出现两版并行的定义，立即停止推进并澄清，不用等阈值。

6. 流程阻塞：审批链长、合规卡点

症状：业务上已经想清楚了，但流程上走不动，或者每走一步就退回一次。

常见误判：把它归到"某个人不批"。要区分"审批人卡"和"审批链设计卡"，后者才是主因。

处理动作：统计每个节点的平均停留时长和退回率，找出真正的瓶颈节点，判断哪些可以并行、哪些可以前置。

升级阈值：单一节点停留超过3个工作日，或者同一环节被退回2次，触发流程复盘。

7. 关系阻塞：历史冲突、信任不足

症状：事情本身不难，但一到这两个部门之间就变形，或者沟通总是带着情绪。

常见误判：把所有问题心理化。关系阻塞确实存在，但它不是万能解释，只有在其他六类都排查完仍无解时才考虑。

处理动作：引入中立方、使用书面而非口头沟通、把互动规则写清楚，而不是强行要求"多换位思考"。

升级阈值：当沟通已经开始影响正常决策执行，交由共同上级处理关系层面的问题。

五、结构性根因：为什么同类阻塞会反复出现

1. 目标不互认：部门指标与项目目标冲突

这是最底层的一条。当一个项目的目标，对某个参与部门的季度考核没有正向贡献甚至构成挤占时，这个部门就没有动力真正投入。

这类问题不能靠沟通解决，因为它不是认知问题，是激励结构问题。判断信号是：同一个部门在多个项目上都出现拖延，且拖延的都是同一类任务。这时候要调整的是目标映射，而项目组自己没有这个权限。

2. 权责不匹配：责任大、权限小

很多跨部门任务的责任人是基层执行同学，但他的职级和权限根本不足以调动其他部门。当任务顺利时，责任人是协调者；当任务卡住时，责任人就变成了背锅者。

正确的做法是把"责任"和"权限"配对：如果一个人对交付日期负责，就必须赋予他在卡点触发升级的正式权利。升级权是需求，不是恩赐。

3. 接口无主：都负责等于没人负责

我反复强调这一点，因为它是最容易修、收益也最大的一条。任何一个需要跨部门交付的任务，都必须有唯一责任人和每个环节的唯一接口人。

接口人不一定是执行人，但一定是对接窗口。把所有"接口人"列成一张清单，比开三次协调会都有用。

4. 缺升级机制：只能靠人情和领导临时推动

当一个组织里所有跨部门卡点都靠"找领导打个招呼"来解决，说明它没有升级机制。这类组织的常态是：事情拖到临界点，由某个有分量的人出面压一下，问题解决了但机制没动，下次继续。

升级机制的价值在于：它把"靠谁出面"变成"按规则触发"。前者只能救火，后者可以预防。

六、启动期设计：把阻塞挡在发生之前

1. 明确唯一责任人与接口人

任何跨部门任务启动时，第一件事不是排计划，是确认两件事：谁是唯一推进责任人，每个参与部门的接口人是谁。

责任人写一个人名，不写部门；接口人写"部门 + 姓名 + 可联系时段"。这两条如果启动时没定，后面一定会补课，而且补课成本更高。

2. 用责任矩阵替代口头分工

不需要复杂模型，一张四列表格就够了：谁决策、谁执行、谁支持、谁知会。判断标准很简单，如果一项任务出现"决策人"空缺，它一定会变成决策阻塞。

3. 把"尽快"翻译成日期与标准

"尽快""越快越好""这周内看看"，这类表达在跨部门任务里几乎等同于没有承诺。我会强制把每一个交付物写成两件事：具体日期 + 验收标准。

验收标准要写到"第三方能判断是否通过"的程度。"做一版包装设计"是模糊的，"提交一版符合现有印刷工艺、含3个尺寸、附色号说明的包装设计稿"才是可验收的。

4. 画出依赖关系图

依赖关系图不一定要用专业工具画，一张表格就能承载：每项任务标注它的上游输入、输出对象、如果是二级依赖就标注二级依赖方。

画这张图最大的价值不是可视化，而是提前暴露"链式依赖"，如果A依赖B，B依赖C，那C一旦延迟，全局都会受影响，这类任务必须优先加保护。

5. 预设升级阈值

这是启动期最容易被跳过、但收益最高的一步。阈值要在任务启动时就写清楚，而不是等到卡住了再讨论要不要升级。

我常用的阈值模板是："如果某依赖在原定日期后2个工作日内没有实质进展，责任人有权发起一次正式升级，升级对象是双方共同上级。"写到这个程度，升级就不再需要心理建设。

七、执行期机制：让阻塞被看见、被记录、被闭环

1. 阻塞登记表：让卡点可见

阻塞登记表是整套方法的抓手。字段不需要多，但要能一眼看出卡在哪、卡多久、谁负责推。

阻塞登记表字段建议

1. 编号
2. 关联任务
3. 阻塞类型（七类之一）
4. 阻塞描述（一句话写清卡在什么上）
5. 阻塞方 / 接口人
6. 提出日期
7. 已等待天数
8. 对交付日期的影响（天）
9. 责任人的下一步动作
10. 承诺解决日期
11. 是否触发升级 / 升级对象
12. 闭环状态（开放 / 已解决 / 已转其他类型）

这张表有一个硬性规则：任何阻塞超过承诺解决日期未闭环，就必须自动出现在下次协同会的议题第一位，不允许被新话题挤走。

2. 站会只开"阻塞会"

很多团队的日常协同会开成了流水账汇报，每个人讲完"我昨天做了什么"，会议结束，卡点还在原地。

我建议把这类会议重构为阻塞会：每人只讲两件事，我目前被什么卡住、我需要谁在什么时间做什么。没被卡住的人不发言，或者会后异步同步。

这个规则执行后，会议时长通常能从40分钟压缩到15分钟左右，而真正被处理的问题反而更多。

3. 异步留痕：决策记录与变更记录

跨部门协同最贵的一类返工是"当初说的不是这个意思"。避免它的方式不是反复确认，而是留下两条记录：决策记录和变更记录。

决策记录写明：什么时间、什么场景下、谁基于什么依据、做出了什么决策、影响哪些任务。变更记录写明：什么被改了、为什么改、谁批准的、影响范围。

规则可以定得很直白：没有归档的决策不生效，没有归档的变更不予执行。这一条能砍掉大量口头承诺引发的争议。

4. 催办话术：从"你什么时候做"改成"谁在何时决策"

催办话术的核心转变是：把压力从人身上转到流程上，把问句从"进度"改成"阻碍"。

低效催办：
"这个需求你什么时候能排上？"

有效催办：

"这个需求目前卡在优先级还是资源？如果是优先级，

需要谁在什么时候拍板排序？如果是资源，需要补充

多少人天，什么时候能确定？我这边可以把业务影响

数据准备好，供决策时参考。"

这个话术的作用不是"更礼貌"，而是把对方从"被追进度"的位置，换到"共同定位卡点"的位置。对方不必防御，反而更容易给出真实原因。

八、升级机制：如何不撕破脸也能推动决策

1. 升级是触发决策，不是告状

前文提到过，升级和告状的区别在于材料。升级材料里写"事实、影响、选项、建议、时限"，它指向的是决策；写"某某不配合"，它指向的是评价。前者任何人都会支持，后者任何人都会防御。

我再补一条：升级应该在卡点形成时发生，而不是在项目临期时发生。提前升级是小问题加一个人，临期升级是大问题加一堆人。

2. 四级升级阶梯

这张表的用法是：每个卡点在登记时就对应一个当前级别，超过响应时间未解决，就升到下一级。升级不再需要临时判断"该不该找领导"，只需要看表。

3. 升级材料五要素

升级材料写不好，是很多人升级失败的原因。我的模板固定为五要素：

1. 事实：客观发生的事，附日期和来源，不加评价性词语。
2. 影响：对交付日期、成本、业务指标的具体影响，最好量化。
3. 选项：列出2-4个可选方案，包括"维持现状"这一项。
4. 建议：明确写出你建议选哪个，理由是什么。
5. 时限：需要对方在什么时间前给出决定，以及超时的默认处理。

五要素里最容易漏的是"选项"和"建议"。升级者往往只提交问题，让决策人从零开始想方案，这样的升级会被无限期搁置。把问题升级为选择题，决策速度通常能提升数倍。

4. 升级后的闭环

升级完成不等于问题解决。我要求每次升级后必须落实三件事：

• 决策记录：谁在什么时候决定了什么，写清楚并归档。
• 任务重排：根据决策结果更新任务日期、责任人、依赖关系，通知所有受影响方。
• 风险同步：如果决策结果是"接受延迟"，要把这个延迟及其影响同步给相关方，避免后面再次当成意外。

三件事缺一件，本次升级就在事实上无效，同类问题大概率还会重演。

九、避坑指南：跨部门协同的十个高频坑

1. 十个坑的错误动作与替代动作

以下十个坑，每一个我都见过至少三次，且每一个都有明确的替代动作。

这十条里，如果只能先改三条，我会选第1条、第4条和第5条。拆阻塞、定唯一责任人、建升级机制，这三条的组合能在两三个项目周期内显著降低卡点积压。

十、可直接套用的三张表

1. 阻塞诊断表

阻塞诊断表
任务名称：

当前阶段：

责任人：

提出日期：

阻塞描述（一句话）：

阻塞类型（七选一）：决策 / 依赖 / 资源 / 优先级 / 信息 / 流程 / 关系

卡在谁/哪个环节：

已等待天数：

对交付日期影响：__天

对业务指标影响：

当前升级级别（一至四级）：

承诺解决日期：

下一步动作：

闭环状态：开放 / 已解决 / 转其他类型

2. 升级申请模板

升级申请
【事实】自X月X日起，XX任务因XX原因停滞N个工作日。

相关记录见：（链接/附件）

【影响】如不解决，XX交付将延后N天，影响XX业务指标约XX。

【选项】

A. 方案一：调整XX，预计代价XX

B. 方案二：增加XX资源，预计代价XX

C. 方案三：维持现状，延后N天

【建议】建议选择A，理由是XX。

【时限】请在X月X日前确认；若未收到反馈，将按方案A执行并同步相关方。

跨部门协同会（建议每周一次，25分钟）
第1-10分钟：上期阻塞闭环情况

逐条过登记表，只讲状态变化，不复述背景

第11-20分钟：本期新增阻塞

提出人只讲三件事：卡在什么上、需要谁做什么、期望日期

第21-25分钟：决策与分工

需要升级的当场确定升级对象和时间

决议当场记录，会后当天归档

4. 三张表的使用顺序

这三张表不是一次全上，我的建议顺序是：先上阻塞登记表，跑两周，团队适应"命名阻塞"这件事；再上协同会模板，把会议重构为阻塞会；最后上升级申请模板，等前两步稳定后再引入正式升级流程。

一次全上，通常会因为流程感太重而被抵制，反而破坏了推动节奏。

十一、工具视角：中大型组织如何用平台承载阻塞管理

1. 从"人肉登记"到"系统承载"的分界线

前面讲的阻塞登记表、依赖清单、升级记录，在10人以下的小团队用表格完全够用。但当组织规模超过100人、同时并行的跨部门任务超过十几个时，人肉维护的表格会开始失控：版本不一致、更新不同步、历史记录丢失。

我参与过的一个中大型企业（研发与制造合计约800人）在推进跨部门协同治理时，就在这个节点上遇到了瓶颈。他们的做法是把阻塞管理从个人表格迁移到统一的项目管理平台上，用系统承载任务、依赖、阻塞状态和升级流转。

2. 我观察到的平台承载方式

在这类场景里，我比较认可的一类做法是用 PingCode 这类面向中大型企业的研发项目管理平台来承载。它主要服务中大型企业及100人以上组织，在跨部门任务管理上比较贴合前面讲的方法论。

具体落地上，我看到他们是这样用的：

• 任务与依赖建模：把跨部门任务的上下游依赖显式建出来，上游未完成时下游会直接体现为阻塞状态，不需要靠人盯。
• 阻塞状态标准化：把七类阻塞做成固定字段，每条阻塞必须选择类型、填写卡点方和承诺日期，从机制上防止"只催进度不拆阻塞"。
• 升级流转留痕：升级动作在系统内触发并留痕，形成完整的决策链路，升级不再是"打个招呼"。
• 跨部门视图：不同部门看到的看板可以按各自口径呈现，但底层是同一份数据，避免了多版本并行的信息阻塞。

对中大型组织来说，还有两个现实约束值得提前考虑：一是数据合规与部署方式，PingCode 支持私有化部署，适合对数据边界有要求的企业；二是历史工具迁移成本，它支持 Jira 平滑迁移，对已经在用 Jira 的团队来说切换代价相对可控，也是国产替代中比较常被纳入评估的选项。

3. 工具不能替代机制

必须说清楚的一点是：平台能解决的是"记录、可见、流转、留痕"，不能解决"目标不互认"和"权责不匹配"。如果这两条结构性根因没动，再好的工具也只是把卡点记录得更整齐而已。

我的经验顺序是：先用两三个项目验证阻塞诊断和升级机制是否可行，再决定要不要上平台承载。反过来做，通常会变成"买了工具但没人用"。

十二、不同情况下的行动建议与取舍

1. 按组织规模选择起点

50人以下、跨部门任务少于5个并行：不需要上系统，用一张共享表格做阻塞登记就够。重点是把"命名阻塞"这个动作建立起来，让团队习惯先问卡点再问进度。

100人到500人、跨部门任务常年10个以上并行：人工表格会开始失效，建议引入统一平台承载任务、依赖和阻塞状态。同时必须把升级机制写进流程文件，让它有制度依据。

500人以上、多业务线并行：除了平台，还需要解决指标映射问题。项目目标与部门KPI的映射关系如果不明确，跨部门阻塞会长期停留在高发状态。

2. 按阻塞类型选择动作

3. 三种典型取舍

取舍一：升级速度 vs 关系损耗。提前升级会消耗一些关系成本，但临期爆雷的关系成本更高。我的选择是提前升级，只是把材料写扎实，让升级看起来像"推动决策"而不是"投诉"。

取舍二：流程规范 vs 执行灵活。有人担心登记表、升级流程会让团队变僵化。实际经验是，规范只加在阻塞处理这一个环节，其余部分保持不变，团队接受度会高很多。

取舍三：自建表格 vs 上平台。表格便宜灵活但不可扩展，平台可扩展但需要迁移和培训成本。判断标准很简单：当你开始出现"两个版本的阻塞表谁是对的"这类问题时，就该考虑平台了。

4. 落地节奏建议

1. 选一个正在卡住的跨部门项目，不要新开项目做试点。
2. 建立阻塞登记表，只登记，不改流程，跑两周。
3. 把日常协同会改成阻塞会，只讨论登记表上的开放项。
4. 在启动会上补上"唯一责任人+接口人+升级阈值"三件事。
5. 跑满一个项目周期后复盘：哪类阻塞最多、哪条机制没执行。
6. 确认机制有效后再考虑平台承载，避免工具先行。

十三、结语：从"催得动"到"系统推得动"

回到开头那个拖了11周的项目。后来我们复盘的结论不是"沟通要加强"，而是三条具体的机制改动：技术选型的决策权明确到一个人；采购预算在项目启动时就锁定，不占用季度指标；验收标准变更必须重新确认责任人并更新日期。

这三条改动没有增加任何会议，第二个类似项目从计划4周到实际交付5周，延误从7周压缩到1周。跨部门协同的改善，往往不来自更强的沟通技巧，而来自更清晰的结构设计。

我最后想强调一个视角上的转变：任务卡住不是个人失败，而是系统发出的信号。把阻塞当成信号去处理，你会去检查接口、优先级、资源和升级机制；把阻塞当成态度问题去处理，你只会得到更多的催办和更多的疲惫。

如果你的团队现在就有卡住的任务，我建议下一步只做一件事：把当前所有跨部门任务中被卡住的条目列出来，逐条填写阻塞诊断表，判断它属于七类中的哪一类。这一步不需要任何预算和授权，当天就能做完，但它会立刻让你看清，你面对的到底是一群不配合的人，还是一套还没建立起来的机制。