UML软件工程组织

QA组织的建立
作者: 秦锋剑

无论是 ISO9000 还是 CMMI ,都是以过程为中心。也就是说,通过过程的持续改进来提高产品质量。而过程质量与产品质量如何正向关联呢?就需要质量保证( QA )。这也是 ISO9000 和 CMMI 都很推崇的方法。但从国内软件企业的现状来看,很多企业的过程体系都相差无几,而开发出来的产品质量却千差万别。导致这种差别的原因有很多,过程及其执行方式的生搬硬套就是其中很重要的原因之一。

在建立 QA 组织的时候,多数企业也这样实行“拿来主义”。就像看着别人穿着一双漂亮的鞋,就想拿过来自己穿,一般都不会适合自己。其结果要么是削足适履,要么是打肿脚穿大鞋,效果可想而知。我们应该做的是“量脚买鞋”、“量体裁衣”。 QA 组织的建立也一样,应先了解企业的文化、可获得的资源以及过程成熟度水平等,再据此选择适宜的 QA 组织。下面我们就从一个动态的视角来探讨 QA 组织的建立。

建立组织结构

建立一个组织,首先需要考虑的是它的组织结构。组织结构不仅在很大程度上决定了岗位的职责,而且还决定了资源如何配置。按照国内多数企业的做法, QA 组织结构可划分为三类:职能结构、矩阵结构以及两者结合而成的柔性结构。

在职能结构中,各个职能部门设立自己的 QA 岗位,位于高级经理之下,独立于项目组。 QA 直接对高级经理负责,但业务上需要向项目经理汇报,属于项目成员。如图 1 所示。这种组织结构的优点是 QA 容易融入项目组,易于发现实质性的问题,解决问题也很快捷。缺点是各职能部门相对独立,部门之间的经验缺乏交流和共享,还可能出现对过程、方法和工具研究的重复性投资。在这种组织结构下,由于高级经理专注于业务的发展, QA 的职业发展容易受到忽视,难于接受到应有的培训和提升。



图 1 职能结构的 QA 组织

在矩阵结构中,设立了专门的 QA 部门,与各业务职能部门平级。 QA 隶属于 QA 部,行政上向 QA 经理负责,业务上向业务部门的高级经理和项目经理汇报。如图 2 所示。在这种组织结构中,由 QA 部经理对 QA 考评和授权,有利于保证 QA 的独立性和评价的客观性,也有利于确保组织的长期利益与项目(或个人)的短期利益之间的平衡。 QA 资源为所有项目所共享,可按照项目优先级动态调配,资源利用更充分,但也可能出现资源竞争冲突。此外, QA 部门对 QA 流程的改进、 QA 知识的管理、 QA 人员的发展负责,并可集中资源进行 QA 平台的建设,以防止重复性的投资。但另一方面,在矩阵结构中, QA 难于融入项目组,发现的问题也很少能得到及时有效的解决。



图 2 矩阵结构的 QA 组织

柔性结构是职能结构和矩阵结构的混合形态,在职能结构的基础上建立了 QA 组。 QA 组是一个专业组,不是一个行政机构。 QAG Leader 可由质量管理部委派人员担任或由某业务部门的 QA 兼任。与职能机构一样, QA 直接对高层经理负责,但在业务上向项目经理和 QAG Leader 汇报。柔性结构吸收了职能结构和矩阵结构的许多优点,既便于 QA 融入项目组,又便于部门之间经验的分享,还利于 QA 能力的提高。 QAG Leader 可以从各部门 QA 汇报中提取出各项目的共性问题,用于组织级过程的改进。企业还可以通过授予 QAG Leader 不同的权利,比如按照 20/80 原则与高级经理分配 QA 的管理,来促进 QA 专业研究与应用的结合。

图 3 柔性结构的 QA 组织

确定岗位职责

