如何建立有效的QA组织

申请免费试用、咨询电话：400-8352-114

一、 概述

　　许多企业在建立研发管理体系时，尤其是实施CMMI时，都需要建立一个QA组织。但由于缺乏经验和指导，只能摸着石头过河，先从各个部门抽调一些新人和“闲人”成立一个部门，按照规范要求试试再说。这样尝试的结果，往往是走了弯路，一切回到原点。

　　还有一些企业已经成立了QA部门，QA的职责就是保证过程体系一板一眼地得到严格执行。而研发人员却认为QA只会站在研发环节之外指手画脚，像警察一般指责研发人员的不是。而QA人员对此也相当委屈，“我是照章办事啊”，得罪了人不说，还可能对自己的工作内容感到迷惘。这样的QA部门，在其它部门的眼中“可有可无”，在老板的眼中是“白白增加了管理成本”。

二、QA在不同组织结构中的组织形式

　　质量体系的建设是一个系统工程，它存在的形式不仅是一套质量体系文件和质量管理部，它更体现为一个企业的质量文化和质量文化在企业的贯彻实施。软件企业在规划质量体系时往往会选择一个模型，如ISO9000、CMMI、XP等。具体选择何种模型，还要看企业的实际情况，充分协调人、技术、过程三者之间的关系，使质量体系能够充分发挥作用，促进企业生产力的发展。质量文化的形成和贯彻实施与QA组织的人员构成、角色定位有着密切的关系。同时，不同企业的各种组织结构也影响着QA组织的建立和作用。根据对一些企业实际情况的调查，以下分别介绍职能型组织结构和矩阵型组织结构中，QA组织的区别和各自的优缺点。

　　 1. 职能型组织结构中的QA组织

　　 在职能型组织结构中，各个职能部门可能会设立自己的QA岗位。QA独立于项目组，直接向部门主管报告，但在业务上也向项目经理进行汇报。如图1所示。在职能型组织结构下QA组织的优点是：因为同属于一个部门，QA人员容易深入项目组的具体工作，容易发现项目的实际问题，项目组对问题的处理也更快捷。缺点是各职能部门相对独立，部门之间缺乏经验的交流和共享。不同部门还可能重复进行过程、方法和工具的研究。而且，企业中普遍存在“重业务，轻过程”的现象，QA的工作与业务工作相比显得无足轻重，QA人员的职业发展更容易受到忽视，很难接受应有的培训和提升。

　　　　　　　　　　　图1 职能型组织结构下的QA组织

　　2. 矩阵型组织结构中的QA组织

　　在矩阵型组织结构中，企业设立了专门的质管部，QA人员由质管部指派到各个项目组。QA独立于项目组和职能部门，在行政上向QA经理报告，业务上向项目经理报告。如图2所示，在矩阵型组织结构中，项目经理对QA的工作绩效有建议权，但由QA部经理对QA进行直接考评，这既有利于保证QA工作的独立性和评价的客观性，也可以保证QA组织的长期利益与项目的短期利益之间的平衡。QA资源的分配是根据项目特点、工作量和进度而确定的，同时考虑项目优先级，对QA人员进行动态调配，保证更加充分地利用资源。一个软件QA通常可以负责5个左右的软件项目的质量保证工作，硬件QA可以负责2、3个项目的工作。

　　此外，由于QA人员直接面对项目组开展工作，非常了解过程运行的情况，更容易发现过程改进的“短板”，所以QA是改进过程实施的重要推动力量。因此，许多企业的质管部还担负了组织级质量体系的优化、过程资产库和度量数据库的建立、维护和使用的职能。质管部甚至还可能包括了企业级IT系统规划、建立和推广实施的职能。这种情况下，质管部成为QA人员的资源池，一方面负责为项目输送QA人员，另一方面关注培养QA人员。可以有效避免职能型组织结构中不同部门重复投资于质量体系、忽视QA职业发展的问题。

　　在矩阵型组织结构中也有一个问题，由于QA和项目组分别向不同的领导负责，因此相对而言，QA较难融入项目组深入发现问题，而且可能常常遇到QA与项目经理很难就一个问题是否成其为问题而达成共识的扯皮情况。对于这种情况，可以通过问题的“上报”机制来解决，即对于QA与项目组协商后仍不能解决的问题，QA可以直接报告职能部门主管和质管部经理，通过高层协商和协调资源来寻求问题的解决。

　　　　　　　　　　图2 矩阵型组织结构下的QA组织

三、QA的三大角色和职责

　　 1. QA的三大角色

　　CMMI标准文件说，QA是高级经理的“ears and eyes”。研发人员眼中的QA往往也是“警察”， QA的作用似乎仅限于发现和报告项目的问题。其实，一个合格的QA在项目中会充当三种角色：

　　　　 角色1-老师，具备学习和培训的能力。

　　　　 角色2-医生，通过度量数据对项目过程进行诊断，帮助分析原因，开处方。

　　　　 角色3-警察，以企业流程为依据，但要告诉大家流程背后的原因；如果和项目组针对某些问题意见相左，可以直接汇报高层。

　　 典型的QA的职责包括了：过程指导、过程评审、产品审计、过程改进、过程度量。

