在您的职场经历中，沟通是否曾帮助您解决了难题或推动了项目进展？您认为在沟通过程中最重要的原则是什么？分享您的经验和故事，让我们一起探讨如何提升沟通能力，打造更高效的团队合作。
作为产品经理，除了日常的基础工作如迭代管理、需求产出、数据分析之外，由于岗位职责特殊，还承担着诸多的沟通工作，甚至在事情的推动方面，有效沟通是促使项目进度往目标方向发展的关键。
在沟通对象方面，如果以产研部门作为一个分界线的话，沟通对象既有对外的，也有对内的，具体包括但不限于老板、领导、运营、市场、实施、UI、技术、测试等同事或部门，同时还可能包括客户对象。
无论沟通对象如何，坚持沟通的基本原则，根据沟通对象不同，使用不同的沟通技巧，都可以达到相对不错的沟通效果。
同时沟通能力作为一种软实力，在今后任何行业、任何岗位都可以应用到，是一种通用能力。
沟通原则是沟通的底层准则，不因沟通对象的不同而进行意志转移，而是从结果导向出发，推动结果的达成。
员工与企业因为契约关系而开始，员工的职责是企业带来效益，同时收获企业回馈的相对报酬。如果要让这种关系保持和谐的稳定发展，就需要实事求是的表达项目或团队的实际情况，无论是需要发扬和保持的积极现象，还是需要遏制和改正的负面现象。
作为中间的承接角色，产品经理对于项目和团队的未来发展都有着重大的责任。实事求是是一种追求科学的态度，这种态度也许在刚开始会伤害一部分人的利益，但是长久来看，是维持企业和团队长期发展的关键。
每个人都存在认知偏差，且是不可避免的。如果想追求事情的本质，作为承担决策职能的产品经理，需要学会批判性思维，特别是强势批判性思维。所谓的强势批判性思维，就是摆脱维护个人偏见的认知，学会接受他人的建议，通过多方讨论，共同得出对项目或团队最有力的决策。
一个决策听谁的不重要，做正确的事情才是最重要的。团队当中，如果每个人都养成了这种批判性思维，那么团队的未来也一定会很客观。（附：与强势批判性思维对立的就是弱势批判性思维，也就是立场维护）
沟通工作是人与人的一种交流，每个人都有表达的欲望和被尊重的需要。虽然最后最决策的往往是产品经理，但是在沟通的过程中也要学会“闭嘴”。
涉及到产品方向、价值收益时，产品经理可以进行全方面的综合性表达，但是涉及到一些需要专业人才执行的工作时，如技术方案的选型、自动化测试的执行、线下市场的推广策略等，产品经理也要学会保持沉默。
专业的人做专业的事儿，产品经理要学会的是如何将这些有专业能力的人集合起来，用团队的集体才智集合的收益，去创造超越独立的个体才智的收益集合，最终也别团队成员带来正向的积极反馈。
在职场中，我们沟通的对象是实实在在的带有个人意志和真实情绪的自然人，且每个人都或多或少存在在沟通的事项中，涉及到个人利益的判断取舍。在达到最终的沟通目标之前，良好的沟通礼仪是可以让沟通有效的持续进行的必要条件。
沟通的事情也分轻重缓急，大多数情况下重要且紧急的情况是比较少的。因此在与他人沟通时，尽量跟他人预约一个双方都可接受的沟通时间，比如十分钟后、下午两点等，这其中既体现了对对方的尊重，也可以确保在事情沟通推动上有效把控。
另外，换位思考想想，你是希望一个同事时不时来打断你工作，还是事前都跟你预约时间。
作为沟通的发起方，对于沟通内容的背景、关键问题点、预期目标都要提前整理好。另外，如果对于沟通事项的推进，涉及到一些其他部门提供支持作为前置条件，作为产品经理，需要提前与协助部门做好沟通工作，确保前置条件是满足。
否则，最终的沟通结果即使是可行的，但由于前置条件不满足，也会功亏一篑。不仅是时间、人力资源的浪费，在团队内部或部门也会形成一种不靠谱的印象，这并不是一件好事。
每个人都有表达的欲望，也有被尊重的需要。在沟通的过程中，对于正在陈述观点的同事，需要给予足够的尊重，不要轻易打断对方的观点。我们暂且抛开那些故意捣乱的情况，对于表达的内容，每个人的都存在可取的部分。
也许只是其中的一句话或其中的某一个词让大家对一些概念得到了统一，那也是此次沟通成果的内容之一。正如那句话所说“我不同意你说的每一个字，但我誓死捍卫你说话的权利。”
团队的存在其实也是多种携带专业技能的人士集合，每个人都有自己的特长，例如UI对于界面审美方面更专业、技术在实现方案层面更专业、测试在边界场景验收方面更专业、市场在线下推广方面更专业等等。
当然作为产品经理，在产品设计、成本收益的综合判断方面也要专业。那么在涉及到一些自己不是很了解的事情方面，产品经理需要学会适当的保持沉默。不过对于有疑问或者有自己见解的方面可以提出来供参考，但是尽量不要越俎代庖的参与这些内容方面的决策。
对事物的认知境界高低，往往就决定了最终的决策质量。
给人带来烦恼的原因之一，就是习惯性的说“不”。直白来说，就是无论对方说什么，都习惯性的进行反驳。带有这类认知的人，往往有两种原因，一种是知识丰富的相对自负，一种是知识贫乏的绝对自信。
前者一般在面对自认为认知较低的人群时，在心理层面就已经认定自己的决策质量会高于对方，于是对于对方提的一些跟自己原先观点相悖时就会进行反驳，也就是前文提到的与强势批判性思维相对应的弱势批判性思维。后者就是由于知识的贫乏，因此认知有限。
这类人的认知里，任何事物，除了自己的观点，就不存在其他的对立观点，久而久之，这两类人都会成为习惯性说“不”的人，而一旦养成了这种习惯性思维，对于其他要与之沟通的人来说，都将是一种灾难。
沟通简单来说就是将想要表达的内容讲出来，但是如果想要进行一次高效有质量的沟通，确保沟通的对象可以尽可能的获取完整的信息，且达成一致的认知，还是有很多细节需要注意的。对应这些细节点，有一些沟通技巧可以在沟通时使用到。
不同的人对于同一件事的理解，固然会存在着认知偏差。比如对背景了解程度不同、对所要达到的目标理解不同、对同一个矛盾点的考虑出发点不同等等。而产品经理往往作为沟通的发起者，对上述信息都有一个初始化的认知。
在与他人沟通的过程中，就需要提前将一些背景信息等进行介绍，同时在此过程中讲到关键信息时可以适当停顿。在停顿时，对方往往会对刚刚的关键信息有更多的思考，如果有问题，对方也可以及时提出，这样确保大家对于信息的认知水平是一致的。
当信息展示的形式不同时，我们获取的程度也是不同的。比如对于图片信息的接受程度就大于文字接受程度，这是由人脑结构决定的。而且人的大脑习惯性使用“系统1”进行思考，一般情况下，更“懒惰”的善于深度思考的“系统2”都不会参与信息处理过程。在我们与他人沟通时，就可以利用这个技巧。
准备好资料，例如要跟技术同学沟通一个需求，可以提前将流程图准备好，这样去沟通的时候，条理也会更加清晰，更偏于逻辑交流的技术同学也更容易接受。再比如讲解一些新概念时，也可以使用准备好的类比案例进行讲解，降低信息接受的难度。
我们沟通的目标是为了促成目标的达成，在沟通的过程中，沟通对象难免会有一些自己的看法，甚至是一些对理性的见解。这种时候，作为产品经理需要停下来想想，对方提出该观点的出发点，也许这个出发点就是当初自己思考不周全的地方。
换位思考，是产品经理必备的共情能力之一。之前讲过执着维护个人观点的弱势批判性思维和追求客观真理的强势批判性思维，后者才是更可取的方式。还是那句话，我们要把关注点集中在目标上，至于是听谁的，并不重要。
提问-回答，是一种常见的互动方式，既可以调节气氛，增加听众的参与度，让对方感觉到存在感，也可以提高听众对于信息的认知深度。在产品经理日常与人沟通时也可以利用到，哪怕是1V1的沟通，涉及到一些关键节点信息，可以提前设置好提问信息，同时对于沟通对象可能的回答提前做好应对准备。
如果对方对于提问的回答与你所希望的回答是一致的，那你就离达成沟通目标又近了一步。不过这里也需要避免一个风险，当我们对于提问的回答内容有偏向性的时候，会导致触发认知偏好的偏误。
产品经理是一个与人打交道的工作，不像技术同学更关注输出高质量代码，也不像测试同学确保产品无bug上线即可。平常除了要与产研内部同学沟通产品迭代相关工作，还要与外部的市场、运营、销售等多部门，乃至外部公司进行工作对接。所以产品经理岗位本身的特殊性，就承载着对内、对外的衔接工作，因此在情商方面也要求较高。
沟通时，由于不同的人性格不同，利益出发点不同，在沟通时难免就会出现争执、尴尬的场面，最怕空气突然安静。此时产品经理可以站出来进行场面调解，可以使用幽默的话语或者新开话题转移大家的关注点，稍后再进行沟通确认等。当然，还是要以达到最初的目标为主。
沟通技巧是一种通用技能，属于一种术。那么在不同的场景下，为了达到预期的沟通效果，所使用的技巧也是不同的。
提需求这个场景对于产品经理和开发人员来说，再熟悉不过了。处理得当，且形成良好的氛围习惯，对于团队内部的组织机制来说，也是有着极大的好处。产品迭代往往都是有截止时间的，因此首先要跟团队成员明确为何定下需求上线的这个时间点，也就是阶段性里程碑目标。
可以是从部门的KPI出发，也可以上升到公司的战略发展要求，同时也要阐明跟团队成员的息息相关性。在明确目标之后，就要明确为达到目标而要实现的需求范围是什么。需求都包括一些核心功能和一些可适当“妥协”的功能，特别对于核心功能需要明确在万不得已的情况下，是没有回旋的余地的。
提需求、限时间，一般就会导致的一个直接现象：加班。关于加班也要在团队内达成共识，加班的不只是开发同学，还有整个团队，只是大家工作内容不同，但是目标是一致的。特别是对于团队中的核心成员，要提前做好思想工作。
对于产品经理规划的需求，有时会涉及到个一个不确定因素就是：技术可行性。理想是丰满的，但现实是骨感的，并不是所有的产品经理的伟大设想都是可实现的，或者是在当前公司可提供的客观现实条件下可实现的。
关于这类需求，产品经理需要提前跟相关技术同学打好招呼，做好技术调研，做到心里有底，且在后续进行迭代排期时也可以做出靠谱的决策。
一般技术调研后有三种结果：一种是调研后可实现产品规划的需求，这种就是万事大吉；另一种就是可实现部分需求，那这种情况下，产品经理首先要调整自己的需求预期，其次在设计产品方案时就需要适当的进行技术难点规避；第三种就是完全无法实现，这种情况下，那作为产品经理就要考虑当前这件事的必要性了，是否非做不可，然后再考虑实现方案。
基于个人认知偏差的客观存在，产品经理所提供的需求方案肯定会存在“缺憾”的地方，可能是交互设计上不合理，也可能是条件判断规则思考有误，甚至也可能只是某个地方文案不严谨导致团队成员在理解上产生了偏差。
这种情况下，产品经理首先要跟相关成员明确变更了哪些内容，其次阐述清楚变更的背景和目的，比如在用户价值方面比之前的方案更好，对于用户体验比之前更符合操作习惯等。
但是需求变更并不一定都是可以被采纳的，比如可能要变更的新方案对于技术同学来说，要调整之前的技术架构，也就是影响范围较大。那作为产品经理就要考虑是否值得付出这些成本去获取当初自己调整方案所带来的收益。
随着每次迭代的深入，产品经理也会逐步进入到迭代验收的进程中来。在验收的过程中，难免会发现实现效果与需求不一致的情况，常用的叫法就是BUG。对于这种疑似BUG的情况，产品经理找技术同学沟通时，首先要明确当前的实现效果是与当初的预期不一致的，然后再确认是否是实现上的错误，还是自己操作上的错误。
技术同学往往都不会逃避BUG的问题，但是作为产品经理也要学会给技术同学提供足够的支持，比如复现你的操作行为，协助定位问题等。双方一起合作找出原因，解决问题，才是可取之道。
每个人都有自己所关注的利益，比如产品经理希望技术同学多实现需求，技术同学希望自己少被安排工作；产品觉得当前实现效果不行，技术觉得要是按预期效果实现，实现成本太高等等，这些都可能是造成冲突的原因。
遇到冲突时，首先要抱着诚恳的态度进行沟通，我们强调对事不对人，即使你对某个人有意见，也不要让这种主观偏误影响你专业的工作情绪。在沟通时也可以适当的主动进行“示弱”，多承认是自身的原因，希望得到对方的支持，一起解决问题。
同时，对于这种冲突情况的产生也要进行反思，表达自己后面遇到类似问题的态度和处理方式。对于冲突，处理得好，其实可以拉近彼此之间的关系。说到底，冲突就是一种更激烈的沟通方式而已。
沟通是一种人与人之间的交流，对于不同的沟通对象，沟通的重点和方法也是不同的。
产品经理最为一个连接产研内部与外部部门的角色，自然承担了大部分的沟通协调工作。与外部们沟通最重要的就是先确认沟通形式，如果是点对点的单独沟通相对而言简单些，可以采用社交软件解决。当然如果需要的话，最好还是当面沟通清楚，以免信息对称不完整，导致后续工作推动受阻。
如果不是点对点沟通，而是需要多一个部门的多人或者多部门的人一起参与的话，那就最好采用集中会议形式，做到信息同步所有相关人员。因此需要提前进行人员时间沟通协调，这个准备工作尤为重要，千万不要养成临时抱佛脚的习惯。
对于沟通的事项，如果需要有后续继续跟进的动作，需要明确第一责任人、第二责任人，以及明确时间点和产出物，做到事事有交待。如果有必要，也可以采用奖惩机制，推进工作的高效进展。
另外需要强调的一点就是：求同存异。不同的部门或者团队的诉求不同，可能当前想推动的事情会触及到他们的利益，他们因此提出相悖的想法都是很正常的事情。作为工作的发起协调者，要善于换位思考，秉持中立的沟通态度，切勿因个人偏向导致团队内部消耗。有时即使在会议上达到了“目标一致”，但是在后续工作推进中会受到很多阻力。
因此对于推进的工作事项，最重要的就是要目标统一，以产品目标为导向，综合权衡其中利益弊端，确保工作的有效推进。
对于达成的沟通结果，通过正式的邮件进行总结周知，做到日后可跟进追踪。
每个产品经理进入职场都会经历上级的领导过程，上级承担更多的责任是进行战略性的决策和工作协调安排。
在与上级领导沟通时，如果是涉及到对于某一项工作的方案决策，可以提供多种方案，表述清楚每种方案的优势劣势，供上级决策。这里还涉及到一个职场边界感问题，作为下级有提供方案建议的权利，但轻易不要触及作为上级领导才有的决策权利，也就是明确自己工作的边界。
一般情况下，由于信息不对称和行业经验，上级对于工作上的某一事项的认知都是高于下级的。同样的，对于上级表达的一些建议，需要理解内在的含义，如果要表达不同的意见，也需要有自己合理的应对方案。提出问题往往很简单，但是解决问题才是能力。
再者，如果对于上级布置的任务，如果在当时心存疑惑，一定要在第一时间再复述确认一遍，避免因信息未对称，导致无用功。更重要的是，如果没有在规定时间内未完成目标工作，还可能影响后续计划。
一般对于刚入职场不久的新同事都会安排mentor进行工作指导。对于职场新人，由于工作经验和行业认知局限，自然在工作中需要有指导的地方。因此在进行工作指导时，要尽量的进行提问和引导。
在情绪上也要注意保持平易谦和的态度，有时表现出不耐烦或者其他一些负面的情绪，可能会导致下级后续对你产生距离感，后续不敢请教或者工作的及时汇报。换位思考自己刚入职场时，也是一个萌新，有很多需要前辈指教的地方。
另外，对于下级的工作表现，可以进行批评，但是尽量不要在公开场合进行批评。公开场合多进行表扬，非公开场合可以批评。
对于向下级布置的工作内容，要明确预期目标产出物，以及交付时间。若觉察到下级有对工作有疑惑之处，上级也有责任再三确认和进行疑惑解答。
说到底，工作是一个互相通过信息及时同步，达到信息对称，一起完成工作目标的协作过程。
除了公司内部的对内、对外沟通，产品经理有时还会承担与外部公司的合作工作。例如做B端产品的产品经理，由于面对的客户是企业客户，要解决的问题是企业的业务问题，因此不可避免的就会与外部公司一起合作。
作为合作的双方，首先要明确甲乙方关系，明确各自的职责和分工，以及双方后续沟通方式和工作流程，比如通过社交群聊沟通，还是邮件形式等。双方在后续沟通时，涉及到相关的资料文档之类的，需要提前准备好。
如有必要，也可以提前发给所有参会人员，提前知悉以提高沟通效率。由于合作双方都代表各自公司，因此难以避免的会存在从利益出发点而产生的一些争论。
对于这些争论情况，切勿陷入个人偏好的误区，不要恶意揣测对方的意图。对双方来说，保持共赢的态度与合作方式，才是长久之计。
产品经理与技术同学沟通一般都是围绕提需求、反馈BUG、产品方案技术调研场景展开。在开始沟通前，产品自己需要厘清自己沟通的的目的，尽自己所能的将所涉及到的方面考虑清楚，不要只提问题就觉得等对方提供解决方案即可。
团队协作讲究的就是一种协作，一种一起思考解决问题的合作模式。例如提需求时，需要讲明白需求的背景和价值，如有相关的数据支持也可以进行列举，避免造成开发同学的反感。也许技术能力不是你作为产品经理的强项，但是分析清楚需求场景和价值是你的本职工作。
同时尽量的去学习一些常用的与技术同学交流需要使用到的技术知识，让他们感受到你也在很努力的配合他们。且在日后的沟通交流中也会更加高效，即使有时犯了一些技术的常识性认知错误，勇于承认和汲取经验，也可以形成良好的职场素养形象。
再者，如果工作中遇到不靠谱的技术同学，如拒绝沟通、习惯性拖延、交付质量差的情况，可以向其上级反馈和沟通。目的不是针对个别人，而是针对此类行为，企业若想长久维持下去，在运行机制和员工职业素质这个层面上，不可马虎。
产品经理与测试同学的沟通主要集中在需求评审、用例评审、BUG反馈等场景上，其中BUG反馈大多数为1V1沟通。在反馈BUG时，要明确BUG使用的场景，可以复现的话则最好不过。
因为引起BUG的可能性有很多，清晰描述场景和复现问题，可以协助测试同学快速定位，进而寻找到对应的开发同学进行快速处理。同时在反馈BUG时，也要讲明产品在该使用场景下的预期目标是怎样的，达成一致。
比如有的产品功能较多，不是每个测试同学都知道所有的功能。也可能会有测试新人加入团队，对功能的预期并不清晰。
针对需求，产品经理输出低保真原型，设计师输出高保真设计稿。特别是针对C端产品，相对于B端产品而言，对用户体验有更高的要求，因此产品经理跟设计师的沟通会更多。
首先对于输出的需求原型，不用过于高保真，例如色彩搭配等，尽量使用黑、灰、白即可，留给设计师充分的设计空间，让他们做自己擅长的事情。
作为产品经理，在高保真设计上可以听的帮助就是尽量介绍清楚原型背后的使用场景和用户画像。其次，如果对于设计师的交付品有不同的意见，可以从使用者的角度表达自己的想法。另外，产品经理也有部分的设计职能，为了更高的与设计师沟通，自己也要懂一些基础的设计规范知识。
虽说术业有专攻，但是如果什么都不懂，沟通起来鸡同鸭讲的感觉可不太好，甚至会让设计师觉得你很业余。再者，在项目排期中，设计师输出和沟通设计稿的时间也要纳入排期当中，切勿为了赶项目进度，忽视设计细节问题。
与运用同事沟通，重要的是基于数据说话。运营同事的职业认知决定了他们会有很多活跃的想法，但是这些想法也会存在很多主观偏见。因此对于运营同事提出的一些运营方案，更多的要基于数据评估。
无论数据是来源于产品本身的，还是用户反馈，还是市场调研，抑或是同类竞品的用户，至少需要有数据支撑，切勿陷入自我主观的偏误当中。
如果在沟通开始前做好充分的准备，在沟通中真实而有效的表达，在沟通后进行达成一致意见的跟进。
任何的沟通开始之前，都要明确沟通的对象是谁。找到对的人或者相关的人，是后续沟通准备工作的基础。若沟通对象不配合，可以向上级进行报备，寻求协助。明确沟通对象后，就要根据需要沟通的事宜进行功课准备。
提前理清业务或流程的现状，以及预期达到的沟通目标，其中涉及到的调整需要沟通对象提供何种帮助，都要一一列清，且可以提前设计好沟通的主线流程，以达到高效沟通。
在沟通时，可能会出现多人多角色参与的情况，所以要准备的沟通内容表达的侧重点，来让参与的人员都可以明确他们需要提供何种帮助、达成目标后对于他们的收益是什么、若目标未达成对双方的影响是什么。同时还要提前准备好，当沟通对象提出异议或者要求时，自己有没有相应的应对方案，要明确自己对于沟通结果的底线。
如果对于上述事项没有思考清楚，就不要贸然开始。
在正式沟通开始时主题先行，即向参与沟通的人员明确今天沟通所预期达到的目标。所有参与沟通的人员都是平等的，可能由于工作流程的上下游关系，所工作的内容不同，但是大家应该本次彼此相容的原则进行每一次的沟通。
每个部门、每个人都会从自身的利益出发去考虑一些事情，提出自己的建议，所以千万注意不要陷入主观先行的误区，也不要站在上帝视角觉得别人的意见是多余的。
随着每次沟通过程的推进，途中针对一些议题的意见若达成了统一，就要及时确认并记录。会议往往是比较耗时的一种工作方式，作为会议主导人也有责任控制会议节奏，避免一些无意义的发散，保证沟通对象对于沟通主题的关注度。
在沟通时，也难免会出现争执的情况，在个人情绪上要学会控制，学会心理隔离，避免被对方影响到，进而影响自己的独立思考，要始终牢记自己的沟通目标和预期效果。
电影《教父》里有一句话“不要愤怒，那会影响你的判断力”。学会冷静而清晰的思考，是走向强大的一种标志。最后，无论沟通之前定义的预期目标是否有达成，都要明确此次沟通的结果，以及周知同步下一步的计划。
在沟通之后，要及时形成会议记录，且通过邮件或其他团队认可的方式抄送所有参会和相关人员，做此次沟通结果的二次周知和确认以及存档留底。若对于沟通结果有异议，要尽早确认，切勿让工作推进过程中再进行方向调整的事情发生。
对于一些重要的决议，也要再三确认，否则在后期再推翻重来，是对整个团队的不负责。
接下来，就是对于沟通时明确的事项进行持续跟进，对于有里程碑式的进展也需要及时反馈周知，让所有参与人员明晰当前的进度，提高他们持续的参与感。
最后，对于事项若全部完成，也要通过邮件的方式周知所有人员，同步达成的效果。若效果较好，对于其他参与的人来说，也会认可你的工作成果和个人能力，有利于树立个人的专业形象，对后续工作的展开是有极大好处的；若效果不好，也不要灰心，总结经验，寻找改善方案，下一次做的更好。
没有人会嘲笑一个专注的、努力的、用心的为工作而努力的人。
本文由 @产品大白 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。