后台产品设计系列：高效沟通（六）

沟通能力是产品经理核心能力之一，可以说，产品经理百分之七十的时间都在与人沟通，剩下的百分之三十在准备沟通的内容。虽然我们深知沟通的重要性，但在实际沟通中仍会遇到各种各样的问题。此篇将结合理论与实践，分享一些做后台产品时高效沟通心得。

一、乔哈里视窗

与人沟通前，先了解一个沟通的基本原理——乔哈里视窗。

乔哈里视窗（Johari Window）是一种关于沟通的技巧和理论，也被称为“自我意识的发现——反馈模型”。这个模型将人际沟通的信息比作一个窗子，将信息分为4个区域：公开区、盲目区、隐藏区、未知区。

1. 公开区

自己知道，别人也知道的信息；例如你跟开发沟通时，产品现有功能、行业部分通用术语等。

开放区具有相对性，有些事情对于某人是公开的信息，而对于另一些人可能是隐秘的事情。我们所有的有效沟通，都是在这个区域上展开的。

公开区面积越大，沟通起来也就越便利，越不易产生误会。所以我们沟通前需要预估与沟通对象的公开区在哪，让沟通的内容始终在这个区域内，并在沟通中试探公开区的边界，当发现信息超出公开区后，就要先扩展公开区，然后再继续后续的交流。

2. 盲目区

自己不知道，别人却知道的信息。例如你跟业务方沟通，业务跟你讲业务场景，跟开发沟通，开发跟你讲技术实现等，这些信息都是你沟通的对象知道，但你不知道的。

对于这个区域信息，我们需要谦虚的学习，但切忌盲目接受，不加思索。尤其是在跟业务方讨论需求时，最重要的是学会区分什么是信息，什么是观点。

信息是事实，观点是主观判断。

我们需要信息来加深产品认识，为更好的产品设计提供基础，而观点是业务方的主观臆断，有时候一个功能放在竞品里合适，但放在我们产品里并不合适，没有认识到产品定位和各条件限制提出的观点是有失偏颇的，很容易把产品带到沟里去。

所以，我们减小盲目区的方式是学习信息，思辨观点。

举个栗子；我们做需求调研时，业务方经常会吐一堆的苦水，说系统这里不好用，那里缺个什么功能，你们应该怎么怎么样。常见句式就是：“哎呀，我们这个系统这里用起来很麻烦，你看看XX（竞品），有个这个功能，就很方便，我们应该加个这个功能。”

这个时候我们需要发现客观事实——“我们这个系统这里用起来很麻烦”，然后进一步挖掘，“在什么场景下某某用户会遇到这样的问题？这个问题出现频次有多高？这个功能对产品影响多大？暂时不修复会怎样？”对事实的一系列深挖，就是我们真正不断减小盲目区的过程，同时避免了其他信息的误导。

3. 隐藏区

自己知道，别人却不知道的信息。例如还未介绍的需求，产品经理神奇的脑回路等。

沟通中大部分的误解都是从这个区域产生的。你知道，以为别人也知道，当讲了半天发现别人还是一脸懵逼时，就会产生诸如“这么简单的问题怎么还不清楚”的疑惑，原因就在于你并没有把你知道的信息提前告诉你的沟通对象，导致沟通信息基础不对称。

所以遇到这种情况，不要随意给对方贴个“理解能力差”的标签，先思考自己所表达的信息是否是在他知识的“盲目区”，把可能造成障碍的概念提前解释一遍，先扩大沟通“公开区”，然后在这个基础推进。

4. 未知区

自己不知道，别人也不知道的信息。例如你跟业务都未考虑到的场景，你跟技术都没发现的逻辑漏洞等。

产品开发中发现的各种坑，在评审时为什么都没发现，就是因为这些坑处于未知区中，等待各路大神去踩。缩小未知区需要沟通双方的共同努力，也需要时间和经验的积累。

二、沟通的原则

1. 主导沟通，适时强势

在跟业务和开发沟通时，把主导权交给对方是件非常危险的事。

业务方主导

当业务主导你时，他就会提出无数你想都想不到、不知是否合理的需求，强迫你们去做，你以为按照他们要求拼了老命做出来就好了。实际最后拿给他们的时候会发现：做出来的产品跟他们的要求相距甚远；于是又得推翻重来，整个团队一起受苦受累。

开发主导

当开发主导你时，他就会跟你讲一万个理由这么做不合理，那样做不好实现，然后你按照他们的意思改方案，改逻辑，最后做出来一个面目全非的产品。

丢失沟通的主导权，就丢失了产品把控力，失去产品把控力，做出来的产品就一定是胡乱生长的歪脖子树，无论哪一方都不会满意。

出现这种现象的原因是：以为不同角色所站角度不一样，无论的是业务方还是开发人员，都是从各自立场提出意见的，存在片面性。

所以，无论是跟业务方做需求调研，还是跟开发做需求评审，都需要作为主导角色，去引导他们说出自己的想法和诉求。在理解分析后，由你站在全局、多角度做判断和决定，无论这个决定将带来什么样的结果，你都需要保持专业的自信和责任心。

但是要想能够主导沟通，需要在对方心中建立具有说服力的形象。

2. 扬长避短，展现优势

具有说服力的形象是在沟通中一点一点的建立，在沟通中学会扬长避短，彰显优势，是建立你的专业形象有效方式。

产品经理的优劣是相对的。

与业务方沟通

业务人员的优势是更了解用户、更了解需求、更了解场景。但他们不懂如何分析需求，只看需求表象而不知探究需求本质，不会区分需求的重要性，不会规划需求，同时也不懂技术；只要掌握少部分的技术方法，理解技术原理，你就能成为他们眼中的技术大牛。

