项目经理在临近评审时，总会犯评审恐惧症，不知道该不该做评审。选择做评审，担心评审效果不好，和没评审差不多，评审只是浪费时间和精力；选择不做评审，又担心做完不是客户想要的，自己白忙活一场。现在就让我们来了解一下这个病，再对症下药。
病症分为需求评审恐惧、代码评审恐惧、测试用例评审恐惧等，下面我们以需求评审为例具体剖析。
症状表现
失眠多梦，焦躁不安。
病因
???
1.需求文档内容多
需求文档内容很长，在规定的期限内评审人员无法将文档读透，读懂，想清楚；
2.评审准备不足
没有做好前期准备工作，需求评审的效率很低。准备工作包括挑选评审重点，评审通知到评审人员等；
3.评审主持不到位
评审主持人没有把握好会议主题，评审变成了头脑风暴，评审节奏无法控制，很可能会议时间很长，却没有任何收获；
4.评审人员选择错误
没有选择合适的评审人员，评审人员无法提出评审内容深入的问题，无法获得有价值的意见反馈，同时浪费评审人员的时间；
5.评审无依据
评审缺乏有效依据和规范，完全靠评审人员的个人经验进行评审，不能保证评审的覆盖率和有效性；
7.目标需求不明确
目标性需求没有沟通好，后面完成的需求只是劳而无功，此时的需求评审已无任何意义；
8.评审人数过多
将涉及到的人员都邀请来做评审，容易陷入细枝末节的讨论，评审会议时间超出预期，且没评审重点内容。
???
药方
现在就给大家一个独家秘方，值得一试哦。
1.评审流程
建立适合项目的评审流程，按照流程规定进行规范评审。规定中包含活动流转，角色定义，准入准出条件，评审工作成果物，评审时间等。
1）评审准备
①准备评审材料，基础规范检查，圈出评审重点；②确定评审人员及评审形式；③准备评审场所，设备等。
2）评审通知
①给评审相关人员发送评审通知，并线下与评审人员沟通并确认评审人员能够如期参加；②发送评审材料给评审人员，进行预评审。
3）执行评审
组织评审，提出评审意见。
成果物：评审意见表。
4）评审总结
①对于评审意见给出处理方案；②对总结工作进行总结；③评审人对评审报告签字。
成果物:签字后的评审报告、变更申请单。
????
2.分等级进行评审
目的是确定评审人员及评审形式。
1）高阶需求：定义了整个项目的边界范围，主要功能模块；
评审人：项目和客户方对此项目负责的高级管理人员，例如双方销售经理。
评审形式：会议评审，会议次数较少
2）功能需求：定义了整个项目的具体功能，包括功能需求，性能需求，接口需求，数据库需求等。
评审人：项目和客户方的项目经理或小组负责人，其他系统负责人，最好带着测试人员。
评审形式：会议评审，会议次数较多
3）操作性需求：定义了项目所开发的系统具体操作细节的需求
评审人：项目和客户方的具体需求人员
评审形式：面对面沟通，或邮件评审，最好带着测试人员。
总结：对于不同等级的需求执行不同形式的评审，邀请不同的评审人员，令评审工作是有效的，高效的。
????
3.评审时间
此处的评审时间包括2个，1是什么时候评审？2是评审会议或沟通要多久？
1）评审时机
完成一个小模块的需求形成了，就组织一次评审，不要在整体需求完成再评审，内容多，评审会议就会长；一旦发现思路错误，之前的工作就都白做了。
2）评审会议时长
单次最好保持在1.5h以内，时间如果过长，参会人员精神集中度就会下降，会议效率会降低，评审会议中主持人时刻保证评审人员围绕评审重点讨论；评审量也要根据时长进行裁剪。
????
4.对评审员进行培训
评审人员可能是领域专家，但不能保证评审能力也是专家级的，他们没有掌握评审流程、评审方法、评审技巧等。所以可以在评审前进行评审规范宣贯，让评审人员在评审中围绕评审节奏走，提高评审效率。
????
5.巧用评审检查单
评审检查单分2类，评审过程检查和评审工作的检查。
1）评审过程检查
①对需求文档的格式是否符合质量标准来提出的；②评审流程检查，各环节是否规范，检查评审目标是否正确等。
2）评审内容检查
检查需求内容是否达到了系统目标、是否有遗漏、是否有错误等等，这是需求评审的重点。
????
6.做好评审后的跟踪
评审后要对各评审人员提出的意见进行反馈，是接受，还是拒绝，还是再议？不接受时，要给出充分的理由及证据。评审报告要获得评审人员的签字确认，不能白评审了；接受的意见，要进入需求变更流程，计入跟踪项，定期跟踪，需求变更完成，此条意见结束。
????
不良反应
???
做评审上瘾，从此睡得美，吃的香，请控制用药量。
???
本文来自同方软银质量控制事业部，欢迎转载和来稿，欢迎
转载请注明：http://www.dwwaw.com/zlyz/11321.html
