业内公认，评审是最有效的保证质量的手段之一，也是一种结构化的方法，可以对方案、需求、设计、代码等工作产品进行审核，找到缺陷。但我们在实际工作过程中，经常遇到这样的情况。我们的系统已经上线了，需要补一个评审材料，或者现在时间不足了，就不用评审了，直接先做吧。评审就是一种形式，没有什么必要。总之，“评审”，这个项目必不可少的过程，没有很好的得到执行。实际上，在我的项目中，也存在这样的问题，但后来，宁可是走一个过场，也要坚持将这件事做下去，同样，给他人的交付物评审的时候，也尽可能提出自己的想法，并和对方仔细沟通，指出我认为的问题，对本次评审活动负责。
在工作中识别工作缺陷主要分为评审和测试，测试虽然是交付前最重要的活动，但评审更是尽早发现缺陷的方法，进而降低因为缺陷带来的成本。评审包括同行评审和项目评审，同行评审包括走查、轮查和审查，项目评审包括项目组内评审和组织内评审两种方式，并贯穿于整个项目的生命周期，特别是软件项目中，需求评审、设计评审都是极其重要的评审活动。在软件项目中，评审也是CMMI中重要的支持过程。既然是支持过程，所以评审对象通常是方案、文档、计划、过程、交付物结果等。
评审像是一次会议，所以评审也分为准备评审、执行评审和缺陷管理、总结几个部分，也需要有计划、有结果，以及对产生的缺陷进行跟踪。与开会唯一不同的是，评审有一定模式和要求，即按照检查单的评审要素要求，将检查项贯穿到会议中。检查单根据评审的内容不同，检查的要素也不一样。例如，文档是否对接口进行了说明？是否满足安全性的要求？设计是否满足产品的标准化审查？等等。评审的目的不是证明正确，而是去找到那里不对。评审的结果是形成既定表格模式的评审报告。
在评审中，一切以发现工作成果的缺陷为核心开展工作，需要说明的是，评审不是消除缺陷，而是找到缺陷，说明消除缺陷的方法。至于评审人的选择，必须选择熟悉此工作成果的人，才能有的放矢。
最后，即使开一次评审会真的是走形式、走过场，如果能把这次会当作对产品、方案的一次沟通交流，至少也是一次学习和提高的机会。
