评审是对软件元素或者项目状态的一种
评估手段，以确定其是否与计划的结果保持一致，并使其得到改进。
评审的主要目的是发现产品中的问题，而不是根据产品来评价开发人员的水平。但是往往会出现把产品质量和开发人员水平联系起来的事情，于是评审变了“味”，变成了“批斗大会”，极大的打击了开发人员的自尊心，以至严重的影响了评审的效果。
参与评审需要投入大量的时间和精力，应该被安排进入项目计划中。但是现实的情况往往是，评审变成了“
义务工”，参与评审的人员必须
加班加点才能完成评审任务。如此一来，出现评审人员对评审对象不了解的情况也就不足为奇了。
评审会议主要的目的是发现问题，而不是解决问题，问题的解决是评审会议之后需要做的事情。但是，由于开发人员对技术的追求，评审会议往往变成了问题研讨会，大量的占用了评审会议的时间，导致大量评审内容被忽略，留下无数的隐患。
任何一份评审材料都是他人智慧和心血的结晶，需要花足够的时间去了解、熟悉和思考。只有这样，才能在评审会议上发现有价值的深层次问题。在很多的评审中，评审人员因为各种的原因，在评审会议之前对评审材料没有足够的了解，于是出现了评审会议变成了技术报告的怪现象。
经常会出现这样的问题，在评审中，评审人员过多的关注于一些非实质性的问题，比如文档的格式，措词，而不是产品的设计。出现这样的情况，可能的原因有：没有选择合适的人参加评审；评审人员对评审对象没有足够的了解，无法发现深层次的问题。
在组织评审的过程中，很多人不太注意细节。比如会议时间的设定，会议的通知，会议场所的选择，会场环境的布置，会议设施的提供，会议上气氛的调节和控制等等，而实际上这样的细节会大大影响评审会议的效果。比如，很难想象，大家在一个空气混浊、噪音很大的会议室里面能够全身心的投入。