项目过程的初期一项重要的工作就是评审需求，每个公司或者团队可能都有自己的一套流程、方案，但有效的需求评审，离不开产品和研发的共同参与。本文所分享的方案主要是针对这一轮或若干轮产品、研发共同参与的评审。
这样的需求评审在研发侧往往只有研发主管尽心去了解了具体的需求细节，在研发参与需求评审的会议上，大部分研发的同学也像走马观花一边纯粹听了一遍产品的同学朗读需求文档，事后开发的时候又发现很多细节问题，有没有？？
下面是要给大家分享的一个方案，这个是我在我们项目组中推行实践过的方案。
其实说起来很简单，就是把需求评审会议上的角色转换一下，让研发的同学来讲解需求文档，让产品的同学来听。貌似每个产品的同学听到这个方案都是先叫好的，好像是让他们从这个会议的朗诵角色中解脱了，负担轻了一大截似的。其实，应该说产品的同学负担会更重了。
那么下面讲讲实施细则
1.要求研发的同学在评审之前仔细阅读需求文档并有所思。一般到了研发参与评审的阶段，需求文档已经包括了相当的细节。而研发的同学应该有自己的思想，要能够挑出文档中的问题，能够做到有效的补充。这对于研发的同学来说是提高了要求。在我们团队实施这一方案的初期，由于团队规模本就不大（5人以下），所以当时我给出的要求是每个人都要熟悉我们负责部分的需求，要能提出有效的问题，评审时随机挑选一名同学来进行讲解，讲解完后其他同学的问题也可以提出。对于规模稍大的团队可能需要做些修改，可以把需求切割，再把团队切割（3人一组也许比较好），照例还是要求一部分人必须熟悉至少一块需求。这样做的目的主要是由一种压迫感“强制”研发侧的同学去思考产品需求，后面应当逐步转化为“自觉”的去思考才算达到了目的。
2.文档的要求，研发的同学需要时间来熟悉文档，哪怕让他看一遍可以在上下班的路上来思考，但起码应该在评审的前一天就有文档发到研发手里，让研发的同学可以开始熟悉需求。具体的哪些方面应该细节化，哪些方面可以延时细节化，视研发和产品直接的配合习惯来确定，这方面需要产品的同学把握。
3.会议中对产品同学的要求，不要认为研发的同学去讲解，产品的同学就没事可做了，相反，产品的同学可能要做的事情更重要了，产品的同学需要用心聆听研发同学的讲解，尽量尽早的发现研发同学对于需求的误解。而研发同学也往往会让产品的同学更清楚得认识到哪些功能可能是暂时行不通的，甚至研发的同学还可能给产品的同学提供新的思路。
当然各个团队自己的评审需求的流程可能都不一样，可以根据自己的需要来做调整。这个方案在我们团队经历的项目过程中实施，个人感觉还是有效果的，没有消灭研发过程中再去发现细节问题，但有效的减少了此类问题，特别是误解。
最新内容请见作者的GitHub页：http://qaseven.github.io/
