原型图可以寻找网络资源来学习绘画，需求文档公司一般会有相关模板，产品经理思维培养可以多看书籍，但需求评审会对于产品新人来说就不知道何从下手，别害怕，需求评审会其实很简单，也很容易。
1、什么是需求评审会？
需求评审会就是对需求的评定和审核的一场会议，会议上确定接下来需要做的需求是什么，需求的细节是什么。在需求评审会召开之前，其实需求已经确定了，召开需求评审会之前，已经获得了各位大佬（各板块负责人对做该需求的同意，比如产品总监，技术负责人，运营负责人等）的同意，召开需求评审会是为了走一个过场，让大家不仅仅是大佬们还有执行层面的经理和程序员等知悉接下来要做的事情。
2、为什么需求评审会总是开很久且不高效？
许多公司把需求评审会和需求研讨会混淆，各版块负责人懒惰，产品经理也懒惰，所有的需求都不提前确认做还是不做，这样做行不行，而是等到开需求评审会再说，这就很有可能在需求评审会上需求不通过，改了一版又继续开评审，直到通过为止，这样的行为是最消耗产品经理精力的，这不是需求评审会，这是需求研讨会了。
正确的做法是开需求评审会之前先召开需求研讨会，这个会可以不用所有人参加，只需要关键的几位大佬来参与就可以了，包括技术负责人、需求提供方（运营、老板、销售等）、产品经理、测试负责人即可。产品经理在这一阶段也不用绘制特别消息的原型图，或者只需要流程图加简单的界面就行，因为后面还会有很多改动。
当与各位大佬确定了大方向没有什么问题了之后，才开始一个个页面的细化需求，这样做出来的需求通过率就很高，因为需求评审会的时候，各位大佬已经达成了一直协定，不会因为观点极度不一致而在会上争吵导致拖延了执行层工作者的时间。
3、正确的需求评审会的流程是怎么样的呢？
接到需求后，作为产品er的自己先自己理清楚需求，在脑子里构想一下大概的方案，可能碰到什么困难点，这个就要看经验了，但尽可能想一想，上网查找一些资料都可以，输出一些简单的流程图和几个关键页面原型。
一般比较难召集所有大佬来讨论需求，所以做法是一般自己私下去找相关的负责人去聊需求，先去找技术负责人，跟他说我们准备做这么一个需求，这个需求是怎么怎么样，可以口述也可以给技术负责人看图，问一下技术负责人这么做的可行性，如果不行怎么做才可行。
确认技术负责人认为这个需求的可行性之后，对于一般需求来说，基本大功告成，若一些牵涉到做出这个需求需要增加运营人员工作的情况，则需要和运营主管讨论一下该需求，同运营主管确定这个需求这样做是否可行。
当然最好还可以在召开需求评审会之前和测试负责人通通气，让测试负责人了解情况，这样在召开需求评审会的时候，测试负责人不至于一脸懵B。
以上的工作都做完了，发邮件发通知约各位大佬时间召开需求评审会，会议上则需要出详细的原型图和备注说明，会议阐述需求的对象其实不再是大佬们，而是那些执行层面的人，当然这里指的就是程序员。
会议召开完毕后，一般会有一些需求要改动，但也只是轻微，改动完成之后则把最新的改动后的原型图发给与会的相关人员。
那么整个需求评审会的流程结束。
在需求评审会召开之前，如果有条件就召开需求讨论会，召集各方大佬，但很多情况下条件不允许，这个时候就只能挨个挨个找相关负责人确认。
写在最后
记住需求评审会不是需求研讨会，需求评审会开会之前一定要在前期做好沟通准备工作，一定要取得各方负责人对需求的认可，提前和技术负责人、运营负责人、测试负责人讲清楚这个事情，取得他们的一致同意，需求评审会才会高效顺畅的开展。