所以在沟通中找个合适的时机秀一秀你昨晚刚看的知识点，讲一个“马车与汽车”的故事，都能为你加分。整个沟通过程，可以向业务方传达一个信息：你就告诉在什么场景下用户有什么需求，至于分析这个需求合不合理、怎么做等等这些事，我来想就行了

与开发沟通

开发的优势就是懂技术，除此之外，其他的好像都不太懂了（张小龙级别的不在讨论范围内），业务、需求、用户、体验、数据都是你的优势。

但是，面对开发，除了扬长，更重要的是避短。产品相对技术最大的短板是对技术的无知，既然不懂技术，就切记不要说“这个功能很简单的，半个小时就能做好”、“三天把这个功能做出来”此类的话，这是很多开发小哥的死穴。

这些大佬可以容忍你不懂技术，但绝不能容忍你对技术的低估，这是对他们工作的极大不尊重。如果说了这种话，请买好保险。

3. 察言观色，把握节奏

有效的沟通需要双方共同参与，主导中要依据情况把握节奏。

一边倒的沟通是低效且无趣的。无论是跟业务调研需求，还是跟开发做需求评审，都容易陷入一边倒的陷阱，一方从头BB到尾，另一方神游天际还好像一脸认真的样子，结果自然是会议时间浪费了，会后把讲过的话再一人复述一遍。

所以，多人会议时，需要掌握以下几个小技巧：

• 分清沟通内容轻重，重点内容投入更多时间精力，多做信息铺垫，扩大沟通双方“公开区”，非重点内容简单说明；
• 每讲一个重点前停顿强调，把精神上正在“打野”的同学拉到会议室；
• 重点内容介绍时适当降速，给予更多时间，让对方理解，皱眉人越多，给予时间越长；
• 重点介绍完，阅读表情，主动询问，及时答疑解惑，确保大部分人完全理解，遇到个别没跟上的同学，可以会后开小灶；

4. 紧盯目标，结果导向

我们的每一次沟通，都是为了解决一个问题，获得一个结果。但不是每次沟通都能获得如期效果的，有时我们甚至连一次跨部门的沟通会议都很难组织起来。

这个时候，如果没有秉持结果导向，就很有可能浑浑噩噩糊弄过去，最后该解决的问题一直搁置，直至成为一个绊倒自己的大坑。所以，结果导向意识是我们面对这些非沟通内容之外问题时，最重要的心态调整武器。

三、沟通的准备

1. 明确的主题和目标

无论是会议沟通还是单人沟通，沟通前一定要明确此次沟通要沟通什么内容，要达到什么目标，解决什么问题。否则会出现一堆不认识的出现在会议室，然后一句话不说，面面相觑的尴尬场面。

当目标很大时，可有拆分目标，分阶段进行，每次会议解决一个问题，多轮会议后就能达到那个大目标了。

2. 明确的沟通对象及关联方

做需求调研时，经常需要跨部门沟通，而且涉及部门可能是多个。所以会议前要明确主要沟通方和关联方，不能遗漏，否则会后执行要找关联方提需求时，是不会有人理你的。

另外，高效的会议一定是有人数限制的，人数越多效率越低，场面越不可控，所以各个相关方最好只出1~2个接口人，由接口人决定或传达，3~5人的小型会议效果最佳。

3. 完善的沟通材料

沟通材料是帮助我们扩大沟通各方信息“公开区”的最有利工具。

沟通前准备相应的材料的意识相信大家都有，但是否完善就是另外一个问题了。很多时候我们以为准备的材料足够了，会上才发现要解释得让参会人都明白还需要补充些图片。

所以，判断材料是否完善的唯一标准，就是这些材料能否帮助你让参会人中信息了解最少的人也能明白你的意思。

四、场景实践——以需求调研为例

做需求调研时，产品经理很容易落入无脑执行的陷阱，因为对于To B产品，在业务方、客服这样的一线人员面前，产品经理真的不敢说更懂用户，更清楚用户想要什么，所以很多的产品经理这个时候都会主动缴械，被业务方带着走，然后开始了痛苦的、没有激情的画原型之旅。

但实际上，我们可以化被动为主动，让业务方跟着我们的节奏走。

1. 沟通前

第一步：分析业务方的优劣势

这一点上文已经提到了，就不在赘述。

第二步：明确大目标，拆分小目标

需求调研前，我们要做的这个系统主要目的是很明确的，但如果就凭这么一个大而泛的目标直接做调研，那你收获的只会是一大堆乱七八糟甚至前后矛盾的需求，所以作为产品经理，我们要知道如何将大目标拆解为小目标，然后针对这些小目标一轮一轮的沟通。这个是我们主导沟通、主导产品的开始。

上图中，通过对大目标的分解，我们明确了每个回合要沟通的内容，准备的材料和结果输出，也就可以主导产品整个调研过程了，这个时候，业务方就是你的用户而已，相信你会从这个过程中找到做产品的主人翁感觉。

当然，上述环节可以视情况合并，一次会议包含多个主题。

2. 沟通中

第三步：紧盯目标，把握节奏

在实际会议沟通中，高效沟通最大的敌人就是过度发散，参与人数越多，发散可能性越大。所以，会议中产品经理除了要做表达着和倾听者，还需要做节奏的把控者，当发现讨论问题过度发散时，要及时且明确的把讨论方向拉回正轨，以免浪费大家时间。

3. 沟通后

第四步：及时总结整理

所有的过程，都是为了一个有效的结果，及时总结整理会议笔记和头脑中的记忆碎片，是把成果最大化保存的最好方式，从艾宾浩斯记忆曲线看：总结越晚，效率越低，尤其不要隔夜，一旦等到第二天再整理，你会怀疑自己记忆力是不是有问题。

作者：周翔，起点学院深圳1609期产品经理实战训练营学员

本文素材来自互联网