跨部门沟通，Edge对此有点胆怯：“我们自己内部进度，怎么着都好管。都是自己人，目标一致。可涉及跨部门合作，管起来就困难。人家又不归我们管，不可控因素太多了。如果在合作的过程中，出现啥问题，拿他们也没法。咋办啊？”

跨个部门，各项沟通复杂度就会剧增。只因不是“自己人”。应对跨部门沟通：

• 约法三章，先说清楚
• 打开边界，一起想办法

1 约法三章，先说清楚

最常见的跨部门沟通方式。

既然不是自己人，就要分清哪些事情我干，哪些你干。

如何约呢？

1.1 第一步：建立君子协定

合作前，跟对方建立合约，明确：

• 合作目标
• 合作事项
• 双方各自的需求和责任
• 时间进度要求
• 风险及责任人

建立合约时，要由双方负责人进行邮件确认，公开做正式承诺。

刚开始合作时，建立稳定的预期是关键，双方责任及进度要求，须得到公开确认。否则，这些问题若不明不白，就会给后续工作带来极大隐患。

合作说明书的示例文档在我的公众后台领取。这是某公共技术部门与某事业部达成的战略合作，里面清晰地约定合作内容、具体需求及总体进度计划。这份文档就需两部门最高领导通过邮件确认。

必要时，可筹备、召开一个跨部门项目启动会，邀请双方领导层参与，通过这种正式仪式，让合作项目成为大家共同目标。

为何很多公司级战略合作都会举办一个签字仪式？因为 承诺越公开，越正式，日后对双方的约束效力就越大。

1.2 第二步：建立机制

别以为签完合约万事大吉。曾经眼看要到联调Deadline，对方任务还没完成。我问对方才知道，说好的功能接口不能准时交付。他们给出很多原因，如工作比想象复杂，还有人员休产假、离职等。

项目进行各种情况都可能发生，只有及时获知、甚至提前预知风险，才能让项目始终保持可控。

合作建立后，需建立常规的沟通机制持续推动。如项目信息开放共享，每周在固定时间开碰头会，双方相关人员交流工作进展及风险情况。更进一步，你还可借助标准的任务管理和文档管理工具，对项目任务和文档做到统一流程化管理，在过程中确保及时跟进检查。

常规机制及工具搭建好后，运行过程中，你还要经常自检，确认流程是否有疏忽。如 是否存在“三不管”地带？每个依赖任务的职责是否明确，责任是否具体到个人？

如果你发现了模糊地带，要及时明确需要共同协作的内容，该由哪个部门、哪个人负责，做到权责分明和分工合理，避免后期出现相互推诿、扯皮。

1.3 第三步：解决问题

通过周期检查，我们可及时发现问题。但若事先约定好了，并做周期检查，对方负责的事情还是出问题，咋办？

“找他们领导！”在跨部门沟通中，打领导牌确会起到一定作用，但这张牌属“王炸”，不到特别时刻，不要随便用。

找领导前，建议先自己摸清状况， 尽快启动风险应对机制，确定问题处理方案，如改变方案、调整时间、增加资源、减少范围等。

另外，要把问题和相应的决议结果抄送给双方负责人，让双方清楚问题对整体项目的影响及调整方案。同时，明确 今后要采取哪些预防措施，以避免问题的再次发生。

那啥时该找领导呢？我曾经就遇到过一种情况：两边的领导已经达成了正式的约定，但是，不是每个牵涉进去的协作方都会立马配合。

原因有很多，比如，这个部门的KPI早就定义好了，目前上面的领导虽然认可了合作方案，但是没改KPI，原来的目标依然有效。对于这部分新增的工作，他们要额外投人去做。因此，他们非常担心，虽然增加了工作量，但产出却不受领导的重视。

类似这种影响合作落地的根本机制问题，你就需要引入双方领导一起研究解决方案。如在双方绩效考核指标中，加入跨部门利益的指标，强化这种目标和利益的捆绑，让双方真把劲一处使。

总结“约法三章式”跨部门沟通要点：

• 首先，在项目合作开始时，要努力争取合作部门上级领导的支持，达成明确公开的“君子协议”，建立稳定的合作预期
• 然后，建立周期检查机制和标准化的流程，而不是想起来才问句
• 最后，对执行过程中的问题，及时跟进解决，对涉及合作机制类的问题，及时请双方领导介入

2 打开边界，一起想办法

尽管不是自己人，咱还是要把对方当成自己人看待，好，就一起好；出问题，一起扛。

为何跨部门沟通还要打开边界？

