引子：在产品经理的日常工作中，有一件事情会占据很多的时间——沟通。产品经理如何了解用户，发掘需求？如何向老板申请资源，获取足够的支持？如何让设计师，开发，测试，运营理解你的需求，并配合你进行工作？遇到这些事情的时候，有良好的沟通能力，能让产品经理更从容的进行工作。本文主要讲述我对产品经理日常工作中沟通的一些思考。

概述#

沟通的定义：沟通指人与人之间，人与群体之间的思想与情感的传递和反馈的过程，以求思想达成一致和人际关系的顺畅。流程如下图所示

沟通_基础模型.jpg

注意：其中正向的通道和反向的反馈中，主体输出或接受的信息都会受到噪音干扰，导致接受者对获取信息的理解与输出者想表达的信息产生一定的偏差。

沟通的作用：
沟通最基本的作用：
1.传递和获得信息
2.改善人际关系
对于产品经理来说，更具体的表现为：
1.使人们达成共识，进行合作。
2.降低成本（时间，人力等），提高办事效率。
3.获得更有价值的信息，使个人办事更井井有条。
4.使人进行清晰的思考，有效把握所做的事情。
总的来说，就是让团队成员理解团队目标，形成共识，心往一处想，力往一处使；明确自己的定位和任务，减少不必要的精力消耗，用更少的精力把控全局，从而可以有更多精力使用在关键任务上，提高效率。

如何做好沟通#

对于沟通的定义，模型和作用有了了解之后，产品经理要怎么样做好沟通呢？
我们从沟通的模型着手分析，先看沟通的要素：
1.主体，包含输出者（主导地位）和接受者（被主导地位），当然有时候两者主导与被主导的关系会随着情境变化而改变。

2.通道，输出者向接受者进行信息传递的途径，内容的总和。即包含两个方面：选择什么样的沟通方式和输出什么样的信息。

3.反馈，反馈是双向沟通中，接受者对输出者的信息传送，包含对信息的理解，态度，情感和困惑等内容。反馈的时候，输出者和接受者的角色会产生变化，参照1。

好，这样看来，要做好沟通，需要做的事情就很清楚了：
1.了解沟通的主体，了解自己，了解沟通目标。
2.选择合适的信息传递途径，整理好需要输出的信息。
3.进行沟通。
4反馈和确认。
从沟通流程上将，1和2，属于沟通前的准备工作，3属于沟通工作，4属于沟通后的工作。我们一步一步来看如何做好这些工作。

第一步，知己知彼，做好准备##

知己知彼
了解自己，就是了解自己的所处的位置，自己能争取到哪些资源，可能会出现哪些问题，有哪些是自己可以处理的，哪些不能处理的，不能处理的问题是否可以通过获取上级支持来解决？
产品是团队的核心，是船长，掌控着团队的方向，产品最终做成什么样子，直接由产品负责。成功了功劳是团队的，失败了黑锅是自己的。简单来说，产品经理是产品的第一责任人。如果你不是，说明你目前只是挂着产品经理头衔的产品设计师，产品助理或者产品专员。向真正的产品经理努力吧。
了解沟通对象，了解对方的身份特征，性格特征，人际关系特征，工作能力情况等，判断对方可能的态度。

做好准备工作
准备工作最重要的一块就是产品的自己的工作，从需求到最终设计出来的产品原型。很多产品经理在沟通上出现问题，在于自己本职内的工作没有做好，比如逻辑不清晰，需求不明确，细节没想好，对现有资源状况认识不清晰。另外就是准备好沟通的方式，当面沟通，电话沟通，书面沟通？沟通的内容，PRD，原型，设计效果图等是否都已经做好并且通过评审？
以下几个问题可以帮助检查自己的准备工作：

• 自己的需求是否真实存在？是否会频繁变更？如果你的需求连自己都说服不了，怎么能让其他人信服呢？
• 原型设计是否考虑到交互和细节？是否体现了需求？流程是否顺畅？
• 需求文档是否描述细致？是否考虑到细节问题？模拟用户使用场景，是否能满足用户需求，可能出现哪些问题，是否有对应的防错措施？
• 事前是否与相关人员沟通？让沟通对象也有所了解和准备？
• 是否确定好沟通的时间和地点？
• 自己要表述的内容是否条理清楚，简明扼要，通俗易懂，并列好提纲？

良好的沟通##

如果之前的准备工作做的充分，这一步将会变得较为容易。不管是和设计师还是开发人员进行沟通，一般可以按以下步骤进行：

• 说清楚要做什么。不仅说清楚要做什么，而且要说清楚为什么这么做。这一步很重要，做得好能让沟通对象认识和自己是一伙的，是一根绳上的蚂蚱，一荣俱荣一损俱损。
• 逻辑清晰的说明功能点。工程师喜欢逻辑清晰的东西，这让他们能够快速的了解需求，设计技术方案。对于设计来说，逻辑也同样重要，告诉他们你需要那几部分内容，分别要体现什么，哪里因为什么原因需要重点突出。
• 引导和控制反馈。告诉他们可以随时打断并进行提问/等你表述玩某一部分或全部功能集中提问。根据你喜欢的方式来，回答他们的问题。做好控制，防止发散，很多时候，一聊就聊到题外去了，浪费了时间和精力。如果遇到不能短时间解决的问题，先放一下，沟通结束之后再进行确认或者私下再度确认。

