老板、甲方脑袋一热的一个需求，轻易的改变了原本的规划，产品想着努力沟通却把工作量从1聊成了10，最后谁都不待见，这是一个真实的互联网产品的日常缩影。 如何掌控沟通、如何有效汇报、如何避免“开口即跪”？ 产品、运营、项目经理、开发在日常过程中类似情况真的不在少数。 过去，笔者见过许多专业能力非常强的老产品，能跟开发聊代码，能跟UI谈设计，画的一手好原型，业务逻辑无比熟悉，最终却无法掌控属于自己的产品节奏。 究其根本，几乎无一例外的是缺乏沟通这项“软技能”。 笔者曾在“某宝”ISV（技术供应商）两年的地狱式产品工作，积累了50+项目负责人经验，在接触了近百位“甲方以及身边的产品“真实案例后，总结了关于需求沟通管理方面的六步公式，和大家分享一下。 一、信息的确认在项目管理指南《PMBOK》中沟通有专门的方法介绍，如推式沟通、拉式沟通、交互式沟通等。 当我们与干系人间直接产生对话的过程便是交互式沟通，针对交互式沟通最重要的一点便是信息的确认。 你是否有过在需求评审的时候，被开发不断的提问难倒？总有问题要留到会后再去确认？ 所以在信息的确认这一步，看似简单，却是影响最大的一步。 那么我们如何好信息的确认？
举个例子：
如以上例子，每个回答都是以疑问句收尾，这样确认信息方式的好处有两个：
有时候我们在沟通时，很多人在第一时间是忙着先拿笔记录，这一点笔者不是特别建议。 当然记录本身没有什么错，只是有时候在记录的过程其实会忽略掉一些信息背后的东西，如：沟通情绪、需求紧急度、需求的真实度等等。 所以，整体来说在沟通的第一步，就是确保信息的有效性、准确性。 二、去除部落效应
不知道大家工作中是否有见过类似这样的话：
诸如此类，在日常工作、生活中，我们经常会被套上各种身份，例如：甲方和乙方、业务方和研发方等等、甚至是产品经理和开发。 当沟通的过程开始陷入各种身份中去，就会引发部落效应。沟通变成了谈判，而谈判总是零和的博弈。 项目管理学中：“由于项目的实施与项目的成功，其利益会直接或间接地受到正面或负面影响的个人和组织”称之为项目干系人，能够针对产品提出需求、想法的人，证明其是关心产品成败的。 换句话说，对方正在为共同的产品做努力，这一时刻我们是一个团队，不是两个组织。 所以这一步，更多的话术上的技巧，首先要做的第一件事，就是改变自己对需求的看法。 作为产品的我们需要记住，任何项目、产品最佳实践都是合作，而非对抗。 那么有没有一些干货是我们可以直接用到的呢？ 举个例子：
三、陈述实事，打破“我觉得”
要知道知识的诅咒名词可能大家很陌生，但很容易在产品身上发生，想当然的从个人角度去理解用户是产品的大忌，所以作为产品人的我们，要时刻理解“用户是用户”。同样的，在沟通中也是如此。 我们都说最好的沟通一定是以诚实为基础的，但是有时候我们的诚实，并非真正的诚实，我们经常会忽略掉那些误以为 对方知道的信息，信息不对称，牛头对马嘴如何沟通呢？ 所以在沟通的过程中，陈述需求完成的基本条件，是为了让双方能够存在一个共同的知识背景，避免“知识的诅咒”产生。那么这一步也就很简单了，尽量把沟通中需要用到的背景知识说全就好。 举个例子：
类似的方式有很多，也很基础，最核心的地方是把实际信息说清楚，尽量避免模糊空间即可。 四、建立模型，全局分析
在笔者和自己团队在分享“沟通”这个领域的时候，也反复有在强调人与人之间沟通的背后，其实就是需求。 很多产品、项目新人在入行初期，都非常注意在文档、原型、或是某些软件技能上花过多时间进行钻研，包括笔者当初也是。 当然，画得一手好原型，写的一手好文档本身并没有错。 但是身处介于用户、市场与研发之间的产品们，我常常称之为“中间件”，如何保证需求与价值之间的其实才是这个岗位最重要的工作，也就是我们常说的“投资回报率”。 如何保证业务需求的准确性、高回报比，让研发的工作产生最大的价值，这个部分笔者不做详细赘述。 举个例子，笔者就经常使用类似价值成本分析法、OKR象限法等。 价值-成本图谱 通过一定的模型（这个模型可以定制，但标准要一致），来对需求做排列。 通常有一定经验的产品、项目经理或者对产品足够了解的情况，都可以快速作出判断是可以跳过这一步，若没有足够的自信，还是请谦虚的和团队多讨论之后进行判断。 总之，对需求的分析是必要的，没有一定论证分析的讨论对沟通的双方以及背后代表的团队都是极不负责任的做法。 在确定了可行性、优先级等后，就要开始选择沟通的方向。 什么是沟通方向呢？ 五、提供方案、解决反馈沟通方向，其实也就是我们希望沟通的结果往哪个方向走， 承接前面所说，所有的沟通背后是需求，那么所有的需求面临的结果是什么呢？ 是决策。 需求做还是不做、做哪些、如何做、何时做、都是一种决策。 所以关于决策，有几个要素我们是要知道的：
关于这4点，其他都比较简单，这里重点谈一下什么是“框架效应”： 人们在面对收益时，趋于规避风险，偏好稳定。 人们在面对损失时，趋于寻求机会，偏好冒险。 总的来说就是：一件事你怎么说，很大程度会影响到对方怎么想。 比如下面这个例子
这个就是著名的”亚洲疾病“理论，也就是上面说的”框架效应”。 另外几点，简而言之就是：别让对方想解决方案、提供信息协助对方做决策但是别替对方做决策、提供的信息最好是道选择题，这几点不单限于于市场、用户、甲方的沟通，在做上下级汇报的时候也是一样的。 那么综合以上，我们可以做出这样的模板。 1. 为对方提供1-2个可推敲的解决方案 2. 利用框架效应进行引导
需要注意的是，日常生活中个别人是风险偏好性格，面对这类人，框架效应要反着来使用。 3. 给对方做选择题 举个例子： 可以这样：老板，这件事情我们沟通后有2个方案，A方案是这样，但项目上线实际会延期，大致延期N天，B方案是在原计划做这样的一个调整，有20%的概率出现性能不太稳定的情况。 六、给出建议，让对方说出，你说的对！其实在完成前五步，整个沟通过程已经算基本完成。 只是，虽然前面我们说了最快的决策是做选择。 但人性的深处对选择还是害怕的，这时候如果有人站出来说一句：“我建议这样比较好，因为xxx” 别看这样的一句话，却是能够起到很大强心针作用。 就像我们经常听到的：“都是他这样，所以我才这样”是一样的道理。 所以，我们在第五步就已经能够猜出对方的选择的时候，将对方的想法说出来。 让对方找到一定的安全，在心里觉得，你说的对！ 即在第五步的结尾，加一句：团队这边觉得B方案可能好一些，稳定性可以在上线后同步做修复。 回顾全篇针对沟通的六步的解析，归纳下来的公式就是：
以上六个步骤，并非需要完全套入，我们可以进行裁剪。 对了，回到篇头的场景。 后来跟“小赖”聊完之后，去和老板重新沟通了一遍 最后敲定下来，就只是先换了一个商城Banner，并且确实换完之后得到了一些好评 就这样~ 最后附几句心里话本篇的中心其实不单是为了讲解沟通，笔者希望作为产品的各位，能够回归产品人的本质”寻找产品价值“。而在这个过程中，任何干系人的建议，其实都可以是提升产品的能量，千万别为了拒绝而来学沟通。 另外，市面上关于沟通这件事的知识文章、书籍有很多，这一篇也可以算入其一。 但随着工作的累积，越发觉得“不存在油嘴滑舌的沟通艺术”。 大道至简，最简朴有效的沟通艺术，叫做：真诚。 如果能够保证一颗真诚的心来进行沟通，那么这些步骤其实可以完全忽略。 本文由 @西特张 原创发布于人人都是产品经理 题图来自 Unsplash，基于 CC0 协议 |
|
|
