软件质量管理之困境与对策思考

相信在很多与软件开发相关的企业内，质量管理部门与软件开发部门在平常运做中造成了以下图所示的“哑铃形”组织结构。

 

 

开发部门执行质量管理部门所制定的流程，经过提供证据的形式将各类流程执行后的数据反馈给质量管理部门（包括缺陷率和各类流程记录），质量管理部门根据这些数据监督流程的执行效果，并适时修订流程。联系两大独立部门的，是单薄的两条线和一些部门间的会议。理想状况下，在质量管理部门与软件开发部门间造成的是一个逆时针的良性质量管理环，理应得到良好的效果。但在我看来，事实却并不是如此！

哑铃形组织结构所存在的前提假设有两个。其一，度量数据能真实地反映软件质量。显然，在软件危机仍四伏的今天，业内并无找到彻底能用于度量软件质量的指标，这一假设对于现实多少显得非常渺茫。其二，软件开发部门能诚实地提供度量数据。对于目前国内职业化程度不高的状态，这一假设也很难成立。

所以，哑铃形组织结构所带来的第一个困境是：将两个部门分别变成了“看数据的”和“造数据的”两大阵营。软件开发部门为了达到质量管理部门所制定的“质量目标”，不时须要考虑如何将数据“造”好，哪怕“造”的手法有点低劣；而质量管理部门因为只是经过数据去了解软件产品的质量情况，除了不能理解有些指标为什么忽上忽下外，更没法督促开发部门就质量问题的根源进行根治。

克服这一困境的对策我认为须要从打破组织结构开始。真正掌握软件真实质量情况的并非来自质量管理部门的人，由于他们根本没有触及软件源代码，而是来自开发部门的软件工程师。为此，两部门的人员应当存在交集才更有可能作好质量管理工做，或许下图的组织结构更有助于达到这一目的。

 

在新的组织结构中，两部门交集中的人应来自开发部门的、对软件质量管理有很好认识的技术专家，这些人来自下图“能力金字塔”（参见《软件开发：我的与团队是永远的核心》）的上面两层。他们除了帮助质量管理部门了解软件质量的真实情况外，还应帮助开发部门理解质量问题的根源和寻求技术解决方案。交集中的人能够考虑采用虚拟团队的形式进行组织与管理。

质量管理容易出现的另外一大困境是：太强调流程与数据，而忽视质量管理很重要的内容是帮助工程师改善工做习惯（好比编程习惯）和提升开发环境的工做效率（好比项目的编译效率、单元测试的实施效率）。在这种困境之中，质量管理活动更多地表现为“钢性”—— 达到设定指标或没有达到，而缺少应有的“柔性”理解。虽然“产品质量源于过程控制”这一思想被业界普遍认同，但却仍容易忽视将工程师的工做习惯和开发环境的效率归入到质量管理的范畴之中，这也是形成很多质量困境的关键因素。对于这两方面内容的重要性，不管如何强调也不为过。

 

最后，我认为质量管理应更多关注于实践，而非度量。因为软件开发的特殊性本质，咱们难以寻找到有效的度量手段，于其在这方面毫无建树，不如花更多的时间去创建适合本身的实践方法，并将这些实践融入到工程师的工做习惯和开发环境中去。

 

推荐阅读

《驾驭你的“职场布朗运动”》

《致IT同仁 — IT人士常犯的17个职场错误》

《软件工程师所需掌握的“终极技术”是什么？》
《技术敏感度 — 基层技术管理者必备》