普林斯顿大学有一项研究说啊，一个人的成功，只有25%受“智商”、“专业技术”和“经验”的影响，其余75%是和良好的人际沟通有关系的。最近，“互联网er的早读课”发了一篇文章提到，好的运营不仅要有创意、有执行力、有方法论，关键还得会沟通。那么，运营该怎么样与平时打交道最多的产品、设计和技术做好沟通呢？
首先是怎么与产品岗位良好沟通。运营和产品听着有点像天生的一对儿冤家，在现实中这两个岗位有时候还真是互相看不顺眼。要么是运营埋怨产品功能做的差，要么是产品说运营只会搞些虚头巴脑的事儿。宝贵的时间就这么被浪费在互相扯皮上，实质的问题一个也没解决。那么，和产品岗位沟通需要掌握哪些小窍门呢？
第一是用同频道的语言沟通。运营的主要工作是做内容、写策划书、写PPT什么的，产品的主要工作是用户需求分析、竞品功能分析、写需求文档、画原型图什么的，工作内容上有很多不一样。如果双方都用自己熟悉的方式沟通，那最后就是鸡同鸭讲，谁也听不进去对方说的话，效率就会大打折扣。所以，运营在和产品沟通的时候，可以先写一份产品需求文档，用产品人员熟悉的方式去沟通，他们就肯定会放下抵触心理。
第二，告知收益，不邀功。产品关心的收益无非就是，用户数量和数据增长这两点，它们会直接影响用户的成就感和积极性。所以，运营人员的项目要是直接复用了产品的某个功能，就可以在立项的时候，直接点名感谢这个产品经理的功能支持，让产品人员感到满足。
第三，虚心学习，不耍情绪。运营一般擅长想创意和点子，产品却偏向逻辑。有的运营能自己应付一些小项目，独立完成产品需求文档，但千万不要因为这个就自恃过高，时不时地还抖个机灵什么的，还是要好好虚心地学习，毕竟这是人家产品岗位的看家本领。
第四，借力领导，不冲突。运营有的时候需要进行跨部门沟通，如果自己实在解决不了了，可以请求领导支援。比如说，在发邮件的时候抄送部门领导。要注意的是啊，借力领导必须提前让领导知道有这么个事，才好让他们指导你接下来该怎么做。
第二个要解决的问题是，怎么与设计进行良好沟通。在这个看脸的时代，产品的美观度对项目数据的影响有多大，大家心里应该都有杆秤。
第一，提前参与，有效设计。运营在功能设计初期就可以邀请设计加入，一是在设计上他们是专业的，也许能带来更多想法；二是让设计提前参与，可以节省时间，不用去重复解释原型图里，每个按钮的交互是啥样的，让大家更能换位思考，提高效率。
第二，迂回说服，给予肯定。虽然孔子说过“三人行，必有我师”，但如果我们问设计师最讨厌什么，那么其中有一条肯定就是，人人都在有意无意地当他们的老师，对他们指手画脚。所以，运营表达自己设计意见的时候，应该更婉转一些，并及时对设计的专业能力给予肯定。
第三，群组沟通，进度互通。如果运营只把自己当成产品、设计、技术各方之间的传话筒，不仅会把自己累死，还会造成各方之间的信息不同，让大家理解不了对方的想法。所以，群组沟通是个不错的办法。现在大家基本都是手机不离手，QQ、微信拉个群就能把这事干了，那干嘛放着不用呢？
最后是怎么与技术进行良好沟通。产品最后是否能完美呈现，技术这关也很关键。运营肯定也不想自己像个跟屁虫似得天天追着技术问排期、测bug什么的。那么，怎么和技术沟通呢？
首先，充分说明，调动积极性。虽然程序员都很有自嘲精神，笑称自己是码农。但你可千万别真以为他们只会写代码，其实他们都很有想法。所以，要让他们彻底了解产品，了解你要做什么以及为什么要做这个，当这帮极客搞清楚你需求的来龙去脉的时候，他们会从专业的角度给你提出更好的解决方案。
其次，明确需求，别轻易改动。运营由于工作琐碎，养成了他们比较活跃、发散的思维，但这也是运营和技术沟通中的一大障碍。你想啊，假如你是技术人员，正开发产品呢，运营那边想一出是一出，一会改下这，一会又改下那，你是不是也得被逼疯。所以，运营给技术的开发文档和页面都尽量给最终版，否则，你就只能眼巴巴地看着自己项目的排期被其他项目挤掉。
最后，模块沟通，让问题沉淀。尽量不要在技术人员写代码的时候，让他不停地修改。因为，技术人员的工作基本都是单进程的，为了提高单位时间写代码的效率，他们会自行开启飞行模式，你在这个时候打断他们，他们的研发思路就会中断，这绝对会让他们抓狂。所以，作为运营，在与技术人员沟通的时候，需要将问题先收集汇总在一起，并确定优先级和排期，然后再定期和他们沟通。
上面讲到的就是运营与产品、设计和技术之间的沟通宝典，尽管这些方法具有参考价值，但并不表示它们都是放之四海而皆准的真理。因为，最好的沟通合作方式是，实现所有参与者的共赢。