关于沟通的方式，一般以口头沟通为主，辅以书面文档。口头讲解，文档作为开发，测试的依据。

最后补充很重要的一点：心态。心态很重要，沟通的本质是工具，让其他岗位的人员明白你的意思并执行，不是辩论更不是吵架。是解决问题的，不是制造冲突的。
记住：
沟通不是PK，你不是为了输赢，是为了做事。不要输赢，要共赢

沟通之后##

沟通之后，如果是简单的口头沟通，再次进行确认，明确彼此的任务和交付时间节点。一般来说，作为备忘或者防止以后理解偏差导致结果出现问题，需要将沟通结果以书面形式发送给干系人。举个例子：比如产品设计和UED设计完成，向开发进行产品移交会议，会议结束后，需要将PRD，设计稿等相关资料在项目管理工具上进行体现，并用邮件发送给干系人，明确各方任务。

另外，在设计或者开发，测试过程中，也需要进行沟通，包括：了解工作进度，对设计，开发，测试人员有疑惑的地方再次进行解释，突发状况引发需求变更等。

TIPS#

• 如果你是个年轻的PM，或者感觉自己信心不足，站着沟通会让你显得更加权威。

• 情绪控制，控制自己的情绪，控制他人的情绪。不要带着情绪交流。避免在对方情绪激动时反馈自己的意见，尤其当要作一个与对方所寻求的意见不相一致的反馈时

• 如果遇到一时不能解决的问题，告诉沟通对象这个问题你记录了，会后再进行确认并告知大家。

• 保持谦逊，你和所有人都是平等的。

• 勇于承担责任，出了问题，第一时间不是撇清关系，而是找到问题并解决问题。互相体谅。

• 鼓励，促进对方表达的意愿；询问，引导对方，获取更多信息；反应，告诉对方你在听同时完全了解对方的意思。

• 反复确认，沟通永远是不够的，多次重复确认，会让对方有紧迫感，也会强化任务在对方脑中的印象。

• 提议，在获取对方的意见后，勇敢地提出意见或者解决方案，并进行讨论，勇于占据主导地位。

• 处理好人际关系，和你关系好的人更愿意与你合作。

• 夸奖。FFC原则。Felling,Fact,Compare。不要仅仅告诉TA好，要有事实和比较。表扬一个设计稿做得好，说“做得真好”远不如说“这个设计真棒！以前页面没有重点，显得很乱，现在结构清晰，用户一眼就能找到他想要的，而且操作更加自然”

• 反馈和激励。经常分析数据，并向团队反馈，让团队成员知道自己做了事情，并且有了效果，获得自我价值的实现的认同感。上线邮件中表扬团队成员。这些东西，一方面有利于人际关系，一方面增强了大家的集体荣誉感和自我实现，同时也渐渐的树立的你在团队中的地位。

实战案例#

设计师##

问题：设计方案不满意，如何建议设计师修改？
解决：
把握住核心：需求！
1.请设计说明当前方案的设计思路，并予以肯定
2.根据ta的说明，分析在产品端能达到的转化效果
3.表述我期望的产品转化需求
4.之处当前设计与产品需求不契合的部分，提出修改要求

这样就避免了与设计师直接讨论好不好看、设计品味之类的扯皮问题，把问题转化到产品需求上，设计师也比较能够接受。没有主线，沟通方向容易失控，有可能会走向“这个button为什么不用圆角”、“红色太鲜艳”乃至“SB你懂设计吗”之类的心理对骂。

工程师##

问题：这个实现不了！
解决：
“技术无法实现”的潜台词可能是：

1. 给的资源不够， 完成不了
   当前没时间，需要其他开发支持但目前没有。协调资源，争取更多资源，如适当延长时间，让技术实现。
2. 你的优先级低， 不想给你做
   向leader明确优先级，并进行排期。记住你不是老板，只要上级觉得这么排没问题，那对于你就是可以接受的。不要去争顶，撒泼。没有意义。如果真的很重要，说服leader调整。
3. 看你不爽， 不想给你做
   人际关系问题，但是不便明说，就是给你穿小鞋。不是他有问题，就是你做人的问题。如果自己有问题，改之；不是自己的问题，找到对方产生这种情绪的原因，对症下药，采用各种可能的方法，让对方服你，或者寻找leader帮助，或者换环境吧。
4. 功能太傻不应该做。
   同3
5. 这个东西，尤其是已经迭代开发过几次的项目或者产品，其框架和技术选型其实已经制约了某功能的实现（不是功能做不了，而是做出来满足不了产品经理的要求）
   一般在需求讨论阶段和技术leader开会时就确认技术实现起来没问题，不要拖到开发中才发现。如果不幸在开发过程中发现，根据该需求的重要程度，选择修改需求保证上线或者全部推倒重来（一般都需要产品和技术leader甚至更高级别的人员参与拍板，你反馈就行了）
6. 该技术人员目前还没掌握此需求所需的技术积淀。
   根据技术人员能力变更方案或者招聘有能力的人。