　　◆ 老师的角色——在项目前期，QA辅助项目经理制定项目计划，包括根据质量体系中的标准过程裁剪得到项目定义的过程，帮助项目进行估算，设定质量目标等；对项目成员进行过程和规范的培训以及在过程中进行指导等。

　　◆ 警察的角色——在项目过程中，QA有选择性地参加项目的技术评审，定期对项目的工作产品和过程进行审计和评审。

　　◆ 医生的角色——在项目过程中，QA也可以承担收集、统计、分析度量数据的工作，用于支持管理决策。

　　在CMMI中，度量分析是一个单独的过程域。CMMI成熟度等级越高，对度量分析提出的要求也越高，难度越大。相应地，QA人员应该具备的能力要求就更高。那么，在企业的实际操作中，QA到底是老师、医生还是警察？或者三者皆

　　如果企业计划进行CMMI评估或者经过评估已经达到了某个成熟度等级，那么这些企业中的QA应该做到以上所列的所有工作，这是为了满足CMMI要求的必须。但如果仅从企业自身业务和管理的需要出发，考虑到企业文化，就不一定非得要求QA既当警察又当老师和医生了。例如，企业认为同行评审投入资源多，产生效益却不明显，QA应加强对同行评审过程的监控，因此QA可以承担同行评审会议的组织和协调工作。而有些企业则是由项目组按照流程自行组织同行评审，QA只是抽样参与评审过程进行审计。如果企业有外包业务，则QA应该作为外包过程和产品质量监控的主力。

　　 2. 不同过程成熟度等级对QA职责的要求

　　 CMMI不同成熟度等级对QA职责的要求有较大的不同，过程成熟度是影响QA工作分布很重要的因素。成熟度等级较低时，由于过程体系尚处于建立过程中，员工的过程意识不强，所以QA的工作主要集中在收集最佳实践、定义过程体系和培养员工建立过程意识方面。随着过程体系的实施、完善和制度化，QA的工作重点转移到过程评审和产品审计。当企业达到了高成熟度等级，即4、5级时，过程的执行已经高度制度化，成为员工的工作习惯，因此过程评审和产品审计所需要的工作量也大量减少，而定量管理需要QA作为专业人员更多地投入度量分析工作中。组织级的过程变革、技术变革等过程改进工作是5级企业对QA最主要的要求。如下图所示，随着成熟度等级的变化，QA花费在过程指导、过程评审、产品审计、过程度量和过程改进方面的工作量分布也不同。

　　　　　　　　图3 不同成熟度等级对QA职责的要求

五、谁是合适的QA人选

　　QA人员可以来自于企业的各个部门，既可以由专职人员担任，也可兼职。但很多企业的经验证明，选择一些新人和“闲人”组成的QA部门往往只能构成形式上的QA组织，却不能胜任企业对质量体系寄予的重任——保证逐步实现产品零缺陷、工作零错误。那么，企业应该选择什么样的人来担任QA才能有效地行使QA的职能？

　　 1. QA应该具备的能力

　　 在选择合适的QA人选时，企业应首先考虑他们的知识、技能和素质能否满足组织和岗位的要求。具体而言，可以从软能力、项目管理经验、软件工程经验、项目业务知识，以及对过程体系的熟悉程度等方面来考察。“软能力”是指创新、团队精神等不太容易评估但又非常重要的素质，软能力的培养不是一朝一夕的事情，而是一个潜移默化的渐进过程，它的形成则更多依赖于自我修炼。这好比我们在政治课上能学到政治常识，却不一定能提高政治觉悟一样。QA人员如果没有实际参与过项目/产品的开发，没有从事过项目管理工作，或是从有些部门抽调来的工作相对比较“轻松”的人员，即便他们熟读背诵了整个过程体系，仍然很难成为企业真正需要的合格的QA。

　　 企业由于成熟度和企业文化的不同，对QA的期望也很不同。比如一个沟通协作差、部门墙林立的企业，QA的软能力，尤其是团队精神和沟通协调能力可能是最重要的要求；对于一个高过程成熟度的企业，对QA的要求则不仅仅是对过程体系的熟知，而要求QA同时具备深入的业务领域知识，并且是一位度量分析的专家。

　　 2. EPG和QA人员的7种素质

　　 EPG，即工程过程组，是过程改进的主体，QA是过程改进实施的重要推动力量，他们应该具备以下7种基本的素质：

　　 1. 真正相信过程改进-只有发自内心的相信才能感染别人。

　　 2. 自我激励-即便身处逆境，也可以克服不良情绪振作起来。

　　 3. 不畏惧失败-我们的任何工作在第一次做时不可能完美。

　　 4. 引导和激励其他人-只有几个人的改变不代表整个组织的成功。

　　 5. 分清工作轻重缓急层次清晰-平衡工作的长期目标和短期利益。

　　 6. 不断充电-不断学习、思考、实践、再学习。

　　 7. 开心地工作。

六、总结

　　企业在建立QA组织时，应根据自身的需要，考虑到企业文化、成熟度等级，以及可获得的资源等因素，因地制宜。“抓壮丁”式地选择QA人员，绝无利于企业的质量体系发挥作用。只有选择了合适的QA组织形式，QA人员具备相应的能力和素质，才能保证质量管理体系良好地运作，从而现产品零缺陷、工作零错误的最终目标。