作为一名产品经理，工作中除了经常与技术、设计沟通以外，也需要同内外部沟通。在这些日常沟通中，都有哪些沟通技巧和心得呢？一起来看看
产品经理的工作分成两部分：一部分是产出方案的过程，另外一部分是跟进执行的过程。如何愉快的玩耍，其实讲的就是后面这部分（应该不算标题党吧，咱们写东西还是很实在的好吗，呵~）。
能不能愉快的玩耍，我认为核心是：产品经理对其他岗位的小伙伴以及他们的工作到底了解多少。说白了就是：懂的越多，越专业，越愉快。
如果用我们常用的流程图来表示的话，我想有可能是这样的：
图3-1 执行跟进流程图
可以看到，多花点时间去学习其他小伙伴的工作，不但能省钱，还不需要出卖灵魂。刚毕业的时候参加同行的线下活动，有嘉宾问到：你认为产品经理是干什么的？很多人给出的答案是“沟通”，好像我们做产品经理成天都在耍嘴皮子一样。我始终认为沟通技巧本身是次要的，懂不懂才是关键，就好像一个乐队一样，你觉得鼓手真的只会打鼓，吉他手只会弹吉他吗？肯定不是这样的，业余时间他们都在互相轮换，这样就知道对方想要什么声音。
一、交互&设计
1.1 理性
设计的部分，我们分成理性和感性两部分来说。理性的部分就是根据设计常见的四个基本原则：对比、对齐、亲密性和重复。对比的意思是说，好的设计会告诉你，先看什么后看什么，从哪里开始从哪里结束。对齐是说，页面上的任何一个元素都不是孤立存在的，空间上需要跟某些其他元素对齐。亲密性讲的是有关联的页面元素应该放在一起。重复是说不同页面之间同一个元素需要保持一致。以上是设计的基本规则，当然规则是可以被打破的，但是打破之前需要知道规则是什么。
1.2 感性
说完了理性的部分，我们来说感性的部分。如果跟我们对接的设计师换人了，导致设计风格跟之前完全不一样，这个如何来控制？或者你认为某个设计创意，用户很可能不喜欢，这种感性的东西，如何处理？两种方式，一种是通过设计规范，规定好颜色、字体、按钮、输入框、图标等，所有页面遵守设计规范，刚开始可以出个v1.0版本，之后不断更新迭代。另外一种，是根据产品的用户画像，有目的收集目标用户喜欢的设计元素，由此构成设计的素材库。
1.3 老毛病
这里我们说下很多设计师常犯的毛病。比如有些设计师觉得，出来的东西只要能表示出设计效果就可以了，内容不对也没关系，虽然前端和开发阶段可以去完善，但是这样会给设计评审和开发带来很大麻烦。再有如果是领导关注的工作，有些设计师会格外卖力，各种标注各种注释非常完善，领导不关注的就随便糊弄一下，这些都需要我们去留意。
二、前端&开发
2.1 要不要懂技术
对于产品经理要不要懂技术的讨论，一直没有停止过。不懂技术的产品觉得完全没必要，干了这么多年也没觉得比谁差。懂技术的产品自己在暗爽，觉得不懂技术还做什么产品。我建议没接触过技术的产品经理，最起码做一些基本的尝试，比如以注册功能为例，找一个注册的设计稿，自己去切图排版，了解下前端经常容易出现的浏览器兼容问题，另外在本地搭建一个虚拟主机、数据库的开发环境，选一个开发当前在用的服务端开发语言，尝试做一个注册功能。
以上这些可能需要1、2个月的时间，但是对我们有非常大的好处，产品经理可以把自己当成一个程序员，理解他们是如何工作、如何思考的，深入下去可以练就你的钛合金像素眼，随便一搭眼1个像素的偏差也看的出来，还可以直接跟开发讨论技术方案，一起商量一个工作量最小同时又满足需求的方案。
2.2 开发和产品的区别
开发跟产品、设计等一个非常大的区别是，在需求紧急的情况下，产品、设计可以在保证目标的前提下，整体上尽量简化，但是开发不同，只要有一个技术点遇到问题，就一直卡在那里过不去，尤其是遇到一些莫名其妙的问题，经常就是这些之前无法预测的问题，导致开发延期。如果有一定的技术基础，在做工作量评估的时候就会靠谱很多。
2.3 老毛病
有些开发会把基本完成的东西拿出来评审，完全没有自测的过程，他们觉得反正后面有测试，或者需求可能会改，先搞个差不多就行了。我认为，开发对自己的东西是最熟悉的，哪里会出现问题只有自己最了解，自测的过程越早进行，对产品的影响就越小。
三、测试
前段时间一个前同事，现在是一个行业内知名公司的产品经理，说公司没招测试人员，需要产品经理自己测试，于是在群里发来一个功能，让我们帮忙测试一下，行业内这种情况不在少数。
测试的工作分成两部分，一部分是性能测试，一般是使用工具自动完成，另外一部分是功能测试，也就是根据我们的需求，设计测试用例来测试。所以我们重点需要通过评审测试用例来保证测试的质量，看测试用例是否涵盖了需求所有的情况，尤其在边界条件下的使用问题。
四、UE
关于用户研究相关的内容，在我的另外一篇文章《用户研究方法的实践细节》里面有详细的说明。
在这里我想说的是：UE的同学跟测试一样，是被行业严重低估的岗位，实际上他们的工作非常重要。
一个UE的负责人曾经跟我说，我们这边的人都很单纯，我非常认可，他们嘴里经常说的是用户，他们是真正把用户放在第一位的人，我们需要通过各种方式去宣传他们的成果，让公司更加认可他们的价值。
五、运营
运营身上背着详细具体的数据考核指标，很多是与营收相关的，要想体面的把钱赚回来，可能不太轻松。比如运营说，该做的都做了，是你产品不行。
这个时候我们需要具体分析相关的数据，跟竞品比，跟公司内部其他产品比，跟行业内大的品类比，我们处在什么位置，我们有哪些问题和优点，哪些是我们产品可以解决的，哪些是需要运营解决的。
再有：运营经常有很多天马行空的想法，那我们要明确这样做的目的是什么，上线之后哪些数据可以说明目的是否达到了，保证不做没有结果的事情。
六、领导
产品经理如何跟领导相处，我认可脉脉上的一个回复：出活+听话+多聊天。
出活的意思很容易理解，保质保量完成任务。听话可能会有些争议，我理解是说：我们提的方案，如果领导有不同意见，首先我们要保证领导完全理解了我们的想法，因为有可能领导提前已经有了自己的方案，发现我们的方案跟他的不一样，并没有仔细看就直接否决了。
如果领导已经理解了我们的想法，还有其他意见，那我们要搞清楚为什么，有时候可能领导没有说明原因，那我们要通过各种方式去了解。
如果领导和我们的想法互相都理解了，还是有不同意见，那就听领导的，与此同时，我们要做好预案，有哪些风险要提前评估做好准备。
多聊天也很容易理解，多跟领导汇报工作，让领导了解我们的工作进展，同时也了解领导的想法，保持思路同步。
七、内部与外部
这里我想重点强调下内部，很多产品外部搞得热火朝天，内部却没几个人知道，这是非常可悲的，我建议产品经理没事可以多勾搭公司内部其他产品的小伙伴，会有很多启发和潜在的合作机会，尽量争取内部的关注和资源。于此同时，产品经理也要有外部的圈子，包括核心用户群和同行圈，核心用户群可以帮你验证产品概念、发现需求，同行圈可以是前同事或者外部组织，可以帮你扩展视野。
八、自己
8.1 合作 – 为人着想，为己方便
当我开始做方案的时候，总是想着尽快完成通过评审，为团队后续工作挤出更多时间，而不是慢慢悠悠把前面的时间浪费光了，只留给其他人很少的时间；当一个功能实现上比较复杂或者有技术困难，我会跟开发商量，尽量找到一个更简单的方式来达到同样的目的。
当我们尽量处处为别人着想的时候，如果出现需求变更，或者进度延期等特殊情况，需要别人支持的时候，沟通的阻力就会小很多，这要比给别人买瓶水、请别人吃个饭管用的多。
8.2 听 – 鼓励意见，把控方向
我们给出的方案，不一定每次都是最好的，要达到同一个目的，实现的方式也有很多种，如果有人提出不同意见，可能不一定每一句都是对的，也可能只是一个考虑问题的不同角度，我都会非常感谢。
我们知道很多知名的产品最初并不是产品经理提出来的，很多知名产品的本质也不是产品本身来驱动的，如果急于争辩，就再也没有这样的声音了。
另外，有时候也有可能出现这样的情况，本来聊的是A需求，不知不觉就扯到了B需求、C需求，沟通过程中我会非常留意，发现苗头立刻打住，防止话题跑偏。
8.3 说 – 注意禁忌，多多夸奖
产品经理在沟通过程中，有些雷区需要特别留意。比如跟开发沟通的时候，有的产品经理会说，这个应该很简单吧？开发说，既然这么简单那你来吧？跟设计沟通的时候，有的产品经理说，这个太丑了，或者再做一个版本对比一下。
我们做产品经理自己都不知道要什么效果，让设计师如何设计呢？再比如我们想了解其他小伙伴的工作进度，可以关注下他们是不是卡在哪里了无法推进，如果有需要就协助解决，因为不是每个小伙伴都有主动沟通的习惯，如果我们只是来一句，做完了没有？可能不太合适。
产品经理跟其他岗位一个很大的区别是：我们是一个需要别人支持的岗位，我们只产出方案，任何一个环节出问题，都会影响最终的结果。如果其他岗位得奖了，大部分是自己的功劳；如果产品经理得奖了，那一定是整个团队的功劳。所以在我们取得一点小小的成绩的时候，别忘了通过各种方式表达我们的祝贺和感谢。
九、总结
从交互、设计，讲到前端、开发，再到测试、UE、运营、领导，还有内部外部，最后说到自己，一不留神啰嗦了不少，各位能不能多给点辛苦钱？呵~
