相信在不少与软件开发相关的企业内，质量管理部门与软件开发部门在日常运作中形成了如下图所示的“哑铃形”组织结构。
开发部门执行质量管理部门所制定的流程，通过提供证据的形式将各种流程执行后的数据反馈给质量管理部门（包括缺陷率和各种流程记录），质量管理部门根据这些数据监督流程的执行效果，并适时修订流程。联系两大独立部门的，是单薄的两条线和一些部门间的会议。理想情况下，在质量管理部门与软件开发部门间形成的是一个逆时针的良性质量管理环，理应获得良好的效果。但在我看来，事实却并非如此！
哑铃形组织结构所存在的前提假设有两个。其一，度量数据能真实地反映软件质量。显然，在软件危机仍四伏的今天，业内并没有找到完全能用于度量软件质量的指标，这一假设对于现实多少显得很是渺茫。其二，软件开发部门能诚实地提供度量数据。对于目前国内职业化程度不高的状态，这一假设也很难成立。
因此，哑铃形组织结构所带来的第一个困境是：将两个部门分别变成了“看数据的”和“造数据的”两大阵营。软件开发部门为了达到质量管理部门所制定的“质量目标”，不时需要考虑如何将数据“造”好，哪怕“造”的手法有点低劣；而质量管理部门由于只是通过数据去了解软件产品的质量状况，除了不能理解有些指标为何忽上忽下外，更无法督促开发部门就质量问题的根源进行根治。
克服这一困境的对策我认为需要从打破组织结构开始。真正掌握软件真实质量状况的并不是来自质量管理部门的人，因为他们根本没有触及软件源代码，而是来自开发部门的软件工程师。为此，两部门的人员应当存在交集才更有可能做好质量管理工作，或许下图的组织结构更有助于达到这一目的。
哑铃形组织结构所存在的前提假设有两个。其一，度量数据能真实地反映软件质量。显然，在软件危机仍四伏的今天，业内并没有找到完全能用于度量软件质量的指标，这一假设对于现实多少显得很是渺茫。其二，软件开发部门能诚实地提供度量数据。对于目前国内职业化程度不高的状态，这一假设也很难成立。
因此，哑铃形组织结构所带来的第一个困境是：将两个部门分别变成了“看数据的”和“造数据的”两大阵营。软件开发部门为了达到质量管理部门所制定的“质量目标”，不时需要考虑如何将数据“造”好，哪怕“造”的手法有点低劣；而质量管理部门由于只是通过数据去了解软件产品的质量状况，除了不能理解有些指标为何忽上忽下外，更无法督促开发部门就质量问题的根源进行根治。
克服这一困境的对策我认为需要从打破组织结构开始。真正掌握软件真实质量状况的并不是来自质量管理部门的人，因为他们根本没有触及软件源代码，而是来自开发部门的软件工程师。为此，两部门的人员应当存在交集才更有可能做好质量管理工作，或许下图的组织结构更有助于达到这一目的。
在新的组织结构中，两部门交集中的人应来自开发部门的、对软件质量管理有很好认识的技术专家，这些人来自下图“能力金字塔”（参见《软件开发：个人与团队是永远的核心》）的上面两层。他们除了帮助质量管理部门了解软件质量的真实状况外，还应帮助开发部门理解质量问题的根源和寻求技术解决方案。交集中的人可以考虑采用虚拟团队的形式进行组织与管理。
质量管理容易出现的另一大困境是：太强调流程与数据，而忽视质量管理很重要的内容是帮助工程师改善工作习惯（比如编程习惯）和提高开发环境的工作效率（比如项目的编译效率、单元测试的实施效率）。在这种困境之中，质量管理活动更多地表现为“钢性” — 达到设定指标或没有达到，而缺乏应有的“柔性”理解。虽然“产品质量源于过程控制”这一思想被业界广泛认同，但却仍容易忽视将工程师的工作习惯和开发环境的效率纳入到质量管理的范畴之中，这也是造成不少质量困境的关键因素。对于这两方面内容的重要性，无论如何强调也不为过。
最后，我认为质量管理应更多关注于实践，而非度量。由于软件开发的特殊性本质，我们难以寻找到有效的度量手段，与其在这方面毫无建树，不如花更多的时间去建立适合自己的实践方法，并将这些实践融入到工程师的工作习惯和开发环境中去。
![[基础篇]ESP32-RTOS-SDK教程(一)之Windows环境搭建](https://img2018.cnblogs.com/blog/1558014/201903/1558014-20190301170648923-2002755151.png)
