本文总结了需求沟通管理六个阶段的公式，用一个实例进行了具体形象的比喻，以便更好地理解内容的要点。

老板：“小赖，我看了一下我们的商业街，觉得不行。 请更改配色和排版。 就这样……，最近在看书，红色是有购物欲的，换成红色吧。 ”

产品：不行啊。 老板，这样就和我们的后台界面不符了。

老板：是吗？ 我觉得那个会员界面也一起改变，整体设计还是可以优化的。

产品：美元…但是，这项改革的前沿将重新开发。 在线时间不是变成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，并且确实换完之后得到了一些好评

就这样~

最后附几句心里话

本篇的中心其实不单是为了讲解沟通，笔者希望作为产品的各位，能够回归产品人的本质”寻找产品价值“。而在这个过程中，任何干系人的建议，其实都可以是提升产品的能量，千万别为了拒绝而来学沟通。

另外，市面上关于沟通这件事的知识文章、书籍有很多，这一篇也可以算入其一。

但随着工作的累积，越发觉得“不存在油嘴滑舌的沟通艺术”。

大道至简，最简朴有效的沟通艺术，叫做：真诚。

如果能够保证一颗真诚的心来进行沟通，那么这些步骤其实可以完全忽略。

本文由 @西特张 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议