X项目是典型跨部门、跨职能大型项目集，项目组人员接近200，涉及跨职能小组12个。由于技术复杂性，各模块依赖和耦合强，各业务模块都有自己的目标和优先级，跨部门沟通成本很高。

每个业务模块都反馈：“跨部门协调太难。”一个很小改进，可能就要交互、前端、中间层、后端、各模块的测试都参与。即使只是组织一个会议，要想把人叫齐都颇周折。

这种跨部门协作已融入每天工作。这时，“约法三章”显然已不适合。

首先

2.1 建立统一、清晰的节奏感

结合不同业务模块功能、相互之间依赖关系，为各业务模块设计统一交付节奏，即根据项目的关键依赖，把交付时间错开排布。

X项目我们在每月固定设置四个发布窗口：5、10、15和20号。根据这12个模块先后依赖关系，把它们安排在不同窗口发布。

此前，这些模块的发布时间都是自行定义，现在，每月有统一规划和交付节奏，协同复杂度降低很多，因为彼此有稳定的交付预期和协同基准。

节奏设定无固定模式可循，你要在自己的情境尝试总结规律，并把它们固化。有个指示性指标：重新设定节奏后，若跨部门协调问题明显变少，当前节奏就更合适。

其次，想要打开边界，你还需要

2.2 主动往前一步

对这项目集的12个子业务模块，每个模块既可能是底层服务的用户，同时又是上层服务的依赖方，互为上下游。若没有彼此通力合作，谁也做不好。

某两部门负责人来回邮件争吵，据理力争互怼。后来，因实在无法直接沟通，他们和我说：“加个项目经理吧。”

了解需求后，我发现，每个模块的日子都不好过：

• 被需求反复弄得焦头烂额，一肚怨气“明明之前都约定好了，需求还是说变就变。我辛辛苦苦做出来，说不用就不用，全白搭。”
• 被频繁依赖问题折磨陷“水深火热”“底层服务又出问题，害我挨用户一顿臭骂。整天出问题，真是拿我们当小白鼠。”

不管哪方，每人都盯着别人的问题，同时捂住自己的问题。这就再放10个项目经理，估计都难从整体改善局面。怎么办？

在和项目集的高层领导一起深入剖析现状后，都认为“头痛医头，脚痛医脚”不是我们想寻求的解决方案。

于是，我们在Leader层发起一次跨部门交流讨论，取名“上有老，下有小”，在这个项目集生态里，各模块是层层嵌套在一起，每个模块都在持续建设，还远未成熟。上面，有人要调用我的服务；下面，我要依赖另外一个服务提供底层能力。每个模块都“上有老，下有小”，想获得整体改善，怎么做？

收集了大家改进建议，并统一整理，形成我们所定义的“担当力模型”。这个模型总共分为四层，它们分别描述遇到跨部门沟通的问题时的四种不同心态和行为：

• 第一层：放弃。“见怪不怪，反正我已经绝望了。”抱着这种心态，于是，你就什么都没做
• 第二层；责怪。“你怎么搞的，每次都这样？”这样想着，你依然是，什么都没做
• 第三层：完成任务。“真是不省心，下次我得特意盯着你点！”抱着这种完成任务的心态，你会针对问题做全面排查，增强对应监控
• 第四层：担当。“出问题不可怕，但我们绝对不能再犯同一错误。”你会把错误当作完善的机会，帮助用户方和依赖方共同成长

真正的担当解释为“上敬老，下爱小”：

• 上敬老，对用户方，你要去主动深挖用户方的需求及业务背景，走在用户前面
• 下爱小，对依赖方，你要全面监控、必要容错、并帮助它不断改进。

只有各模块都往前走一步，才能引发系统改善。与其责怪对方，不如跟他一起找到合作共赢方式，最终让所有人获益。这四层担当力模型，本质是心态差异，而每次主动往前一步，最终必将体现到工作的长期效果上，从而形成持久化差异。

总结

何时该使用哪种方式呢？看双方之间的依赖关系和合作性质。

• 若更多是单方依赖、单方受益，且是一次性合作，第一种更适合
• 若互相依赖，且长期合作的共生关系，就不能只考虑短期利益。要从长期合作关系着眼，建立协同共荣生态

这两种方式并不一定是非此即彼的，也可结合使用。

跨部门协作难在边界所引发的“分别心”，你是你，我是我。若执着你我之间“界限”，必导致摩擦。也正因如此，跨部门合作时，你要付出更多努力，保障项目推进同时，用心经营、维护良好合作关系。

共同目标、利益捆绑、流程约束是基础，除此之外，你还需要更加开放的心态，去找到更多合作共赢的方式，共同做大事业。

FAQ

在跨部门沟通上，你有什么很好的经验吗？