38 | 如何做好需求评审（下）：在评审中控住全场

爆竹声中一岁除，2018 pretty cool。

千门万户曈曈日，all your dreams coming true。

——王安石 & 邱岳（加微信：642945106 发送“赠送”领取赠送精品课程 发数字“2”获取众筹列表。）

作为产品经理，需求评审时最头疼的事情莫过于参与人都心不在焉，嬉皮笑脸就通过了评审，结果到了项目都快做完了突然又提出问题，这时再返工除了浪费资源，还会打击士气。

除此之外，有的产品经理甚至提到需求评审就紧张，因为经常会有人跳出来挑战产品方案，需求评审会最终演变成争吵掐架会，没有结果产出，大家不欢而散。

上次分享中我们聊到了需求评审的目的和准备工作，今天我分享几个能帮助我们提高评审效率的方法，希望可以给你带来启发。

1. 当心知识的诅咒

我们说到了评审会上大家不能积极参与的情况，通常情况产品经理都会责怪评审会的参与人，觉得他们没有积极投入，缺乏主动性。其实我觉得并不完全是这样，很多时候他们也是有苦难言。

这里要先提到一个叫做“知识的诅咒”的概念，指的是当一个人拥有某种知识之后，就很难想象和模拟出不知道它时的状态，因为陷入这样的状态会影响沟通和表达，仿佛就像受到诅咒一般，所以由此得名。

有个著名的心理学实验，让一组人在限定的范围内选择一首非常简单的曲子，然后在桌面上敲击它的节奏，另一组来猜具体是哪一首，最终结果是只有 2.5% 的听众猜对了曲目，而敲击者在敲打节奏之前，预测这一概率至少是 50%。

你也可以试试，在脑中试想一首旋律，然后手指敲打书桌，这时你会觉得自己敲打出的节奏如此准确清晰，别人不可能听不出来啊；但倘若你把桌面上的敲击声录下来，回放自己听，你就会发现当脑子里没有旋律的时候，这些敲击声就像是一串毫无规律的莫尔斯码。

作为产品经理，对业务和产品细节的了解就像脑海中的旋律，台上的你其实无法想象坐在下面听讲的人的处境。我参加过类似的评审会，虽然抱定全情投入的决心，但产品经理在上面讲不了几分钟，我就完全迷失了。

所以我建议你在做宣讲或者评审需求的时候，要像做产品设计的时候一样，把自己放到听众的上下文中去，把来龙去脉讲清楚。哪怕有一部分听众会觉得你有点啰嗦，也要讲，尽可能从所有人都了解的背景开始讲起，逐渐向外延伸，像讲故事一样。大部分人听到自己已经知道的事情时会有安全感，以此为基础延伸开来，才能让听众感到踏实和好奇，摆脱知识的诅咒。

2. 不要强迫，要吸引

和与人相处一个道理，当听众没有积极参与的时候，我们要做的不是强迫他们，而是引导他们来理解。在需求评审会上引导听众的最有力武器就是“具体”。

先讲个故事，这是我在一本书上看到的，说一个产品经理在公司内部做便携式平板电脑的提案，在上面介绍这个平板电脑的外观、尺寸、数据，说了半天下面的听众一头雾水，鸦雀无声。这时他发现自己随身携带的文件夹的尺寸跟这个产品的设计尺寸很相近，于是灵机一动，把这个文件夹扔到会议桌中间，说：这就是那个平板电脑的样子。

有人拿起那个文件夹端详，然后传给下一个人，终于有人开始发言，并且逐渐演变成了七嘴八舌的热烈讨论，开始提出问题，讨论功能特性。所以你看，一个莫名其妙却足够具体的文件夹，就能帮助所有漂浮在空中虚无缥缈的概念落地。

对于软件产品来说，我们的“文件夹”就是用户场景和用例故事。

为了让听众理解需求和方案，我们最好可以从场景和故事出发，用具体的案例来跟听众沟通，而不是对着文档从头到尾照本宣科。我过去的习惯是，先整体地介绍业务，大的逻辑和背景，然后用一个实际的业务案例把相关的功能和流程串讲一遍，最后回到文档本身，把需求文档从头到尾过一遍。

比如我之前做工单流转的需求，里面涉及了很多角色和业务场景，还有一张巨大的流程图。为了让所有人能看懂这个流程图，我就编了一个客户案例，然后还花了很多时间做幻灯片的动画，上面有一个卡通形象，顺着这个流程图移动，每移动到一个点，会停下来，然后跟大家解释在这个流程点上，系统的界面会是什么样子。

那次评审很成功，虽然流程和逻辑非常复杂，但基本上没什么人走神，这是因为大家都可以在具体的用例故事里理解需求和方案。

3. 用自己的态度感染别人

