如今在研发流程里，不论大厂小厂，几乎已经普及了需求评审这一环节。需求评审的关键作用，在于让项目的参与者都了解知晓即将实施的项目的各种需求细节。产品人员会在需求评审会上，较详细的介绍产品，大概有多少个功能点，核心功能点包含哪些，哪些细节需要特别留意，哪些功能已经明确，哪些现在还没有确定要不要做，。
通过需求评审，开发人员可以先笼统地形成技术选型，针对模块的设计架构等一系列的规划工作；而测试在知晓功能点以后，会形成关于功能点的测试用例类型的选型。
But，需求评审，是成员中问题最少，但是分歧最多的一个评审会。大家在面对一个迭代项目可能还好，如果是个新项目的话，其实每个人都提不出什么问题，但是心里对于该项目的测试或者开发规划却存在很多的疑问。
我的做法是，要求测试在需求评审会上，把自己对这个产品的功能点复述一次，先让产品人员和测试人员就产品理解达成一致。话术大概是，让测试人员说“我对这个产品的理解，大概是这样这样，这个地方如果是这样的话，我大概会怎么怎么测试，大家看这么做有没有什么问题？”
这样其他成员会立刻发现，测试人员的理解跟自己的理解有没有分歧，如果有的话，就需要立刻说出来达成共识，消除歧义。可能在这个过程中，会陷入拘泥于细节的地步，比如什么提示语啊，按钮放左边还是右边这些小细节上。所以测试人员应该真对大的功能点来做自己理解的描述，某些关键细节如果有必要，或者产品人员考虑不周，可以说出来大家讨论。
如果测试人员对某个功能有不确定性的疑问，一般我会让测试人员追问出来，话术大概是“这个功能点我的理解是这样的，产品人员你觉得这样对不对？跟你的需求是不是一个意思？XX开发你明白了吗？你能不能复述一遍？”对自己有疑问的点，先要说出自己的理解，抛出疑问点，然后征求多方的证实，而不是仅仅局限于产品人员，因为如果测试有疑问，那么可能开发人员也不是很清楚，所以需要开发人员开口说一说这个功能的理解。
我这样追问的作用，在于激活团队每个角色在评审会中的主观能动性，从被动的接受需求，到主动的思考需求，并且形成讨论的氛围，把每个角色都调动起来，从而让需求评审不流于形式。虽然这样会让大家都比较累，但是总比最后开发到一半发现大家对某些模块存在需求阶段的分歧更好。
END.
