写在前面：
“抖腿”App V3.0 的研发迭代已经开始了三天。 早会上，后端老张略带疲惫地打了个哈欠：“我这边的接口逻辑都写完了，正等着前端小王接。但小王说 UI 小美还没把视觉稿传到蓝湖上，他没法切图。”
在项目管理里，有一类“卡点”特别让人无力。
需求已经评审完了，
技术方案也定了，
研发排期排得明明白白，
UI 说：“我这周排满了，下周再给你图。”
市场说：“推广物料还在讨论方向，先等等。”
研发开始出现一种诡异状态：“人坐在工位上，但项目实际上动不了。”
作为 项目经理，你发现自己成了“催单员”：
- 催 UI：快点出图，研发等着呢。
- 催研发：别闲着，先做点别的。
- 催运营：物料在做了，再等等。
这种 “串行依赖”（A等B，B等C）完全违背了敏捷的初衷。
更糟的是，
几天后老板问你一句：
“你这个项目，为什么又慢了？”
你很清楚不是研发不干活，
但你也同样清楚——
“UI 没给图、市场没给物料”这种理由，说出口是没分量的。
一、跨部门协作失效，本质不是“谁不配合”
很多项目经理一遇到这种情况，下意识会归因成：
- UI 不重视
- 市场不配合
- 对方部门优先级低
- 大家没有“项目意识”
但你在职场待得越久，就越会发现一个残酷现实：
跨部门协作失败，90% 不是态度问题，而是结构问题。
我们先拆几个“常见错觉”。
错觉一：大家目标是一致的
这是项目管理里最致命的幻觉。
在你眼里：
- 项目延期 = 你背锅
- 研发闲着 = 资源浪费
但在对方部门眼里：
- UI 的 KPI 是设计质量和品牌一致性
- 市场的 KPI 是转化率、曝光、节点
你的项目，只是他们任务池里的一个普通任务。
你急，不等于他们必须急。
错觉二：提前说过 ≠ 对方就会按时交付
很多项目经理会说：
“我在需求评审时已经说清楚时间节点了。”
问题是：
你说清楚了，不代表对方“认账了”。
尤其是在跨部门场景下：
- 没在对方的排期系统里
- 没进对方的 OKR / KPI
- 没明确负责人
这种“口头确认”，在现实中几乎等于没有。
错觉三：等，是最省事的做法
当 UI 图没出、物料没给时，很多项目经理会选择：
- “那研发先等等吧”
- “反正现在也做不了”
这在短期看似合理，
但在中长期，会产生非常可怕的副作用：
- 研发对项目经理的节奏信任下降
- 项目整体变成“被动等待型”
- 一旦资源紧张，项目直接被挤出优先级
等，是最隐蔽的节奏杀手。
二、研发“闲着等”，其实是管理失职信号
这句话可能不太好听，但很真实：
当研发出现大面积“等 UI / 等市场”的情况，说明项目管理已经失控。
注意，不是指你能力差，而是说明：
- 依赖关系没被提前拆解
- 风险没被前置暴露
- 协作机制是“临时凑的”
敏捷不是让大家跑得快，
而是让阻塞尽早暴露、尽早处理。
三、真正可落地的 4 种破局方式
下面讲的，不是“理想状态”，而是在资源有限、权责不对等的情况下，PM 还能做什么。
1️⃣ 把“依赖”显性化，而不是藏在甘特图里
很多项目计划表里，只写：
- 前端开发：5 天
- 后端开发：7 天
但没有写：
- 依赖 UI 最终稿
- 依赖推广物料文案确认
结果是：
计划看起来很美，实际一动就卡。
正确做法是：
在项目拆解时，明确标注：
- 阶段性依赖项
- 依赖部门
- 最晚交付时间
- 风险等级（高 / 中 / 低）
并且——
让这些依赖对所有干系人可见。
2️⃣ 不要等“完整交付”，先要“可用输入”
这是很多 PM 的认知升级点。
你真正需要的，往往不是：
- 最终 UI 图
- 全量推广物料
而是：
- 关键页面结构
- 核心文案方向
你可以这样沟通：
“不是要最终稿，我需要一个能让研发先跑起来的版本。”
一旦研发能动起来：
- 节奏就保住了
- 风险被前移
- 等正式稿出来，只是替换而不是重做
3️⃣ 用“研发成本”换“协作优先级”
跨部门协作里，有一个非常现实的杠杆：
研发资源，是最有分量的筹码。
当你只是说：
- “这个项目很急”
对方可能无感。
但当你说清楚：
- “目前 3 个研发在等这个输入”
- “如果今天不给，后面会整体延期 X 天”
这不是甩锅，而是把成本显性化。
很多协作问题，不是对方不愿意帮，
而是他们根本不知道你这边已经“在烧钱”。
4️⃣ 留“缓冲”，不是浪费，而是对现实的尊重
很多项目经理不敢留缓冲，是怕被说：
- 排期保守
- 效率不高
但在跨部门项目里，零缓冲 = 默认延期。
真正成熟的做法是：
- 在计划中明确“协作缓冲区”
- 只对核心里程碑承诺
- 把不确定性写进风险说明
这不是消极，而是专业。
四、别把跨部门协作，当成“人情管理”
很多项目经理最后会陷入一个误区：
- 到处求人
- 私下协调
- 用关系补制度
短期有效，长期极其危险。
因为一旦：
- 人变了
- 关系断了
- 组织调整了
项目直接失去支撑。
真正可靠的，是机制，而不是情分。
五、真实项目场景
在“抖腿”App V3.0 的研发迭代中：
- UI 延期 5 天
- 市场物料迟迟未定
你不要选择等，而是去做三件事：
- 让研发先基于低保真原型实现核心流程
- 把“3 人等待成本”同步给市场负责人
- 在周会上公开风险节点，而不是私下抱怨
结果可能会是：
- UI 给了阶段稿
- 市场优先确认了核心文案
- 项目整体只延期 1 天，而不是 1 周
不是因为大家突然变配合了，
而是因为——
阻塞被提前、被量化、被看见了。
六、总结一下
我认为跨部门协作真正的难点，不在于“别人不配合”，而在于项目管理是否把不确定性前移、把成本说清、把依赖管住。
当你看到：
- UI 图迟迟未出
- 物料一拖再拖
- 研发开始“闲着等”
那不是某个人的问题，
而是一个清晰信号：
项目的节奏，需要你重新设计了。
【第23讲·思考】
场景回顾： 因为 UI 小美家里有急事请假，V3.0 剩下的三张核心视觉稿彻底卡住了。研发小王说：“没这几张图，我这个模块完全没法写，这周我打算请假去考驾照了。”
请思考并回答：
- 反思题： 既然已经发生了“单点依赖”（只有小美会画这几张图），说明我们在风险管理上犯了什么错？
- 行动题： 作为项目经理，面对小王想请假和 UI 缺席的局面，你如何利用 “Pairing (配对)” 或 “T型人才” 的思维，在不延期的情况下渡过难关？（提示：以前做过类似的 UI 吗？前端能不能先用组件库顶上？）
