每个公司里基本都会有一个类似同事老王一样神的存在，他们非管理层但是说话分量很足，很有群体公信力，仔细分析，都能挖掘出这三点：自信、专业、理性。当然这里会有一个误区，对于工作性沟通，不是为人和善、亲和力十足就是好的沟通基础，专业性和理性才是更重要的，也就是形成个人职业公信力。一个人的公信力不是一朝一夕就能培养出来的，需要不断提高自己的专业性，如工作方法优化和对工作细节的重视，始终保持自信、理性的态度，一点点累积，最终构建自己的信任防火墙。从心理层面来说，大家在心里都会对别人形成一个信任打分机制，而如果专业性等不足，慢慢做减法，会导致最后说什么都很难获取对方的信任，这种时候的沟通成本都是高昂的，再谈什么沟通技巧都是砍柴不磨刀式的挣扎。
沟通过程其实是一个理解、分析、表达的递进过程，任何一个环节的问题都可能导致沟通不到位。关于分析，跟个人的思维模式关系紧密，之前文章有提过，此篇不展开。主要来讨论下理解、表达，很多人没有将两者区分开，当做一个笼统的沟通问题。就拿我自己而言，我是一个理解能力强于表达能力的人。理解过程是个静态过程，偏向于思维，需要细心分析；表达过程是个动态过程，还要有比较好的临场能力。表达过程可以运用演绎和归纳推理，理解主要是运用演绎推理，这里的拓展理解可以参照《金字塔原理》表达的逻辑。
在沟通的时候，一定是先细心去理解再采取高效的方法来表达，我们经常会犯自己还没理解透彻就开始急于表达的错误，或者是表达不到位、表达过于啰嗦导致对方理解成本很高的问题。
当你在理解的时候，你用的完全是自己的思维；但是当你去表达的时候，你就要学会去考虑对方习惯的思维，表达的时候其实是一个吸收再创造的过程。
例如，我们在沟通需求的时候，有些炫技派产品经理习惯去讲一些专业性的词语，觉得口语化、或者用一些很接地气易懂的比喻都是体现不出专业性、不够逼格的表现；或者说话啰嗦，说了5min没有重点的内容还没讲到结论，直接将沟通对象的热情扼杀在摇篮，这些都属于没有采取最简单易懂的表达方式。
“if you can’t explain it simply，you don’t understand it well enough”，这是爱因斯坦很早提出来的结论，就是说明炫技没什么厉害的，重复啰嗦可能是自己都没搞懂，讲得谁都能懂才是真厉害。很著名的费曼技巧也表达了同样的意思：判断自己是否已经掌握一个知识点，就看你能否将它解释给一个10岁的小孩并让他听懂。
产品经理要面向不同的人群，并且他们由于自己的专业性限制导致的思维模式、理解模式都有一定的倾向性。所以我们需要迎合各个人群的专业语境，以“定制化”的方式沟通，能增加友好度，降低沟通成本甚至争取到有利资源。
比如我们要跟老板过需求的时候，这个时候，好好想想老板这个人群的特点：相对傲娇、商业导向、没啥耐心（当然是对下属的时候，对投资人都笑的像花儿一样灿烂）。既然这样子的话，老板好这句话之后的第一句话要高度概括你的需求目的，下一句话高度概括你的需求大概流程…当然，最多三句话不能再多了。然后接下来，展开描述的时候，要始终落脚点是能吸引新用户、增加数据流、提高订单成交量等等跟平台交易、投融资数据有关的点上。表述的时候，要客观理性，通过已有事实和基本规则逐条分析各种方案的优缺点，以供老板大人选择。另外，在这种时候，除了语言沟通，还有原型也是一个重要的表达媒介，这个时候的原型最好是高保真，这里的高保真不仅是UI、交互完善，填充内容也要尽量场景化，能体现出当前定位的数据；例如我们要做一个网红教练的拍卖系统，通过网红私教个性化物品拍卖来促进用户和私教在平台的互动，这个时候的商品选择如果是私教的签名训练服、获奖纪念物品boss们就更容易对号入座了。
同样地道理，当面对开发、面对UI时，也要根据他们的工作性质，来选择跟他们对话的方式。比如，开发小哥哥们长期习惯使用机器语言，因此我们的沟通也要尽量严密、高逻辑性，总的原则就是调理清晰、简单粗暴。并且尽量避免感性沟通，因为大部分开发同学说话方式就是直来直去，要习惯这种语境，也不必为此生气。
抓取沟通对象岗位职责所关注的点来沟通，才能更顺畅，例如你跟公司视频业务方一直强调你的前端呈现要做弹幕、扫码留言等交互，用户体验多么友好酷炫，人家听不进去，直接画重点告诉人家视频拍摄的调性、主题分类、讲解配音要求才是真爱。
对于产品经理来说，我们日常沟通的同事总的来分，就是我们的上游、下游和同级的产品同事。这个时候抓住他们相对于你而言所处的位置的独特心态，面向对象式、针对性精准沟通。
《原则》里讲到：封闭的人时常打断别人发言，开放的人则善于倾听和引导对方发言；封闭的人常说，“我可能错了，但是我认为……”，开放的人知道何时陈述，何时提问；封闭的人不喜欢被挑战，开放的人永远保持好奇。大部分人都是建立有强大的自我防御机制的，不管是生理还是心理层面。对别人的言论尤其是异见，会保持高度的警惕、甚至抵触情绪。良性循环的沟通就是要克服这种本性，以开放性心态去沟通，不要为了反对而反对，为了赞成而赞成。
每个人对一件事基于自己的认知都会持有一个观点，但是在之后的沟通碰撞过程，需要我们开放性心态，认真思考，然后及时调整自己的观点。
而封闭心态的人往往有两种特性，一是固执，二是过于自我。
曾经的一位产品同事，逻辑思维、分析能力都很好，但是具备以上两种特性。最后大家每次跟他的沟通都会变成他为了反对而反对，因为封闭心态完全听不进去别人的话；而假若开始是赞成的，后面就变成为了赞成而赞成，因为他要艰难地维持自以为的那份话语权。因为总是这种沟通方式跟技术同学沟通，让大家感觉工作效率低，被开发部门的CTO约谈了几次，最后的结果肯定是不太好的…
刻意练习自己的空杯心态，尝试着认真倾听并消化对方的话，特别对于之前存在沟通问题的同事。我曾经在很长一段时间由于沟通问题情绪低迷，后来尝试保持这种开放性心态来沟通，又对一些之前沟通不顺畅的同事有了新的认识，并且也学到了来自这些异见视角的新东西。
想清楚再说话：
曾经跟几个同行朋友讨论过工作时候的沟通问题，大家一致很反感那种你刚讲完，就开始发表自己专业见解的人，因为这是不尊重别人和个人表现欲过盛的体现。大家应该会碰到讨论工作的时候，还没等别人把话说完，就赶紧说no或者yes的同事，特别是很年轻的团队。这个坏习惯，第一就是最基本的社交礼仪都没有做到。还有更大的坏处，因为情绪驱动，导致还没有想清楚就开始说话，也就是所得结论很可能是主观惯性思维下的产物。
甚至很多时候，当沟通过程突然出现了一个新的问题，难以一下子想到解决方案或者覆盖齐全所有场景，就应该直接跟大家说明情况，表示需要更多的思考时间，总之一定要是想清楚再说话。不要为了面子，为了表现自己的专业性和敏捷，给出一个不成熟的结论然后事后又不得不打脸。相信很多人会有这种体验，在慢慢成长为一个成熟的职场人过程中，是应该逐渐杜绝这种情况的发生。
有依据再沟通：
对于一个属于资源争取性质的沟通会议，最好提前收集好相关依据，会极大提高沟通效率。因为对于产品经理来说，我们平时要沟通的大部分都是其他岗位同事，大家之间就会存在专业认知上的沟鸿，这个时候直接拿出相关数据、线上的实例来佐证自己的观点，更容易说服对方。由于这种职业沟鸿限制，太理论或者抽象地讲道理，对方其实很难跟你共鸣。
及时沟通：
及时沟通是指当你疑惑的地方，或者因为个人思维局限性、专业局限性考虑不全的地方，一定要及时找到相关人员沟通。听起来像是讲了一句废话，但是仔细想一想，其实很多人不能100%执行这件事。
第一种，因为大部分人是有鸵鸟心态的，特别是沟通对象是你的上级甚至老板的时候，这个时候大家的小忧虑就出来了，担心说错话表现不好等等。对于互联网从业者的工作都是时效性很强的，在你这纠结中很可能就错过了某个时间节点。
还有一种就是有疑惑的时候，根据常识或惯性思维猜测，不去找到相关的人员确认就开始往下进行，可能是小问题很难被发现，但是这个时候很容易埋下隐患。
提前沟通：
当预估到沟通成本会比较高时，在正式评审会议或者需求讨论会之前，提前沟通会很有帮助。提前跟话语权高的人私下沟通，对方会因为你的特殊对待而产生好感，并且此时沟通的发挥空间比较大，很容易获得认同，然后在公开讨论时，由于这种KOL的引导和群体效应，就比较容易获得广泛性的认同。
我们可能会经常碰到这样的沟通局面,就是两边意见分歧，并且谁也说服不了谁（当然万一不行，只能睡服啦）。这个时候双方都观点明确，大家都为了证明自己是对的毫不妥协，沟通很容易变成情绪拉锯战。所以像前面提到的保持自己的开放性心态，采用迂回战术，在两者之间找到平衡，结果并不是非黑即白，非A就是B的。
例如，我们有一次在首页卡片式横划区需要做划完9张直接跳转更多页面的功能，开发同学坚持既然卡片的标题行能跳转，这个功能就没有意义。我们从各个角度讲了他的交互意义，似乎对方都不买账。其实这个时候并不是对方多么不能理解它在产品层面的意义，问题的根源是整个开发周期比较紧张，这个功能对于他们来说只是体验优化层面的功能，性价比不高，因此他们这个时候的沟通是带着“找茬”的心态。后来我们及时跳脱出来，通过引导大家讨论它的开发周期跟项目周期，并且提出最后处理这个地方，如果那个时候开发还有充裕时间，就完成这个功能，如果没有，就下一期，这么一说大家就比较能接受了。并且既然是相互理解的基础上，也不会存在为了不做这个功能故意拖延。
我们在沟通的时候，只要不是原则性问题，都能采用迂回战略，跳脱出顽固的二维思维，仔细想想，好像确实不是非要采用A,或者采用B…
透过现象看本质，产品经理这个岗位就是一个万能型的翻译者，翻译自己、翻译市场、翻译业务方、运营、老板、翻译用户、翻译开发…作为一个在团队里上传下达或平行沟通的高密度的信息源，除按照上述方法保证信息传递的高效外，还要保证信息传递的对称，这个对称就是及时的、全面的信息到达。此时产品经理扮演的角色就带有项目管理的性质，保证这个需求从规划到开发落地阶段的信息对称，能够避免返工、无用功等情况。
例如，需求规划的时候要考虑是否牵扯其他业务线或者可复用、可合并的地方，这个时候要及时沟通到其他业务方和负责的产品；需求落地开发的时候，需求、UI变动、前、后置条件、入口等地方的关联模块，以及引用公共模块需求、复用老需求，都要及时了解清楚相关内容，保证信息的对称，以免漏掉隐形坑。
关于这一点，我自己得做法就是需求文档里，在全局说明中列举出所有关联内容，能起到梳理思路并提醒自己、开发、测试同事的作用。
1、避免关于细节或者A∕B测试类问题的长时间沟通拉锯战
过久的讨论一个问题点，容易消耗个人的理性，被感性带偏，从而导致沟通的低效，而且很多细节问题是不值得花费过多时间去研究，并且像A∕B测试类的问题没有对错之分，就像争论先有鸡还是先有鸡蛋一样没有结果。
2、给予认真付出的同事以肯定
我们都知道一个项目的进行过程中，不可控因素太多，是一场耐力战，并且最终结果可能是无法上线、上线效果不好等等，所以对于认真付出的同事，及时给予肯定，也是同事之间同理心的表现。
3、一个好产品是要有一套全家桶表情包的
如果你真的无法说服TA，可能是缺了一套表情包吧，哈哈，至于原因，大家都懂得，我就不多说了…
后记：在做产品之前，我一直自我定位为一个沟通能力很强的人，甚至这一点是我入行前认为自己做产品最大的优势，因为以前是个随便就洋洋洒洒几万字的豆腐块青年。但是这种小众感性的、书面化的沟通能力，对于产品经理这个岗位的沟通要求，根本就不够，甚至是起到逆反的作用。踩了这么多坑以后，被怼了这么多次以后，终于从刚入行时，动不动要被气哭的感性妹纸，成长到今天，刀枪不入的理性小姐姐…
原文作者 @Miss right
该文章评论功能已经关闭！