跨部门沟通，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
在跨部门沟通上，你有什么很好的经验吗？
