38 | 如何做好需求评审（下）：在评审中控住全场
邱岳
该思维导图由 AI 生成，仅供参考
爆竹声中一岁除，2018 pretty cool。
千门万户曈曈日，all your dreams coming true。
——王安石 & 邱岳
作为产品经理，需求评审时最头疼的事情莫过于参与人都心不在焉，嬉皮笑脸就通过了评审，结果到了项目都快做完了突然又提出问题，这时再返工除了浪费资源，还会打击士气。
除此之外，有的产品经理甚至提到需求评审就紧张，因为经常会有人跳出来挑战产品方案，需求评审会最终演变成争吵掐架会，没有结果产出，大家不欢而散。
上次分享中我们聊到了需求评审的目的和准备工作，今天我分享几个能帮助我们提高评审效率的方法，希望可以给你带来启发。
1. 当心知识的诅咒
我们说到了评审会上大家不能积极参与的情况，通常情况产品经理都会责怪评审会的参与人，觉得他们没有积极投入，缺乏主动性。其实我觉得并不完全是这样，很多时候他们也是有苦难言。
这里要先提到一个叫做“知识的诅咒”的概念，指的是当一个人拥有某种知识之后，就很难想象和模拟出不知道它时的状态，因为陷入这样的状态会影响沟通和表达，仿佛就像受到诅咒一般，所以由此得名。
有个著名的心理学实验，让一组人在限定的范围内选择一首非常简单的曲子，然后在桌面上敲击它的节奏，另一组来猜具体是哪一首，最终结果是只有 2.5% 的听众猜对了曲目，而敲击者在敲打节奏之前，预测这一概率至少是 50%。
你也可以试试，在脑中试想一首旋律，然后手指敲打书桌，这时你会觉得自己敲打出的节奏如此准确清晰，别人不可能听不出来啊；但倘若你把桌面上的敲击声录下来，回放自己听，你就会发现当脑子里没有旋律的时候，这些敲击声就像是一串毫无规律的莫尔斯码。
作为产品经理，对业务和产品细节的了解就像脑海中的旋律，台上的你其实无法想象坐在下面听讲的人的处境。我参加过类似的评审会，虽然抱定全情投入的决心，但产品经理在上面讲不了几分钟，我就完全迷失了。
所以我建议你在做宣讲或者评审需求的时候，要像做产品设计的时候一样，把自己放到听众的上下文中去，把来龙去脉讲清楚。哪怕有一部分听众会觉得你有点啰嗦，也要讲，尽可能从所有人都了解的背景开始讲起，逐渐向外延伸，像讲故事一样。大部分人听到自己已经知道的事情时会有安全感，以此为基础延伸开来，才能让听众感到踏实和好奇，摆脱知识的诅咒。
2. 不要强迫，要吸引
和与人相处一个道理，当听众没有积极参与的时候，我们要做的不是强迫他们，而是引导他们来理解。在需求评审会上引导听众的最有力武器就是“具体”。
先讲个故事，这是我在一本书上看到的，说一个产品经理在公司内部做便携式平板电脑的提案，在上面介绍这个平板电脑的外观、尺寸、数据，说了半天下面的听众一头雾水，鸦雀无声。这时他发现自己随身携带的文件夹的尺寸跟这个产品的设计尺寸很相近，于是灵机一动，把这个文件夹扔到会议桌中间，说：这就是那个平板电脑的样子。
有人拿起那个文件夹端详，然后传给下一个人，终于有人开始发言，并且逐渐演变成了七嘴八舌的热烈讨论，开始提出问题，讨论功能特性。所以你看，一个莫名其妙却足够具体的文件夹，就能帮助所有漂浮在空中虚无缥缈的概念落地。
对于软件产品来说，我们的“文件夹”就是用户场景和用例故事。
为了让听众理解需求和方案，我们最好可以从场景和故事出发，用具体的案例来跟听众沟通，而不是对着文档从头到尾照本宣科。我过去的习惯是，先整体地介绍业务，大的逻辑和背景，然后用一个实际的业务案例把相关的功能和流程串讲一遍，最后回到文档本身，把需求文档从头到尾过一遍。
比如我之前做工单流转的需求，里面涉及了很多角色和业务场景，还有一张巨大的流程图。为了让所有人能看懂这个流程图，我就编了一个客户案例，然后还花了很多时间做幻灯片的动画，上面有一个卡通形象，顺着这个流程图移动，每移动到一个点，会停下来，然后跟大家解释在这个流程点上，系统的界面会是什么样子。
那次评审很成功，虽然流程和逻辑非常复杂，但基本上没什么人走神，这是因为大家都可以在具体的用例故事里理解需求和方案。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
产品经理在日常工作中面临着需求评审效率低下、参与人员不积极等问题。本文提出了三个方法来提高需求评审效率。首先，产品经理需要意识到自己对业务和产品细节的了解可能会让他们难以理解听众的处境，因此在宣讲或评审需求时，要设身处地地讲清楚，避免陷入“知识的诅咒”之中。其次，要通过具体的案例来吸引听众，而不是死板地照本宣科，这样能够让听众更容易理解需求和方案。最后，产品经理在评审过程中要展现出自信和信念，因为听众通常会根据产品经理的表现来判断产品和方案的可信度。此外，文章还提到了在需求评审中避免为了赢而争吵的重要性，以及小公司的需求评审方式。总的来说，需求评审虽然看起来像是一个环节，却影响了需求从产生到实施的整个周期，也是对产品经理基本功、业务了解和情商的一次综合考验。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《邱岳的产品手记》，新⼈⾸单¥59
《邱岳的产品手记》，新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(11)
- 最新
- 精选
听天由己我只能感叹，关于需求评审的每一点都恰到好处，这让我有了更多的信心与武器来面对产品工作。我已经把这几篇文章收藏了，会一步一步去实践起来。 新的一年，我的目标就是成为向二爷一样牛逼的产品经理。 这已经是第 37 篇专栏文章了，我也会继续留言下去。感谢二爷的持续分享，感谢池老师的引见，感谢「极客时间」团队的辛苦付出。 祝大家新年快乐，工作、生活、学习旺旺旺~作者回复: 貌似换头像了 ：P 希望我们都能有突破，有新的收获和成长
2018-02-155
CC今天的文章让我注意到“换位思考”的重要性。 自己踩过几次“知识的诅咒”的坑，就是因为没有换位思考。自己第一次主持评审时，下意识地假设听众和我一样有相关的背景知识，在一开始没有很好的铺垫和交代，导致很短的时间后，听众明显开始迷失。二爷文中“旋律”的类比，感同身受。 这进一步让我想到了“类比”。就像文中提到的“文件夹”一样，类比可以让抽象的事物更具体，提起听众兴趣。同时，类比要选择听众熟悉的事物，能让听众产生安全感，把自己的体验带入思考，会让思维更活跃。 以后如果还有机会主持评审，希望自己能做得更好。感觉由于需求评审流程的存在，也会督促产品经理严谨对待需求，让项目有一个很好的开头。 祝大家的的需求评审都凯旋而归。 感谢二爷在大年三十的更新，祝狗年更旺！作者回复: 加油加油💪
2018-02-151
ly可以具体说一下需求评审按照怎样的方法，讲给开发听，可以让对方理解并且显得自己更专业作者回复: 这个话题挺大的，而且跟你对接开发的风格有关系。 有的开发喜欢完善的文档和细致的交互流程图，但你不要打扰他。有的开发不愿意看文档，喜欢你去位置上边讲边展示线框。 大部分时候不需要考虑显得专业，尽量考虑如何搞定问题。
2019-11-19
张伟“不要让赢得争吵，替代了最终的评审目的”一句话概括了评审中的冲突处理2018-02-225
林彦小公司里翻译老板或需求方的想法，和开发方交待背景，解读场景，把它们拆分成开发放能理解，能认同的具体元素，这个过程在现实中经常缺乏。 技术出身的创业公司老板们是如何在资源紧张，变化迅速的环境中找到一个合适的产品经理的？靠过去的人脉积累拉拢或推荐，靠物色合适的人刻意培养，自己承担部分或大多数产品经理的职责。 很多非互联网公司的从业人员和他们聊天并没有典型的互联网公司的产品经理这种角色，有项目经理，产品线经理。 他们在创业小公司阶段是不是有一个善于翻译用户需求的一线销售/商务，还是有一个明白用户需求，愿意花不少时间与开发执行人员沟通的老板/技术领导，还是开发核心既实现能力强，又情商高，善于沟通，很快抓住非工程领域的问题关键并建立与工程领域的联系。2018-02-153
Dylan避免情绪化地讨论确实很难做到，在实际评审种，我们如若能做到延迟思考，思考对方背后的真正有价值动机，及时表达和沟通，相信可以节约大家很多时间。2018-07-241
Charlse这几期讲的需求评审，包含交互的评审么？ 是只要讲清楚接下来要做什么就好，还是要讲清楚怎么做，包括交互细节等等？2021-09-19- 周竹筠没想到学产品课还学到了情绪管理：不为了维护自尊而开启战斗模式，想想最终希望达到的目的是什么（不是赢得争论保住自尊）。具体方式是用陈述句复述对方的问题并确认。--不仅可以用在需求评审，生活里也是一样。2020-12-07
CatTalk哈哈哈😂，作为开发，每次开需求评审...其他部门的开发几乎从来没有提前了解过需求，除了现场怼产品经理，就是“这个怎么能这么做？....这个做不了！”...怼到最后也没有任何正效的产出，我也是服了，浪费大家时间2018-10-22
彭龙我一般会在之前单个沟通一遍2018-07-27
收起评论