着眼于项目管理的SQA组织架构思路分享

[如需转载，请在转载时注明出处，并保证本文的完整性]

今天和一位质量经理朋友讨论其公司新组建SQA部门的话题。讨论的话题很多，包括组织架构、角色职责、流程订制、过程控制、测试与度量等话题。在过去几年，本人以SQA的角色参与数个软件项目的质量保证、测试管理工作。大量的实践证明，扎实的SQA工作无疑在项目交付时间与交付质量上提到的作用不容小觑，项目的项目总体成本得到有效控制。不过这样的做法持续下去是否就真的能做到“一劳永逸” 呢？其实不然

想必大家对项目管理的知识都有一定的了解了，既然被称作“项目管理”，自然有其先天资源、时间、成本上的限制。我们在了解到这些问题的前因后果后，将有限的资源与时间，瞄准主要的目标，提出可执行、立竿见影的方法（当然包括测试手段、评审制度等诸如此类的行业做法），期望能为项目"止疼止血"。大家可能觉得形容视乎有些危言耸听，常见的质量手段岂不成了“亡羊补牢”。
长期的软件测试工作经验告诉我们，想要让软件项目能在问题发生前就预先防范，除了常见的SQA手段和方法，其实还有一类问题不可忽视，我们发现“高估”和 “低估”也有可能成为整个项目出现问题发散的罪魁祸首。

看到这里，可能很多读者已经开始发晕了，在进一步讨论之前，我们不妨换个角度看一个相关的问题：讨论一个组织要把工作完成需要的三个部分：专业能力、流程体系、管理模式
A、所谓专业能力会随着专业领域的不同而不同，也会随着不同的员工而有所差异；
B、不同的公司都有各自跨部门的流程/体系，以有效的动员组织成员，用经济的方式解决问题；
C、接着，组织要靠管理系统让这些问题都能有效率地在要求的时间、达成要求的质量指标。
好了，我们收集信息发现，目前国内很多软件企业普遍对研发人员（含QA人员）的要求比重。大约是：要求其专业能力占80%左右、流程系统占5到10%、管理模式占5%左右。
换言之，管理者往往比较重视个人的专业表现，忽略了个人在流程系统、管理模式上的表现或理解。所以时常会我们发现作了很久的开发或测试，只要专业能力的表现不差，通常能有一定的晋升空间。
而有注重制度的的公司或部门，会对加强人员对流程系统、管理模式要求的比重，大约是：专业能力40至50%、流程系统20到0%、管理模式20到0%，而不只是要求专业能力。
    那么对于人才流动的常态化的今天，作为SQA部门，与其重点提升专业测试技能与方法，不如同时加强流程体系与个人作为项目管理中角色的转变的工作中来。试想下，拥有这样的组织成员，一旦能留下有效率的系统和管理模式，只要选对的人，就能完成要求的事，而且最后变动的风险会在可接受的范围内（风险受控）。



现在我们把焦点回到前面的“高估”和 “低估”。那什么是高估呢，所谓的“高估”，个人认为是决策者通常会“高估”组织在流程系统、管理模式的能力，以致于在项目计划阶段无法提出实际、具体、准确、考量风险后的项目计划，以致于项目启动后实际执行时，才发现以现在组织的运作效能，随着项目进度不可能如期完成。
所谓的“低估”，是指决策者通常都会“低估”项目的难度、复杂度、深度，以致于在项目启动后，随着越来越了解项目要求，才发现要如期、如质、如成本地完成项目有相当的难度。
究其原因，可以发现决策者“高估”了组织的流程系统、管理模式能力，“以为”组织已经正确地评估项目，才是后来产生“低估”项目难度的结果。但解决项目只是治“已病”，因为流程系统、管理模式能力不足才是“未病”--问题的真正原因。而且，这些“未病”通常是组织内沉寂已久的问题，想治疗“未病”通常得需要大刀阔斧，甚至不惜伤筋动骨破坏人和，最后还需要一段时间后才能看得出效果。
以普遍现况来看，很多管理者组建SQA部门的初衷都寄希望于采用有效的SQA手段，能短时间内有效处理曾经发生或已经发生的问题，这当然是无可厚非的。这只不过是倾向本末倒置地解决“已病”，而非认真解决造成问题的“未病”。所以，“未病”一再成为“已病”，导致SQA从业人员无论怎么跳槽，去到大部分公司的结果，还是会遭遇到去应接不暇地解决“已病”。
至此，如何真正意义做处理“未病”的SQA，大家不妨共同思考了...