项目中用到的检查单一般有两种，一种是过程检查单，一种是工作产品检查单。很明显，过程检查单是对工作过程的检查，工作产品检查单是对工作产品的检查。但不管是哪种检查单，对使用者都有一个基本的要求：能根据实际情况得出检查结果。

　　但在现实中，经常遇到这样的情况，做QA的既不懂技术也不懂业务，懂业务、懂技术的又不做QA，而公司通过了CMMI的几级几级，为了保住证书又必须有QA的角色和检查结果，该怎么办呢？

　　办法一：所有检查单的使用者都是QA

　　方法一是很多公司都使用的方法，那么到底有什么优缺点呢？

　　优点：项目组的人不需要了解检查表是干什么用的，更不需要明白怎么用，只要专心做项目，必要的时候配合检查，并在被检查出问题的时候进行更正即可。

　　缺点：QA经常不懂业务也不懂技术，很多工作产品的检查项根本无法得出检查结果，这时候，QA一般有两种做法，一种是不懂装懂，随便得出一个结果，反正这个结果只要项目组的人不反对，也不会有人说什么；另一种是比较敬业的QA，知道自己不明白，所以会与项目组中明白的人一起，得到检查结果，这时候的检查结果是比较真实可信的，但又占用了项目组中项目成员的时间，相当于又做了一遍同行评审。而且QA一般会选择项目中的“专家”帮忙，更是无形中增加了成本。

　　方法二：分工合作，各展所长

　　其实，项目中使用检查单无非是为了检查项目过程或工作产品是否满足公司要求或满足项目要求，而这个目标，与项目目标在本质上是一致的。而且，检查单也并不全是给QA用的。弄明白了这两点，接下来的事情会容易的多。

　　在我曾经经历过的一家对日外包、CMMI 3级的软件公司中，检查单是这样用的：

　　检查单分三种，一种是项目组成员自检用的，一种是小组长用的，一种是QA用的，项目经理可以根据需要，随意选择使用。

　　自检用的检查单是在每个人做完自己的工作时用的，编码、设计、需求、测试都有，检查单中包括产品检查单和过程检查单。这个检查单的粒度很细，细到代码中的换行、设计中的每页行数、打印格式是否设置、光标是否停在第一个格中、编码完成之后是否通过了编译等等。

　　小组长用的检查单偏重于工作产品的检查，而且粒度稍粗，不是每个工作产品都检查，有一定的抽查比例，而且检查单上要写明抽查的是哪些，检查结果如何等。

　　QA的检查单偏重于过程检查单，主要是什么事情做没做，工作产品检查单也大多是定性的检查，只要判断有还是没有可以了。具体在有的情况下做的怎么样，则是小组长和具体负责人的事。

　　这样通过分工合作，完成了对项目所有工作产品和过程的检查。

　　优点是，不存在让不专业的人做专业的事，浪费时间和精力且没有好的结果的现象。而且前期的工作做的比较细致，大大降低了后期出现bug后的修复成本。

　　缺点是，项目组需要在前期的检查上投入比较大的时间和精力。对很多国内的软件公司来说，老板急着看到工作成果，不管有多少bug，先给我个能将着用的东西才是主要的。这种情况下，与其期待着不专业的人做出专业的事，不如直接将这部分工作省掉，或者让专业的人去做，哪怕粒度粗一点。