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

Feb 15, 2018

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



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

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

2018-02-15 邱岳来自北京

《邱岳的产品手记》

课程介绍



讲述：邱岳

时长14:11大小8.11M



爆竹声中一岁除，2018 pretty cool。
千门万户曈曈日，all your dreams coming true。
——王安石 & 邱岳
作为产品经理，需求评审时最头疼的事情莫过于参与人都心不在焉，嬉皮笑脸就通过了评审，结果到了项目都快做完了突然又提出问题，这时再返工除了浪费资源，还会打击士气。
除此之外，有的产品经理甚至提到需求评审就紧张，因为经常会有人跳出来挑战产品方案，需求评审会最终演变成争吵掐架会，没有结果产出，大家不欢而散。
上次分享中我们聊到了需求评审的目的和准备工作，今天我分享几个能帮助我们提高评审效率的方法，希望可以给你带来启发。
1. 当心知识的诅咒我们说到了评审会上大家不能积极参与的情况，通常情况产品经理都会责怪评审会的参与人，觉得他们没有积极投入，缺乏主动性。其实我觉得并不完全是这样，很多时候他们也是有苦难言。
这里要先提到一个叫做“知识的诅咒”的概念，指的是当一个人拥有某种知识之后，就很难想象和模拟出不知道它时的状态，因为陷入这样的状态会影响沟通和表达，仿佛就像受到诅咒一般，所以由此得名。
有个著名的心理学实验，让一组人在限定的范围内选择一首非常简单的曲子，然后在桌面上敲击它的节奏，另一组来猜具体是哪一首，最终结果是只有 2.5% 的听众猜对了曲目，而敲击者在敲打节奏之前，预测这一概率至少是 50%。
你也可以试试，在脑中试想一首旋律，然后手指敲打书桌，这时你会觉得自己敲打出的节奏如此准确清晰，别人不可能听不出来啊；但倘若你把桌面上的敲击声录下来，回放自己听，你就会发现当脑子里没有旋律的时候，这些敲击声就像是一串毫无规律的莫尔斯码。
作为产品经理，对业务和产品细节的了解就像脑海中的旋律，台上的你其实无法想象坐在下面听讲的人的处境。我参加过类似的评审会，虽然抱定全情投入的决心，但产品经理在上面讲不了几分钟，我就完全迷失了。
所以我建议你在做宣讲或者评审需求的时候，要像做产品设计的时候一样，把自己放到听众的上下文中去，把来龙去脉讲清楚。哪怕有一部分听众会觉得你有点啰嗦，也要讲，尽可能从所有人都了解的背景开始讲起，逐渐向外延伸，像讲故事一样。大部分人听到自己已经知道的事情时会有安全感，以此为基础延伸开来，才能让听众感到踏实和好奇，摆脱知识的诅咒。
2. 不要强迫，要吸引和与人相处一个道理，当听众没有积极参与的时候，我们要做的不是强迫他们，而是引导他们来理解。在需求评审会上引导听众的最有力武器就是“具体”。
先讲个故事，这是我在一本书上看到的，说一个产品经理在公司内部做便携式平板电脑的提案，在上面介绍这个平板电脑的外观、尺寸、数据，说了半天下面的听众一头雾水，鸦雀无声。这时他发现自己随身携带的文件夹的尺寸跟这个产品的设计尺寸很相近，于是灵机一动，把这个文件夹扔到会议桌中间，说：这就是那个平板电脑的样子。
有人拿起那个文件夹端详，然后传给下一个人，终于有人开始发言，并且逐渐演变成了七嘴八舌的热烈讨论，开始提出问题，讨论功能特性。所以你看，一个莫名其妙却足够具体的文件夹，就能帮助所有漂浮在空中虚无缥缈的概念落地。
对于软件产品来说，我们的“文件夹”就是用户场景和用例故事。
为了让听众理解需求和方案，我们最好可以从场景和故事出发，用具体的案例来跟听众沟通，而不是对着文档从头到尾照本宣科。我过去的习惯是，先整体地介绍业务，大的逻辑和背景，然后用一个实际的业务案例把相关的功能和流程串讲一遍，最后回到文档本身，把需求文档从头到尾过一遍。
比如我之前做工单流转的需求，里面涉及了很多角色和业务场景，还有一张巨大的流程图。为了让所有人能看懂这个流程图，我就编了一个客户案例，然后还花了很多时间做幻灯片的动画，上面有一个卡通形象，顺着这个流程图移动，每移动到一个点，会停下来，然后跟大家解释在这个流程点上，系统的界面会是什么样子。
那次评审很成功，虽然流程和逻辑非常复杂，但基本上没什么人走神，这是因为大家都可以在具体的用例故事里理解需求和方案。
3. 用自己的态度感染别人我们上一次的分享中曾经提到过，需求相关文档和会议流程要尽可能的专业严谨。有个重要的目的是让大家郑重其事地对待你的文档和会议议程。
换位思考一下，如果你拿到的是一份非常潦草的文档，以及没有任何议程计划的会议邀请，你也不会为这次评审提前投入什么精力。相反，如果文档严谨准确，会议邀请里写有相对完整的会议议程，或许你本能地就会觉得这是一次“正式而严肃的会议”。
信心也是一样，产品经理在评审时一定要有信心，并且要在评审过程中传递这样的信心。所谓“自信者，人恒信之”，如果你自己都对产品和方案没有信心，整个项目组就会没有主心骨；而且人都很奇怪，他们是否会相信一件事情，通常会取决于是否相信提出这件事情的人。
所以想要让听众相信你的话，最好能让他们先相信你，除了日常建立的影响力和信任之外，在评审过程中表现出来的信念和气势也非常重要。没人愿意跟软蛋合作，尤其是产品经理。
4. 不要为了赢而争吵需求评审中经常会发生争吵，产品经理站在台上被人挑战，不论是挑战方案还是个人能力，都会让人不太舒服。人在面对挑战和危险的时候，会自动开启战斗或逃跑模式，也就是要么选择对抗，要么选择逃避。开会的时候我们站在台上无所遁形，所以大部分人会本能地选择对抗，也就是开始为自己的方案和想法辩解。
对抗通常会激起更多对抗，很快大家都忘了本来要做什么，只是希望能赢得辩论。一旦大家的目标是赢，争吵就变得毫无建设性。所以说争吵本身不可怕，可怕的是为了捍卫自己而吵。产品经理要对自己的情绪活动敏感，当意识到是因为自尊而开启战斗模式的时候，你需要能尽快刹车。
防止将不同意见升级为争吵的一个办法是用陈述句复述并确认，我举个例子，比如我们正在讲客户服务流程，你说客户来电结束后，需要记录在案并设置下次跟进提醒时间。听众插嘴了，说：“你了解过现在的流程吗，所有的来电都记录提醒时间，服务人员还用不用干别的了？”
这句话可能不太友好，如果你恶向胆边生，回他说：“我看是你不了解流程吧，你知不知道有多少没有及时后续跟进造成的客户投诉？”照着这个趋势，说不了几句应该就要吵起来了。
可是如果你能及时摁住情绪，把态度描述忽略掉，用陈述句去复述提问人的意思，你说：“我理解一下，你是想说，并不是所有的来电都要记录提醒时间”，对方可能还会挑衅，说：“废话，一天一个服务人员平均接两百个电话，你说呢？”
你继续摁住情绪，复述：“所以我理解你的意思是，如果我们要求服务人员为未处理的来电建立提醒，会降低工作效率。”
用这样的风格不断复述的同时，你可以引导他把问题背后的问题说出来。这个过程的目的是通过他的反对找到有建设性的建议，而不是赢得争论。
另外，用这样的方式还可以让提出挑战的人意识到他自己在对话中混杂了情绪，从而被你引导回到冷静讨论的范围中，而不是继续抬杠。不要让情绪影响了判断，更不要让赢得争吵取代做好产品成为你的评审目标。
如果没能控制好情绪，或者发现陷入细节无法自拔了，一定有礼貌地喊停，先搁置争议继续后面的内容，不要浪费其他人的时间。
5. 小公司的需求评审最后想简单说一下关于小公司、创业团队的需求评审方式。在小公司中，需求评审未必会成为一个仪式化的流程环节。可能是产品经理跟老板聊几句，然后写比较短的文档，或者画个原型，跟工程师面对面交流。
然后工程师在设计开发的过程中，可能还会不断跟产品经理交流，来进一步明确需求，可能需求分析的过程直到产品上线的一刻才最终成型。
这样的工作方式对小团队来说可能是合适的，因为它足够灵活，而且没有流程成本；但我的建议是，小公司可以没有正儿八经的大型需求评审会，但最好要有需求评审的过程。
这个评审可能是跟工程师小范围的需求串讲，也可能是产品经理自己在脑海中对自己的一次模拟评审。不能因为缺乏评审会，就把没有完全想清楚的需求交付给开发，浪费了时间，也影响士气。
总结到这里，关于需求评审的分享就结束了，需求评审虽然看起来像是一个环节，却影响了需求从产生到实施的整个周期，也是对产品经理基本功、业务了解和情商的一次综合考验。
今天的分享中，我们提到要避免知识的诅咒，以及用引导而不是强迫的方式让相关同事用心投入，之后说到了要利用自己的态度感染他人，并且尽量避免以赢为目的的争吵。希望这些建议，能在你的需求评审中发挥作用。
最后，在此祝福你春节快乐，狗年顺心，能在自己的职业生涯中有新的突破，我们一起加油！