我们上一次的分享中曾经提到过，需求相关文档和会议流程要尽可能的专业严谨。有个重要的目的是让大家郑重其事地对待你的文档和会议议程。

换位思考一下，如果你拿到的是一份非常潦草的文档，以及没有任何议程计划的会议邀请，你也不会为这次评审提前投入什么精力。相反，如果文档严谨准确，会议邀请里写有相对完整的会议议程，或许你本能地就会觉得这是一次“正式而严肃的会议”。

信心也是一样，产品经理在评审时一定要有信心，并且要在评审过程中传递这样的信心。所谓“自信者，人恒信之”，如果你自己都对产品和方案没有信心，整个项目组就会没有主心骨；而且人都很奇怪，他们是否会相信一件事情，通常会取决于是否相信提出这件事情的人。

所以想要让听众相信你的话，最好能让他们先相信你，除了日常建立的影响力和信任之外，在评审过程中表现出来的信念和气势也非常重要。没人愿意跟软蛋合作，尤其是产品经理。

4. 不要为了赢而争吵

需求评审中经常会发生争吵，产品经理站在台上被人挑战，不论是挑战方案还是个人能力，都会让人不太舒服。人在面对挑战和危险的时候，会自动开启战斗或逃跑模式，也就是要么选择对抗，要么选择逃避。开会的时候我们站在台上无所遁形，所以大部分人会本能地选择对抗，也就是开始为自己的方案和想法辩解。

对抗通常会激起更多对抗，很快大家都忘了本来要做什么，只是希望能赢得辩论。一旦大家的目标是赢，争吵就变得毫无建设性。所以说争吵本身不可怕，可怕的是为了捍卫自己而吵。产品经理要对自己的情绪活动敏感，当意识到是因为自尊而开启战斗模式的时候，你需要能尽快刹车。

防止将不同意见升级为争吵的一个办法是用陈述句复述并确认，我举个例子，比如我们正在讲客户服务流程，你说客户来电结束后，需要记录在案并设置下次跟进提醒时间。听众插嘴了，说：“你了解过现在的流程吗，所有的来电都记录提醒时间，服务人员还用不用干别的了？”

这句话可能不太友好，如果你恶向胆边生，回他说：“我看是你不了解流程吧，你知不知道有多少没有及时后续跟进造成的客户投诉？”照着这个趋势，说不了几句应该就要吵起来了。

可是如果你能及时摁住情绪，把态度描述忽略掉，用陈述句去复述提问人的意思，你说：“我理解一下，你是想说，并不是所有的来电都要记录提醒时间”，对方可能还会挑衅，说：“废话，一天一个服务人员平均接两百个电话，你说呢？”

你继续摁住情绪，复述：“所以我理解你的意思是，如果我们要求服务人员为未处理的来电建立提醒，会降低工作效率。”

用这样的风格不断复述的同时，你可以引导他把问题背后的问题说出来。这个过程的目的是通过他的反对找到有建设性的建议，而不是赢得争论。

另外，用这样的方式还可以让提出挑战的人意识到他自己在对话中混杂了情绪，从而被你引导回到冷静讨论的范围中，而不是继续抬杠。不要让情绪影响了判断，更不要让赢得争吵取代做好产品成为你的评审目标。

如果没能控制好情绪，或者发现陷入细节无法自拔了，一定有礼貌地喊停，先搁置争议继续后面的内容，不要浪费其他人的时间。

5. 小公司的需求评审

最后想简单说一下关于小公司、创业团队的需求评审方式。在小公司中，需求评审未必会成为一个仪式化的流程环节。可能是产品经理跟老板聊几句，然后写比较短的文档，或者画个原型，跟工程师面对面交流。

然后工程师在设计开发的过程中，可能还会不断跟产品经理交流，来进一步明确需求，可能需求分析的过程直到产品上线的一刻才最终成型。

这样的工作方式对小团队来说可能是合适的，因为它足够灵活，而且没有流程成本；但我的建议是，小公司可以没有正儿八经的大型需求评审会，但最好要有需求评审的过程。

这个评审可能是跟工程师小范围的需求串讲，也可能是产品经理自己在脑海中对自己的一次模拟评审。不能因为缺乏评审会，就把没有完全想清楚的需求交付给开发，浪费了时间，也影响士气。

总结

到这里，关于需求评审的分享就结束了，需求评审虽然看起来像是一个环节，却影响了需求从产生到实施的整个周期，也是对产品经理基本功、业务了解和情商的一次综合考验。

今天的分享中，我们提到要避免知识的诅咒，以及用引导而不是强迫的方式让相关同事用心投入，之后说到了要利用自己的态度感染他人，并且尽量避免以赢为目的的争吵。希望这些建议，能在你的需求评审中发挥作用。

最后，在此祝福你春节快乐，狗年顺心，能在自己的职业生涯中有新的突破，我们一起加油！

!

戳此获取你的专属海报