相较于其他互联网行业的工种，产品经理算是跨部门沟通做得相对较为频繁的一类了，每天都要和其他部门的人沟通。那么，如何进行跨部门沟通呢？需要注意什么？一起来看一下吧。
相较于互联网行业的其他工种，产品经理其实算是跨部门沟通做得相对较为频繁的一类了。因为每天都要和其他部门的人沟通，研发、设计、交付、业务、销售、售后等，那势必会容易感觉到力不从心。
你曾经有没有遇到过这些情况：
“自己火急火燎的开会沟通完之后，其他部门同学在push和解决问题上很不积极、像挤牙膏一样，但我们又不是一个部门的，可急死我了。”
“突然有个项目需要和销售部门的同学对接，找了A，A说让我找B，找了B，B又说这个不归我管、让我找C，就这样耽误了好几天进度，真的很头疼”
“我们的业务高度依赖其他部门的产品和部署，但是每一次对方都说自己也很忙、确实没时间帮我们去对接，每一次都要花极大成本去协作怎么办？”
跨部门沟通本身其实属于产品经理软技能的一部分，虽说是较为定性的软技能，但真的没什么可参考的办法、只能靠通过不断踩坑来成长吗？不是的，软技能也有其提升的方法和技巧。
那么，本文将通过以下3个小节的学习，帮助刚入门的产品新人或是在跨部门沟通过程中时常遇到阻塞的同学规避部门间沟通风险和降低沟通成本，从而与多部门同学达成共识，推进迭代和跨部门事务顺利开展。
如果你在跨部门沟通上有一些力不从心，或是经常遇到扯皮、甩锅而非常头大的情况，那一定要看下去～
在了解跨部门沟通有什么用之前，我们先来看看什么是跨部门沟通？
如上图所示，跨部门沟通=跨部门+沟通，本质上就是沟通的一类。其中，沟通其实就是信息传输的过程，可以用信息传输模型来解释，它包含了从信源到信宿的信息流向过程，其中也经历了编码、解码的过程，这是不是和我们要和另外一个人进行聊天和沟通很像？
那么，跨部门沟通则是在沟通的基础上增加了「跨部门」这样一个难度，它意味着我们在与其他部门的同学进行沟通时，势必会存在视角不同、职责不同、目标不同的天然屏障。
所以，在这样的基础之上，跨部门沟通本身确实是比较麻烦和复杂的，如果你感觉力不从心，不用太过焦虑，这是一件产品经理刚入门再正常不过的事情～
跨部门本身就意味着公司的部门和组织架构较复杂，组织架构复杂虽然从沟通角度上来说，好像是造成了天然屏障，但其架构本身对业务的开展等有其好的一面和作用，因此，我们要先尝试去理解公司多部门组织架构的存在即合理的意义，那么，我们能做的就是在这个基础上去高效的做好跨部门沟通。
那么，做好高效的跨部门沟通对我们有什么好处呢？
一是能够帮助我们提升工作效率。需要跨部门沟通就意味着我们可以借助其他部门的资源去推进一些事情，那么大家如果合作比较高效和顺畅，是不是就能够从全局上提升我们的工作效率；
二是降低迭代、项目或事务风险。人越多事情就摊的越开，也就越容易出岔子，好的跨部门沟通自然能降低各方沟通的gap，从而降低目标出岔子的概率；
三是发挥团队价值。前面我们说到了一件事如果需要跨部门沟通，那大概率是需要多个团队齐力协作的，这就像《系统架构》这本书中说的系统经过一系列运转之后，会涌现出一定的价值，那么一个组织或者团队亦然，高效的跨部门沟通能更好的发挥团队价值。
前面我们简单介绍了跨部门沟通的定义和价值，现在我们来带大家一起看看跨部门沟通的核心路径和思路应该是怎样的，这里我们将一次跨部门沟通分为了3个大步骤：沟通前、沟通中、沟通后。
在任何一次沟通之前，如何保证众多来自不同部门的人在一起沟通时，能够让决策和沟通效率最大化呢？答案很简单，那就是收集充足的信息。
我们需要先在力所能及的范围内收集充足的信息（包含背景、和资料），不限于通过提前私聊询问相关人员、公司文档库中查阅相关文档等方式，这样，无论在沟通前和沟通中，我们都能即时拿出相对较为全面的资料和信息，辅助大家快速决策。
此外，沟通前我们要做好的第2件事是——进行合理的沟通规划。
从项目管理的角度而言，沟通管理和规划本身就是十大管理的一部分，可见沟通管理的重要性。那么一次跨部门沟通也是类似的，在沟通前，我们要做到4个规划+1个文档：
4个规划指确定好会议目标、沟通时间、沟通方式（线上会议、电话、线上群聊）、参与人员，1个文档则指需要提前给相关人员提供资料和前置信息。
这里我们给出2大沟通前的常见易错点，大家可以看看自己有没有犯过类似的错误，或者遇到有身边的同事出现过这样的问题？
易错点1：
还没有提前做好充足的功课和信息拉齐，一上来就说“拉个会先过一下”，导致会上1、2个小时过去了，啥结论都没有。
正确做法：提前准备好会议资料，保证大家对会议目标都达成了一致后，再征求大家建议或者依据需沟通的内容情况决定以什么方式进行沟通。
易错点2：
开会时为了达成自己的目标，把有关系的人全部拉上、一次性讨论多个议题，导致有些人其实原本只需要参与10分钟解决一个问题、最终2个小时都耗在会上。
正确做法：
尽量一个议程解决1-2个关键问题；若确实一次会议需要解决多个问题，那提前准备好会议议程，什么时间什么人需要参与的规划提前发给大家，高效进行跨部门沟通。
OK，我们再回过头来看，当我们收集到充足的信息，也对整个沟通节奏有了提前的规划之后，就能胸有成竹的约好相关人员一并进行沟通了。
在沟通过程中，我们这里给大家介绍一个模型——GBP模型（Goal目标-Backgruond背景-Problem问题）。这个模型是什么意思呢？指我们可以通过这样的模型去开展和发起整个沟通。
下图就是GBP模型的示意，G指目标Goal、B指背景Background、P指问题Problem。
我们在开展和发起一次跨部门沟通前，需要先讲清楚目标。
前面我们提到了跨部门沟通存在目标不同、角色不同、职责不同的天然屏障，那么，一次需要跨部门协作的事务必然有一个共同的目标去驱动，所以，我们需要先开门见山地把目标甩出来，让大家拉齐目标，讲清楚后面所要讲到问题的利益共同点。
简而言之，先让大家成为一条线上的蚂蚱，这样，别人是不是才愿意主动地去帮助和参与进来呢？
接下来，我们需要用3、5句话讲清楚事务的背景，同步好当前问题的相关项目或者迭代，以及事情的重要程度等，让对方对事情有一个快速宏观的判断。最后，我们再详细的去描述当前所需解决的问题。
那么，在沟通过程中，时常会遇到的常见易错点有哪些呢？
易错点1：
为了省时间，一上来就问对方具体某一个问题，搞得对方一头雾水、或是只能针对该问题片面针对性地进行回答。
正确做法：
易错点2：
先铺垫了一大堆背景，对方听的云里雾里，半天不知道到底要做什么？
正确做法：可以仿照金字塔模型，先抛出问题/主题/目的，然后一并再阐述背景和其他内容，保证对方可以带着问题去高效理解后续内容。
那么，在会上沟通完了之后，是不是我们就结束了呢？千万记得，并不是，我们还需要善始善终、做好沟通后的收尾。
沟通过后，千万别忘了一件事：花几分钟时间整理并及时同步会议纪要。
会上已经达成了一致，会后还有必要去写会议纪要吗？有必要！
首先，一件事需要跨部门沟通，说明该问题依赖外部信息和共同决策，因此，我们需要通过纪要再次确认会上共识，同时也可以将书面的会议纪要用于留档方便追溯问题与决策。会议纪要同步的方式可以是在相关人都在的群里进行同步，甚至也可以在相关的文档中进行记录存档。
此外，一场跨部门沟通主要适用于决策和达成共识，那么同时也会产生相应的一些后续todo和行动。这时，我们也需要在沟通后明确好相应问题与进一步动作的落地跟进。
下面我们来看看，在沟通过后常见的易错点有哪些？
易错点1：
拉着一堆人沟通好几次也没能解决问题，那直接上升到自己leader处或者干脆不管了。
正确做法：不由分说地上升和听之任之都是消极解决问题的表现，可以先对内进行复盘。如果是自己沟通没处理好，那可以尝试改进后看有没有好转；如果确实是项目本身沟通复杂度问题，再考虑与leader商量如何解决。
易错点2：
重大会议会写会议纪要，小一点的跨部门沟通就直接开始做了、懒得写会议纪要。
正确做法：
会议纪要不仅可以帮助双方再次确认结论，对其他相关人来说，也能获得相关信息的同步，帮助大家工作顺利开展；同时，还能在时隔很久之后进行问题追溯时，会议纪要也会是一个有效保护自己过往工作的「证据」。
这样，通过沟通前中后3部曲的学习，能够帮助你对跨部门沟通有一个相对清晰的路径和思路。但学到这里，可能有些同学还有一些具体的问题需要具体对待，那么下一节，我们来看看沟通过程中，具体会有哪些常见问题及对应的解决办法。
Q1：火急火燎地开会沟通完之后，其他部门同学在push和解决问题上很不积极，我们又不是一个部门的，该怎么去push他呢？
第一步，做好自己该做的。遇到push不动的情况，先自我反思——是否已经做好了自己该做的，先内省再push他人。
第二步，借助其他角色。若自己已经努力想尽办法都无效，那可以在必要时适当借助中间角色（如项目经理）、上升一级的角色（如自己的leader）或者对这个事情需求最紧急的角色（如销售/售前）去进一步push。
Q2：突然有个项目需要和其他部门对接，找了A，A说让我找B，找了B，B又说这个不归我管、让我找C，就这样耽误了好几天进度，真的很头疼！
若问题为中低优：先按照GBP模型客观描述清楚问题，让对方根据问题判断后，提供一个较为全面的各个模块对接人清单或是统一的对接人；后续可以push该部门预先准备一个较为全面的对接人清单，方便快速沟通；
若问题为高优且很紧急：可以考虑上升给自己的leader，由leader去对接对方部门的leader，从而提供指定接口人，快速处理问题；但切记，该方法要慎用和少用。
Q3：我们的业务高度依赖其他部门的产品和部署，但是每一次对方都说自己也很忙、确实没时间帮我们去对接，每一次都要花极大成本去协作怎么办？
1）短期处理
如果问题高优且紧急，那可以考虑：
2）长期处理
主动push被依赖部门能够逐渐补全相关文档和对接资源，能用文档解决的尽量避免对方派人专项参与，互相提升效率。
以上简单列举了常见的3类问题，当然工作中其实还会遇到非常多的问题，很难一次性归纳在常见Q&A中，如果你有解决不了的跨部门沟通问题都可以甩在评论区，看是否能够给你一些建议。
虽然不能解决全部的问题，但以上Q&A中的思路也是值得我们去借鉴的，即先对问题进行分析，分析后先进行自我反省和主动寻找解决办法，实在尝试无效后，再去尝试借助其他资源的力量进行解决。
OK，以上就是本文的全部内容，我们讲了跨部门沟通的价值、跨部门沟通前中后三部曲、以及3个常见的跨部门Q&A，希望大家在读完本文后能够有一些收获，同时在不断的磨练和踩坑后能够在跨部门沟通中游刃有余，一切尽在掌握！
另，如果你有遇到一些跨部门沟通中很无语或者很有趣的经历，欢迎在评论区交流呀。
专栏作家
冰冰酱；公众号：冰冰酱啊，人人都是产品经理专栏作家。5年产品经验，创过业、带过人、踩过坑；独立负责从0-1搭建业务中台，持续深耕B端及SaaS领域。
本文原创发布于人人都是产品经理，未经许可，不得转载。
题图来自 Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。