作为产品经理，大家都或多或少参加过需求评审，也组织过需求评审。回想自己组织第一次需求评审时，由于紧张，竟然忘记自己之前做的准备了，于是直接打开原型图，对着它巴拉巴拉讲了一大通。结果也就可想而知了。
现场听的人没有搞懂；或者是讲解遗漏关键点，甚至会造成最终的交付产品和原需求相差较大。
需求评审是产品设计开发的一个重要环节，贯穿了产品需求和产品实施的全过程，对于产品最终是否能按时落地起到关键的作用。
所以需求评审的重要性就不言而喻，小编将结合自己的实际经历，介绍一些产品新人该如何做好“需求评审”。
我们做某件事情，可以先去定义这件事情的目的是什么，为实现这个目的我们该怎样去努力。
当你明白了这件事情的目的以后，你才会有对应的努力目标，才知道该如何去努力。
即通过我们将需求以通俗易懂的语言传达给相关研发、设计、测试等人员，达成需求理解的一致，明确接下来的工作该如何去展开。
研发同学会就需求的实现方面重点讨论，另一方面UI同学就设计页面的需要注意的几点做确认，而测试人员大多会就系统的边界做补充说明。
知道了目标和不同的工作的侧重点，下一步就要为实现这个目标，设定关键路径，这也是产品能成果交付的必经之路。
无论你将要面对的是谁，提前准备好，才可以帮助我们稳定全场。这里我结合我自身实践经验，总结了一份准备事项。
在开始之前，首先明确讲解的材料有哪些？这些材料讲解的顺序是什么？材料讲解的侧重点是什么？
需求宣讲的材料，是我们讲解的依据，我们先要把准备材料做足。才能让我们把客户的需求通过思维导图、原型图等更好地传达出来。
比如，我们需要先用思维导图去把功能架构进行整体概述；然后通过原型图详细说明，在讲解原型中，会借助流程图、状态图等加以补充，这样将我们准备的材料很好得组合起来，才能够游刃有余的掌控自己的讲解内容，相关的同事也才能够更清晰明了。
在正式宣讲之前，需要事先声明你想要宣讲的形式，是整体讲解完，再答疑；还是边讲解，边答疑；或者讲解和讨论结合。
当然这要根据项目而异，比如，只是开发一个功能模块，不复杂，可以先整体讲完，让团队成员把问题记录，后续一并作答。
宣讲的形式，是能够让你掌控自己的讲解节奏，不至于经常性被打断，导致需求讲解拖沓，影响整个会议效，这里推荐学习《六顶思考帽》让我们如何做会议的主导者。
我们要讲解需求，不管是面对的是一个全新的系统，还是在原有系统上迭代功能，或者是增加新的模块，我们大体都可以从背景-整体系统框架—详细原型讲解—问题答疑的过程，实现我们的讲解目标。
当然，我们真正去实操时，可能还是会有些疑虑，我们要怎样讲解显得更为专业和完整呢？
需求的宣讲，介绍需求的用户的背景，这点很重要。让研发及测试人员能清楚知道用户的需求。
系统是用来做什么的、主要使用户得到满足哪些需求、能给公司创造什么样的价值等，使开发及测试人员的工作目标很明确，也能从全局角度去考虑系统的价值。
整体系统框架的讲解，一般是通过导图呈现，比如信息架构图和功能结构图，将功能以结构化的形式分块讲解，并且通过信息架构图，将功能进行归类，让研发人员对系统概貌有一个了解，这里不需要将规则、功能定义详细讲解，具体的留到讲解原型时去说明，这样更直观。
最后是系统原型的详细讲解，原型内容越详细其实是越有利的，每个公司要求的原型颗粒度不同。
根据不一样的情况将原型细化做标注。那么讲解的时候，是不是需要把所有标注的内容都讲解到？
如果在宣讲时有遗漏，即便是原型上有标注，研发人员也有看不到的时候，这绝对是血的经验。
当然，如果需求内容多，可分开多次宣讲。其次在讲解时，也要分开重难点，对于大家容易理解，众所周知的的需求可以简单带过。
当然在这整个过程，会发生很多不可控的事情，所以一定要保持平常心，这里有几个小tips分享给大家：
因为原型内容相对较多，要注意讲解模块的节奏，给大家留有一定的思考时间。
讲解时要注意语速和语调的变化起伏，就像我们上课听老师讲课一样，我们也会常常走神，一样的道理，要让你的讲解有起伏，从听觉上是一种享受。
需求讲解，为了让内容更为丰富化和趣味化，可以以用户故事的形式来去讲解，一个个小故事串联起整个系统。
要放平心态，要知道需求的设计不可能是完美无缺的，我们有可能存在逻辑漏洞，我们也有一定的可能在讲解时做不到面面俱到，会存在一些隐含的需求未被讲解出来等等。我们在需求宣讲和答疑的时候，需要做的是收集项目组成员的问题，然后补充到自己的原型设计里面。
当然整一个完整的过程可以总结为辅助答疑式宣讲，会有头脑风暴时刻，交互交锋，像极了切磋才艺的战场，我们要从心态上保持开放、接纳、期待，才能从这场战役中获胜。
当然需求宣讲，其实是一个多方面锻炼自己的很好的方式，包括自己演讲、沟通、控场能力、思辨能力等，还能在这样的一个过程中，吸收UI设计思维、开发思维、测试思维等。
当前位置: 