分享给需要的人，Ta购买本课程，你将得18元

生成海报并分享

赞 4

提建议

37 | 如何做好需求评审（上）：需求评审不只是一次会议

39 | 产品案例分析：SeatGeek的订票设计

 写留言

精选留言(11)

听天由己
2018-02-15
我只能感叹，关于需求评审的每一点都恰到好处，这让我有了更多的信心与武器来面对产品工作。我已经把这几篇文章收藏了，会一步一步去实践起来。新的一年，我的目标就是成为向二爷一样牛逼的产品经理。这已经是第 37 篇专栏文章了，我也会继续留言下去。感谢二爷的持续分享，感谢池老师的引见，感谢「极客时间」团队的辛苦付出。祝大家新年快乐，工作、生活、学习旺旺旺~
展开
作者回复: 貌似换头像了：P 希望我们都能有突破，有新的收获和成长
5
张伟
2018-02-22
“不要让赢得争吵，替代了最终的评审目的”一句话概括了评审中的冲突处理
4
林彦
2018-02-15
小公司里翻译老板或需求方的想法，和开发方交待背景，解读场景，把它们拆分成开发放能理解，能认同的具体元素，这个过程在现实中经常缺乏。技术出身的创业公司老板们是如何在资源紧张，变化迅速的环境中找到一个合适的产品经理的？靠过去的人脉积累拉拢或推荐，靠物色合适的人刻意培养，自己承担部分或大多数产品经理的职责。很多非互联网公司的从业人员和他们聊天并没有典型的互联网公司的产品经理这种角色，有项目经理，产品线经理。他们在创业小公司阶段是不是有一个善于翻译用户需求的一线销售/商务，还是有一个明白用户需求，愿意花不少时间与开发执行人员沟通的老板/技术领导，还是开发核心既实现能力强，又情商高，善于沟通，很快抓住非工程领域的问题关键并建立与工程领域的联系。
展开
3
Dylan
2018-07-24
避免情绪化地讨论确实很难做到，在实际评审种，我们如若能做到延迟思考，思考对方背后的真正有价值动机，及时表达和沟通，相信可以节约大家很多时间。
1
CC
2018-02-15
今天的文章让我注意到“换位思考”的重要性。自己踩过几次“知识的诅咒”的坑，就是因为没有换位思考。自己第一次主持评审时，下意识地假设听众和我一样有相关的背景知识，在一开始没有很好的铺垫和交代，导致很短的时间后，听众明显开始迷失。二爷文中“旋律”的类比，感同身受。这进一步让我想到了“类比”。就像文中提到的“文件夹”一样，类比可以让抽象的事物更具体，提起听众兴趣。同时，类比要选择听众熟悉的事物，能让听众产生安全感，把自己的体验带入思考，会让思维更活跃。以后如果还有机会主持评审，希望自己能做得更好。感觉由于需求评审流程的存在，也会督促产品经理严谨对待需求，让项目有一个很好的开头。祝大家的的需求评审都凯旋而归。感谢二爷在大年三十的更新，祝狗年更旺！
展开
作者回复: 加油加油💪
1
Charlse
2021-09-19
这几期讲的需求评审，包含交互的评审么？是只要讲清楚接下来要做什么就好，还是要讲清楚怎么做，包括交互细节等等？
周竹筠
2020-12-07
没想到学产品课还学到了情绪管理：不为了维护自尊而开启战斗模式，想想最终希望达到的目的是什么（不是赢得争论保住自尊）。具体方式是用陈述句复述对方的问题并确认。--不仅可以用在需求评审，生活里也是一样。
ly
2019-11-19
可以具体说一下需求评审按照怎样的方法，讲给开发听，可以让对方理解并且显得自己更专业
作者回复: 这个话题挺大的，而且跟你对接开发的风格有关系。有的开发喜欢完善的文档和细致的交互流程图，但你不要打扰他。有的开发不愿意看文档，喜欢你去位置上边讲边展示线框。大部分时候不需要考虑显得专业，尽量考虑如何搞定问题。
CatTalk
2018-10-22
哈哈哈😂，作为开发，每次开需求评审...其他部门的开发几乎从来没有提前了解过需求，除了现场怼产品经理，就是“这个怎么能这么做？....这个做不了！”...怼到最后也没有任何正效的产出，我也是服了，浪费大家时间
彭龙
2018-07-27
我一般会在之前单个沟通一遍
刘世芬
2018-07-18
二爷，一个完整的需求，用户提交的需求信息应该包含哪些内容信息？需求分析应该从哪几方面入手？