在 CMMI 中, QA 的主要工作是过程评审和产品审计。从实践经验来看, QA 只完成这两项工作很难体现出 QA 的价值。为了让 QA 组织的产出大于组织的投入,实现增值,就应该根据企业需要适当增加 QA 的职责,比如过程指导、过程度量和过程改进等。过程指导主要是项目前期辅助项目经理制定项目计划(包括辅助定义或修改项目过程和过程模型、协助项目估计、建立项目验收准则、设置质量目标等),对项目成员进行过程和规范的培训以及在过程中进行指导等。过程度量(包括产品度量)在 CMMI 中已经成为 CMMI ML2 级中一个单独的过程域,但却是对所有过程的一个共性要求。特别是成熟度越高,对度量的要求也越高,难度也越大。这就要求有专业的人员来负责, QA 就是一个很好的选择。主要职责包括收集、统计、分析度量数据,以支持管理信息需求。过程改进在 CMMI 中主要是 EPG 的职责。但事实上, QA 更接近于过程实施的环境,更了解过程运行的情况,也就更容易发现“木桶中最短的那块”。同时, QA 也是改进过程试施的重要推动力量。

在了解了 QA 的这些工作以后,是否认为每个企业的 QA 职责应该都一样或者差不多呢?目前国内不少企业的现状确实是这样,这也是 QA 整体效果低下的一个很重要的因素。我们在确定 QA 职责的时候应该考虑自身的需要和环境,主要包括业务需求、过程成熟度水平和企业文化。

业务需求主要是确定了 QA 需要完成哪些方面的工作,比如执行同行评审过程中, QA 可以协助评审和组织会议;在存在外包的情况下,可能需要 QA 在监控外包方方面发挥作用。

过程成熟度是影响 QA 职责分配很重要的因素,不同的成熟度等级所要求的 QA 工作分布是不同的,如图 4 所示。在低成熟度等级下,需要抽取各项目最佳实践来定义过程,并指导过程的试施, QA 在这方面的工作最多。随着过程的完善、制度化和实施, QA 的工作重点逐渐转向了过程评审和产品审计。当企业的过程成熟度达到 4 级或 5 级以后,对过程的遵守已经成为员工的一种习惯,过程和产品的审查需求减少,而度量和过程能力的优化又成为 QA 的工作重点。

图 4 QA 工作随成熟度等级的动态分布

企业文化对 QA 来说就像空气一样,看不见它,但却深深地被它影响。比如说,在一个氛围活跃、高技术、创新能力强的企业, QA 应该倾向于服务职责;而在一个强纪律、低技术、规章制度成熟的企业, QA 就应该倾向于监督职责。

 配置岗位人员

在建立组织结构过程中设立了 QA 工作岗位,现在就需要为岗位配备足够的资源,特别是分派岗位人员。从大体上说, QA 人员的配备可根据企业特点分为两类:全职和兼职。

全职就是设置专门的 QA 人员, QA 的主要职责就是质量保证工作。在设置这类人员时,最重要的是考虑他的知识、技能和素质是否符合组织和岗位的规定和要求。这些要求是依据企业文化和成熟度的不同而有所侧重。比如说,对于一个协作意识较弱、官僚主义较浓的企业,沟通对 QA 来说可能是一个重要的素质要求;对于成熟度较低,还没有制度化标准过程的企业,对业务的了解和 QA 专业知识的精通可能是选择 QA 最重要的标准。

兼职就是将工程师分派到其它职能部门或项目中去兼任 QA 工作,每一位工程师都作为一名潜在的 QA 。这也是 QA 人员配置的一个可选方案,一般适宜于开放的、以质量为向导的文化,反过来也能对质量文化的建设起到很大的促进作用。但这种方案应小心地与组织制度结合,比如奖惩制度、成本制度等,否则容易引起利益冲突。

由于 QA 的概念引入国内不久, QA 人才相当缺乏。为了获得足够的资源来完成 QA 工作,也可以采取岗位轮换的方式。比如,允许项目经理在项目管理岗位和 QA 岗位上轮换,把一定的 QA 工作经历作为项目经理上岗的必备条件。采取岗位轮换的方式,一方面解决了 QA 资源的不足,另一方面还促进了轮岗人员把 QA 的思想和方法融会到开发和项目管理工作中,更大程度上提高产品质量。

从以上的分析我们可以知道,建立 QA 组织需要动态地考虑企业的文化、可获得的资源以及过程成熟度水平等因素,做到“因地制宜”,而不是生搬硬套。首先要建立一个适宜的组织结构,组织结构中确立了 QA 岗位和汇报渠道。接下来就是确定岗位职责,并根据岗位职责的要求配置合适的 QA 人员。只有在组织结构、岗位职责、岗位人员都设置和整合好以后,才能充分发挥 QA 的价值,确保通过过程的持续改进来带动产品质量的不断提高。

 

版权所有:UML软件工程组织