沟通的成功与否，既关系着自身工作是否达标也关系着是否能将虚化的需求转换为真实的产品。作为产品经理在日常工作中有哪些沟通技巧呢？文章作者分享了自己的一些心得。
沟通是产品经理日常工作中，除技能工作（竞品调研、原型、PRD）之外，最重要的工作内容之一了。对上，向领导汇报项目进度、请求资源协助；对外，向兄弟部门沟通工作配合；对内，梳理产品需求。
沟通的成功与否，既关系着自身工作是否达标也关系着是否能将虚化的需求转换为真实的产品。下图是产品经理的沟通模型，今天就和大家结合沟通模型一起交流一下，如何提高沟通技巧。
一、 搞清楚对象
1 找到对的人
有一些问题你找了错的人，沟通了半天结果发现他并没有权力或者说他并不会有太强的意愿来一起配合。
2 找全相关人
一个项目中需求的变更，往往涉及设计师、程序员、QA乃至项目经理，如果只和项目的某一些成员完成了沟通，即便这个沟通非常的顺利也不属于有效沟通。因为其他相关人员没有得到需求变更的信息，这就会导致他们工作的卡壳。这就是要找全沟通对象的重要性，没找全的话会导致你同一件事情重复沟通。
3 与上级领导沟通
很多产品经理的状态是，从领导那拿到简单的一句话就开始工作，但是即使再用心，搞不好领导还不满意。汇报缺乏逻辑、没有规划，导致付出的工作没有得到相应的回报，就太可惜了。
3.1 明确任务
首先接到任务的时候，要搞清楚疑问点，没搞清楚的点要当场确认。以下是需要确认的疑问点：为什么要这样做、开始时间和结束时间、负责人是谁、参与人由哪些、需要得到的结果是什么
3.2 过程汇报
沟通之后，要按领导确认的方案和时间节点情况，拟定一个汇报日历。记录好项目的里程碑，做好汇报节奏的规划。缺乏请示，否则领导会觉得不在掌控之中。具体的节奏要根据领导的时间安排和习惯，比如两天左右，下班时间汇报等。
3.3 总结汇报
当项目进行结束的时候，一定要把一开始的目标和结果做一个对比总结，这是自信和善始善终的表现。尤其是注意要用数据说话，这样会给领导留下深刻的印象。
4.项目成员沟通
即便文档写的再完善，在产品开发过程中也难免需要和项目的相关人员进行沟通。这个过程产品人员的工作往往会比较繁琐，也会比较忙，当然也会锻炼产品经理的沟通能力。而产品最头疼的是和开发人员沟通，这里就以此来阐述。
4.1做好基础工作
一是想好产品规划的原由，避免被技术的同学问住。技术人员也特别讨厌产品经理说“某某产品就是这么做的，我们按照他们的做就行了”这样的话；
二是写好产品文档，在产品文档中避免有遗漏的地方，特别是一些比较复杂的功能，一定要解释清楚
4.2如果被拒绝，要找到原因
产品经理的需求与开发人员手头的项目撞期：解决的办法很简单，就是根据需求的优先级来调整开发排期。
技术人员并不认同产品经理的观点：提供完整产品分析和用户调研外，平时要多跟技术聊聊天，增进彼此了解。另外，在跟技术讲解产品的时候也要适当的画饼，描绘一下产品上线成功后的美好未来，这会带动起他们的积极性
二、不同沟通场景的正确姿势
1 座谈会议
1.1 适应场合：项目立项、需求评审、视觉审核、项目总结、头脑风暴
1.2 必要条件：专人做会议记录（纸笔或录音后整理）
1.3 沟通工具：面谈、电话或其它语音设备
1.4 时间控制：时间不能超过60分钟
1.5 结果控制：会议开始前明确主题，围绕主题进行讨论
2 当面沟通
2.1 适应场合：需求疑问点或小的需求变更
2.2 必要条件：沟通完成后，将内容以文字形式进行记录
2.3 沟通工具：面谈、IM工具
2.4 时间控制：时间不能超过10分钟
2.5 结果控制：如果无法达成共识，就暂停，邀请项目经理参与
3 书面沟通
3.1 适应场合：结果通知，只要指E-mail
3.2 必要条件：将会议或当前沟通的结果，通过E-mail的形式进行告知
3.3 时间控制：无
3.4 沟通工具：纸质文件、E-mail
3.5 结果控制：准确的传达结果，如果有异议，通过邮件互相确认
三、选择合适的沟通方式
1. 一对一沟通
例如，当一个项目完成需求评审，进入开发阶段时，项目经理需要和每一个项目成员进行一对一的沟通，明确他对当前项目的疑问。这样做的原因是避免团队成员“一哄而上”的提问问题，导致沟通进程的中断。
2. 一对多沟通
一般当我们需要大家共同的力量一起想办法或者要做群体决策的时候，就需要采用一对多的方式。比如我们常进行的头脑风暴，还逐个找人单独沟通的话，那会极大的降低沟通的效率甚至让沟通无效。
四、使用正确的沟通工具
1 IM工具
1.2 优势分析：及时、快捷，面向对象广泛
1.3 劣势分析：干扰条件过多，有效信息不利于提取
2 E-mail
2.1 适应场景：正式沟通、结果通知及任务分发
2.2 优势分析：可复查、可追溯 、单一性抗干扰
2.3 劣势分析：线路单一、非及时
3 电话及其它语音设备
3.1 适应场景：远程会议
3.2 优势分析：跨越空间范围及时间范围
3.3 劣势分析：缺乏真实感、受制于工具性能，容易中断
五、沟通过程要理清
1 沟通前
1.1 理清事实：在沟通前，需要将事情本身（事实）理清楚。但什么才是事实呢？比如说“用户觉得某个功能不好用”。要清楚，这个“不好用”真实的含义是什么，是操作步骤繁琐还是交互反常理。
1.2 明确双方利益诉求：理清事实之后，我们需要进一步确实，在这件事情中，我们想要得到的最终结果是什么，现在就左手优化，还是放到后期进行迭代。
1.3 想清楚自己的底线，就可以知道破局点在哪里，在沟通过程中，只要不触及到这个点，沟通就有圆满完成的可能。
2 沟通中
2.1 把对方拉到同一个频道：在沟通的开始，需要确保双方在沟通同一件事情，且对同一件事情的定义一致。
2.2 缓解由情绪带来的冲突：因为对方并不一定能分清事实和情绪，所以我们要预先帮助对方排除情绪本身对于事实讨论的影响。我们需要按压下自己的不良情绪，首先站在对方的立场上，为对方说话。当对方能够平息愤怒后，才有可能真的坐下来和我们一起解决问题。
3 沟通后
3.1 结果确认：对于沟通时已经确认的结论进行简要总结，并寻求各方现场反馈确认，并以邮件、文件等进行实质性的记录，避免对方翻盘。同时，以结论为基础，明确下一步行动的责任人和完成时间，能够保证结论迅速执行。
3.2 二次补救：如果在沟通过程中发挥不出色，也不急着放弃，而是要寻求领导的帮助。我一直信奉在公司中，我的上级是我最重要的资源。
写在最后：沟通的学问其实很大，不同的角度会有不同的理解。以上只是我个人基于过往有限的经历所梳理的一些要点，欢迎探讨！
最后的最后，我的宝宝即将出生，人生第一次当父亲，忍不住把这种喜悦分享给大家。
