|
|
|
|
|
# 21｜跨部门沟通：怎么让不归你管的人积极配合你？
|
|
|
|
|
|
|
|
|
|
|
|
你好，我是雷蓓蓓。这一讲，我们来聊聊跨部门沟通。
|
|
|
|
|
|
|
|
|
|
|
|
作为项目管理人员，跨部门沟通是不可避免的。不过艾文对此却有点胆怯：“我们自己内部的进度，怎么着都好管。都是自己人嘛，目标都是一致的。可是，一旦涉及到跨部门合作，管起来就很困难。人家又不归我们管，不可控因素太多了。如果在合作的过程中，出现了什么问题，拿他们也没办法。针对这种情况，你说怎么办呢？”
|
|
|
|
|
|
|
|
|
|
|
|
其实，很多冲突都始于“边界”二字。比如，部门与部门之间存在边界，所以就有了“部门墙”。别看只是跨了个部门，各项沟通的复杂度就会直线上升。
|
|
|
|
|
|
|
|
|
|
|
|
为啥呢？不是“自己人”了啊。那么，我们该如何应对跨部门沟通的问题呢？我跟你分享两种方法。
|
|
|
|
|
|
|
|
|
|
|
|
* 约法三章，先说清楚。
|
|
|
|
|
|
* 打开边界，一起想办法。
|
|
|
|
|
|
|
|
|
|
|
|
## 约法三章，先说清楚
|
|
|
|
|
|
|
|
|
|
|
|
我们先来看看第一种：约法三章。既然不是自己人，那就要分清楚哪些事情该我干，哪些该你干。那么，该如何约法三章呢？
|
|
|
|
|
|
|
|
|
|
|
|
**第一步：建立君子协定**
|
|
|
|
|
|
|
|
|
|
|
|
在合作前，你要跟对方建立合约，明确**合作目标、合作事项、双方各自的需求和责任、时间进度要求、风险及责任人**。建立合约时，要由双方负责人进行邮件确认，公开做出正式的承诺。
|
|
|
|
|
|
|
|
|
|
|
|
需要注意的是，**在刚开始合作时，建立稳定的预期是关键，双方责任及进度要求，必须要得到公开确认**。否则，这些问题如果不明不白的话，就会给后续工作带来极大的隐患。
|
|
|
|
|
|
|
|
|
|
|
|
我给你分享一份合作说明书的示例文档。你可以点击[网盘链接](https://pan.baidu.com/s/1PFIvDLnvYypmF6k2XhbuJw)获取，提取码是35qw。这是某公共技术部门与某事业部达成的战略合作，里面清晰地约定了合作内容、具体需求及总体进度计划。这份文档就需要两个部门的最高领导通过邮件进行确认。
|
|
|
|
|
|
|
|
|
|
|
|
必要的时候，可以筹备、召开一个跨部门的项目启动会，邀请双方的领导层参与，通过这种正式的仪式，让合作项目成为大家共同的目标。
|
|
|
|
|
|
|
|
|
|
|
|
为什么很多公司级的战略合作都会举办一个签字仪式呢？其实，这就是因为**承诺越公开，越正式，日后对双方的约束效力就越大**。
|
|
|
|
|
|
|
|
|
|
|
|
**第二步：建立机制**
|
|
|
|
|
|
|
|
|
|
|
|
万万不要以为，签完合约就万事大吉了。
|
|
|
|
|
|
|
|
|
|
|
|
曾经，我们就遇到这样的情况：眼看着要到联调的Deadline了，对方的任务还没完成。我问了对方之后，才知道，说好的功能接口不能准时交付了。他们给出了很多原因，比如，工作比想象得复杂，还有人员休产假、离职等等。
|
|
|
|
|
|
|
|
|
|
|
|
在项目进行中，各种情况都有可能发生，只有及时获知、甚至是提前预知风险，才能让项目始终保持可控。
|
|
|
|
|
|
|
|
|
|
|
|
**合作建立之后，需要建立常规的沟通机制来持续推动**。比如，项目信息开放共享，每周在固定的时间开碰头会，双方相关人员交流工作进展及风险情况。更进一步的话，你还可以借助标准的任务管理和文档管理工具，对项目任务和文档做到统一的流程化管理，在过程中确保及时地跟进检查。
|
|
|
|
|
|
|
|
|
|
|
|
常规机制及工具搭建好之后，在运行过程中，你还需要经常自检，确认下流程上是否有疏忽的地方。比如，**是否存在“三不管”地带？每个依赖任务的职责是否明确，责任是否具体到个人？**
|
|
|
|
|
|
|
|
|
|
|
|
如果你发现了模糊地带的存在，要及时明确需要共同协作的内容是什么，该由哪个部门、哪个人负责，做到权责分明和分工合理，避免后期出现相互推诿、扯皮的情况。
|
|
|
|
|
|
|
|
|
|
|
|
**第三步：解决问题**
|
|
|
|
|
|
|
|
|
|
|
|
通过周期检查，我们可以及时发现问题。但是，如果事先约定好了，并做了周期检查，对方负责的事情还是出问题了，该怎么办呢？
|
|
|
|
|
|
|
|
|
|
|
|
有同学会说：“找他们领导！”在跨部门沟通中，打出领导牌的确会起到一定的作用，但是，这张牌属于“王炸”，不到特别时刻，不要随便拿出来用。
|
|
|
|
|
|
|
|
|
|
|
|
在找领导之前，建议你先自己摸清楚状况，**尽快启动风险应对机制，确定问题处理方案**，比如改变方案、调整时间、增加资源、减少范围等。
|
|
|
|
|
|
|
|
|
|
|
|
另外，你要把问题和相应的决议结果抄送给双方的负责人，让双方清楚问题对整体项目的影响及调整方案。同时，你还要明确的是，**今后要采取哪些预防措施，以避免问题的再次发生**。
|
|
|
|
|
|
|
|
|
|
|
|
那么，什么时候该找领导呢？
|
|
|
|
|
|
|
|
|
|
|
|
我曾经就遇到过一种情况：两边的领导已经达成了正式的约定，但是，不是每个牵涉进去的协作方都会立马配合。
|
|
|
|
|
|
|
|
|
|
|
|
原因有很多，比如，这个部门的KPI早就定义好了，目前上面的领导虽然认可了合作方案，但是没改KPI，原来的目标依然有效。对于这部分新增的工作，他们要额外投人去做。因此，他们非常担心，虽然增加了工作量，但产出却不受领导的重视。
|
|
|
|
|
|
|
|
|
|
|
|
类似这种会影响合作落地的根本机制问题，你就需要引入双方的领导，来一起研究解决方案。比如，在双方的绩效考核指标中，加入跨部门利益的指标，来强化这种目标和利益的捆绑，让双方真正把劲往一处使。
|
|
|
|
|
|
|
|
|
|
|
|
我们总结一下“约法三章式”跨部门沟通的要点。首先，在项目合作开始时，要努力争取合作部门上级领导的支持，达成明确公开的“君子协议”，建立稳定的合作预期。然后，你要建立周期检查机制和标准化的流程，而不是想起来才问一句。最后，对于执行过程中的问题，及时跟进解决，对于涉及合作机制类的问题，要及时请双方领导介入进来。
|
|
|
|
|
|
|
|
|
|
|
|
## 打开边界，一起想办法
|
|
|
|
|
|
|
|
|
|
|
|
“约法三章”，可以说是最为常见的一种跨部门沟通的应对方式。接下来，我们再来看看第二种方法：打开边界，一起想办法。尽管不是自己人，咱还是要把对方当成自己人看待，好，就一起好；出了问题，大家就一起扛。
|
|
|
|
|
|
|
|
|
|
|
|
为什么说跨部门沟通还需要打开边界呢？我给你分享一个我经历过的项目，你就明白了。
|
|
|
|
|
|
|
|
|
|
|
|
X项目是一个非常典型的跨部门、跨职能的大型项目集，项目组人员接近两百个，涉及到的跨职能小组就有12个。由于技术复杂性，各模块之间的依赖和耦合很强，再加上各业务模块都有自己的目标和优先级，跨部门沟通的成本很高。
|
|
|
|
|
|
|
|
|
|
|
|
在这样的背景下，每个业务模块都反馈说：“跨部门协调这个事，太难了。”一个很小的改进，可能就需要交互、前端、中间层、后端、各模块的测试都参与其中。即使只是组织一个会议，要想把人叫齐，都颇费周折。
|
|
|
|
|
|
|
|
|
|
|
|
这种跨部门的协作，已经融入到每一天的工作中了。这时，“约法三章”的沟通方式，显然已经不适合我们了。那怎么办呢？
|
|
|
|
|
|
|
|
|
|
|
|
**首先，要建立统一、清晰的节奏感。**
|
|
|
|
|
|
|
|
|
|
|
|
你需要结合不同业务模块的功能、相互之间的依赖关系，来为各个业务模块设计统一的交付节奏，也就是根据项目中的关键依赖，把交付时间错开排布。
|
|
|
|
|
|
|
|
|
|
|
|
比如，在X项目中，我们在每个月固定设置了四个发布窗口，分别是5号、10号、15号和20号。接着，根据这12个模块的先后依赖关系，我们把它们安排在不同的窗口进行发布。
|
|
|
|
|
|
|
|
|
|
|
|
在此之前，这些模块的发布时间都是自行定义的，现在，每月有了统一的规划和交付节奏，协同复杂度降低了很多，因为彼此之间有了稳定的交付预期和协同基准。
|
|
|
|
|
|
|
|
|
|
|
|
需要注意的是，节奏的设定没有固定模式可循，你需要在自己的情境中，尝试总结规律，并把它们固化下来。有一个指示性的指标，就是**重新设定节奏之后，如果跨部门协调的问题明显变少了，那么，当前这个节奏就是更合适的**。
|
|
|
|
|
|
|
|
|
|
|
|
**其次，想要打开边界，你还需要主动往前一步。**
|
|
|
|
|
|
|
|
|
|
|
|
对于这个项目集里的12个子业务模块来说，每个模块既可能是底层服务的用户，同时又是上层服务的依赖方，彼此互为上下游。在这样的情况下，如果没有彼此的通力合作，那就谁也做不好。
|
|
|
|
|
|
|
|
|
|
|
|
曾经，我见过两个部门的负责人来来回回地在邮件里争吵，据理力争地互怼。后来，因为实在无法直接沟通了，他们就跟我说：“给我们加个项目经理吧。”
|
|
|
|
|
|
|
|
|
|
|
|
在了解了需求之后，我发现，每个模块的日子都不好过，要么是被需求的反复弄得焦头烂额，一肚子怨气，说：“明明之前都约定好了，需求还是说变就变。我辛辛苦苦做出来了，说不用就不用，全白搭了。”要么是被频繁的依赖问题折磨得陷入“水深火热”的境地，纷纷吐槽：“底层服务又出问题，害我挨用户一顿臭骂。整天出问题，真是拿我们当小白鼠。”
|
|
|
|
|
|
|
|
|
|
|
|
不管是哪一方，每个人都盯着别人的问题，同时捂住自己的问题。像这样的情况，就算是再放10个项目经理，估计都很难从整体上改善局面。那么，该怎么办呢？
|
|
|
|
|
|
|
|
|
|
|
|
在和项目集的高层领导一起深入地剖析了现状之后，我们都认为，“头痛医头，脚痛医脚”的方式，并不是我们想要寻求的解决方案。
|
|
|
|
|
|
|
|
|
|
|
|
于是，我们在Leader层发起了一次跨部门的交流讨论，取名为“上有老，下有小”，意思是，在这个项目集生态里，各个模块是层层嵌套在一起的，每个模块都在持续建设中，还远未成熟。上面，有人要调用我的服务；下面，我要依赖另外一个服务提供底层能力。每个模块都是“上有老，下有小”，如果我们想要获得整体改善，该怎么做？
|
|
|
|
|
|
|
|
|
|
|
|
我们收集了大家的改进建议，并进行了统一整理，形成了我们所定义的“担当力模型”（如下图所示）。这个模型总共分为四层，它们分别描述了我们在遇到跨部门沟通的问题时的四种不同心态和行为。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* 第一层：放弃。这背后的心态是：“见怪不怪，反正我已经绝望了。”抱着这种心态，于是，你就什么都没做。
|
|
|
|
|
|
* 第二层；责怪。这背后的心理是：“你怎么搞的，每次都这样？”这样想着，你依然是，什么都没做。
|
|
|
|
|
|
* 第三层：完成任务。这背后的心态是：“真是不省心，下次我得特意盯着你点！”抱着这种完成任务的心态，你会针对问题做全面的排查，增强对应的监控。
|
|
|
|
|
|
* 第四层：担当。这一层的表现是：“出问题不可怕，但我们绝对不能再犯同一个错误。”你会把错误当作完善的机会，帮助用户方和依赖方共同成长。
|
|
|
|
|
|
|
|
|
|
|
|
我们把真正的担当解释为“上敬老，下爱小”。什么意思呢？上敬老，是说对于用户方，你要去主动深挖用户方的需求及业务背景，走在用户前面；下爱小，是指对于依赖方，你要全面监控、必要容错、并帮助它不断改进。
|
|
|
|
|
|
|
|
|
|
|
|
通过这次的深入讨论，我们认识到，只有各个模块都往前走一步，才能够引发系统的改善。与其去责怪对方，不如跟他一起找到合作共赢的方式，最终让所有人获益。这四层担当力模型，本质上是心态上的差异，而每次主动往前一步，最终必将体现到工作的长期效果上，从而形成持久化差异。
|
|
|
|
|
|
|
|
|
|
|
|
## 总结
|
|
|
|
|
|
|
|
|
|
|
|
今天，我介绍了跨部门沟通的两种应对之道，分别是约法三章，先说清楚，以及打开边界，一起想办法。那么，我们怎么区分什么时候该使用哪种方式呢？
|
|
|
|
|
|
|
|
|
|
|
|
答案就是，**看双方之间的依赖关系和合作性质**。如果更多是单方面依赖、单方面受益，且是一次性的合作，第一种方式会更加适合。如果是互相依赖，而且是长期合作的共生关系，那么，你就不能只考虑短期利益了。你要从长期的合作关系着眼，建立协同共荣的生态。需要注意的是，这两种方式并不一定是非此即彼的，你也可以结合起来使用。
|
|
|
|
|
|
|
|
|
|
|
|
跨部门协作之所以很难，究其根源，就在于边界所引发的“分别心”，也就是你是你，我是我。如果执着于你我之间的“界限”，必然会导致各种摩擦。也正因为这样，在跨部门合作时，你需要付出更多的努力，在保障项目推进的同时，用心经营、维护良好的合作关系。
|
|
|
|
|
|
|
|
|
|
|
|
共同目标、利益捆绑、流程约束是基础，除此之外，你还需要更加开放的心态，去找到更多合作共赢的方式，共同做大事业。
|
|
|
|
|
|
|
|
|
|
|
|
## 畅所欲言
|
|
|
|
|
|
|
|
|
|
|
|
在跨部门沟通上，你有什么很好的经验吗？
|
|
|
|
|
|
|
|
|
|
|
|
欢迎你畅所欲言，我在留言区等你，也欢迎你把文章分享给你的朋友。
|
|
|
|
|
|
|
