参会人员
项目经理、产品经理、前后端开发、测试、（可能还有需求分析师、业务等，一般不在场）
首先我们来看看每个角色于需求评审会议的内心世界
产品眼中的需求评审
1.开需求评审会，意义不大，因为大家都不重视；开完会还得再单独讲一遍，感觉开会时这些开发测试猿不带脑子！
2.宣讲过程，开发猿们在需求评审会上一讨论技术问题就没完没了，将需求评审会开成技术大会，留下我在那里目瞪口呆，要开好几个小时都开不完，还吐槽我文档写的不完整，哪有时间啊！
3.业务负责人和产品线老大基本不在场，具体实际业务我有些事儿也定不了！会后连线说不定需求又变了一个样！
开发眼中的需求评审
1.开始思考该版本中的需求自己目前的技术是否有难度
2.这些需求具体要怎么实现，前后端开始讨论这些数据的是前端自己去拿还是后端传给前端，接着就开启了技术讨论大会，口吐芬芳！
3.事后心里开始吐槽，这些需求真是没经过大脑去想，这怎么实现，顶个产品的光环干吗用？干啥啥不行！
测试眼中的需求评审
1.就拿个改的不完整的旧原型开始了宣讲吗？这不是给我留坑吗，不行！这要求产品补充文档，开启吐槽
2..开始烧脑，目前需求实现的业务与当前版本有没有冲突，这里需求不明不白，不会是个坑吧？
3.这块挺开发讨论的这么激烈，应该负责程度很深吧，测试得多要点时间
看完以上内容，是不是找到了内心的自己
那么我们分析分析问题点在哪里？
1.需求评审的意义和目的产品没有明确
2.产品设计可能不周全，业务需求可能是一时脑热，产品自己也没深思熟虑就端桌，导致需求会议进入尴尬阶段
3.作为会议的发起者会议的内容和时间没有把控好，要会控场；1H会议，硬是搞三个钟！
4.测试开发们宣讲前没做好需求熟悉准备，导致现场听的不明不白，会中没疑问，会后三连问，产品后期还得花时间成本进行逐一讲解
5.产品未涉及实际业务现场实施，勘察业务走向，方向错没错？不能每次让测试开发吐槽"功能一大把，用户不过十"
那么需求评审时期测试到底要做什么呢？
1.需求评审前，提前进行需求熟悉阶段，逐一分析需求点，做好准备，相关需求疑问点列好清单，带着问题去参会。
2.产品宣讲时期，就算过程有问题，不要试探打断产品的宣讲，一是节约时间，二是不礼貌，等产品将一个模块宣讲完毕，开始带着你的问题，开始你的表演，分析给项目成员听，并提出改进建议
3.当需求有问题确认需要修正，或需进一步跟业务确认再做定夺的，做好标记，并提醒产品，做好会议记录
4.开发是个直男~一旦进入技术凯旋，那非得争的明明白白的，所以宣讲时期如果开发进入技术凯旋，在适当时期提醒产品，进行控场，有效的控制时间，接着宣讲其他模块业务流
5.需求评审完后，项目群推送需求评审会议记录点，周知各位目前的版本的疑问点以及修改点，并提醒产品进行下次需求确认会议时间,这个会议也可以由测试主持，