引子
因为新华书店网上商城要将业务拓展到自营非图、电子书及第三方店铺，我们后台小组最近在梳理相关的业务需求。我所负责的订单系统模块今天参加了公司内部的需求评审，但是评审到一半就被勒令停止，要求回去梳理流程图，节后再参加评审。
需求评审理应是一个产品经理最辉煌的时刻，但是我这次却搞糟了，会后与各路人马沟通交流，做了一个简单复盘，梳理清楚了需求评审的正确姿势。
一、需求评审的目的
1、帮助团队明确需求
一般公司都是各产品线的产品经理分别负责某个模块，为了让团队各成员明确产品经理在做什么，做到了什么阶段，是不是合理，需要组织大家进行一场需求讨论，从而让接下来要做的需求更加清晰、合理。
2、找出设计缺陷，进行方案对比
产品经理在考虑问题的时候不可避免会出现一些纰漏或者不合适的地方，特别是对于后台产品经理，如对相关技术实现不了解，设计出来的方案技术实现成本太高或者造成系统执行效率太低，这些产品经理不经意间的设计缺陷会在需求评审会上暴露无疑。通过让各团队成员参与讨论，从而及时调整相关方案，尽量找到最优解。
3、让研发同学评估开发的工作量
需求确定了，对于没有做过研发的产品经理，很难准确评估出相应的工作量。一枚合格的产品经理应该优先解决那些开发成本低但是重要且紧急的需求，确定开发工作量后，产品经理可以据此进行需求优先级的调整，从而让产品迭代走向一个正向的循环。
二、一个坏的需求评审例子
引子中的例子就是一个坏到极致的例子，此生都不想再犯了。分析一下这个例子，具有如下几点特性：
1、评审无条理，让与会人员懵逼
在需求评审之前，只准备了脑图，并没有将业务逻辑用泳道图进行描述。因为是新业务，再加之订单模块极度复杂，所以只依据脑图讲解一定会让人觉得无条理，一脸懵逼。
2、开始就讲细节，没有让与会人员对模块建立全局认知
没有流程图，如果讲解时思路清晰，也能弥补没有流程图的缺陷。但是，如果一上来就深入到细节中，与会人员会抓不住重点，跟不上思路，不知所云。需求评审到了这一步就真的是万劫不复了，没有别的办法，只能接受批评回去好好反思。
3、讲解时吞吞吐吐，没有自信
主要还是前期准备不充足，导致评审当天不够自信，直接就被人打上了“不靠谱”的标签。这样其实很危险，时间久了团队成员会对自己产生不信任，以后即使是自己做得好了也很难被认可，以后工作推动起来就会极其困难。
三、合适的需求评审姿势
1、会前准备
提前准备业务流程图、脑图等评审当天需要用到的文件。重要性前文已经强调过，这里不再赘述。
提前2天把文件发给与会人员。主要目的是让与会人员提前熟悉评审当天需要用到的材料，大概知道评审当天要一起讨论的重点内容，以避免无效会议。
提前排练。类似于演讲前的预演，主要是让自己熟悉评审内容，用合适的语言、语速表达清楚主要观点，让听众更容易理解，同时也会让自己更加自信。
与重要人员私下沟通。一般会议活跃的就那么几个人，提前1天找他们沟通，能解决大部分问题，能够提高需求评审时的效率。例如我们本次需求梳理是先与后台小组一起进行局部评审，之后再拉上产品总监及各部门相关人员进行正式的评审，至少提升3倍的工作效率。
2、会中评审
评审当天要先做好前戏，再深入细节。通过PPT、流程图等工具，先让与会人员了解清楚背景及主要的业务流程，再深入到需求的细节中去。这时候正是产品经理舌战群师，创造辉煌的时刻。会中一定要针对具体需求讨论清楚，并要求研发给出工作量评估，产品排好优先级。
记录讨论要点。会议中难免会有一些问题存在争议，难免会有设计纰漏，对于这些争议问题及纰漏，一定要记录清楚，不然会后可能就很难追溯。
3、会后善后
同步会议记录。互联网公司一定要注重信息同步，对于会上记录的重点内容，会后一定要整理清楚并同步给相关人员。好处有3：能够帮助自己不断积累声誉；能够增强团队的目标感；能够帮助团队成员节省时间。
修改相关文件并同步与会人员。经过需求评审讨论，肯定有一堆内容需要修改，会后脑图、流程图、原型等相关产出文件，该改的改，然后及时同步给与会人员。另外，在同步给团队成员时可以预约下次需求评审的时间，让大家感受到原力与自己同在！
可以发现，本文在会前准备方面着墨较多，“台上三分钟，台下十年功”，准备工作做充足了，至少在评审过程中产品经理能够hold得住场。这样良性的需求评审多来几次，产品经理会热爱上这份神奇的工作，团队成员也会对产品经理产生更多的信任，团队所负责的产品也会蒸蒸日上。
以上！
部分内容来自三节课上课时的笔记。
