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