每个公司都想用高质量的产品来取悦客户，并且很多组织为了达到这个目的，都很自然地注重于流程改进。但是组织文化会吞噬策略，那么，应当如何打造质量文化呢？
产品质量是工程师团队通过软件开发周期来紧密监控的一项。多数情况下，我们融合了外部质量测量和内部质量测量。外部质量测量是对客户可见的部分，例如缺陷、可靠性或安全性。内部质量测量是对客户不可见的部分，例如对规格标准的遵循度、可维护性如何、代码的有效性或者代码库的大小。而当需要对外部、内部质量进行很大程度上或者重复性提高的时候，工程师团队通常专注于流程改进作为提升质量的方法。毕竟，产品的质量见证了创造它们的流程质量，难道不是吗？
产品也是创造它们的文化产物。麻省理工学院马丁信托创业中心的总经理Bill Aulet，同时也是麻省理工斯隆商学院的资深讲师，提醒我们：文化会吞噬策略 ，并且，我质疑流程也一样会被文化所吞噬。当组织文化与流程改变的精神相冲突时，例如当命令式与控制式的文化试图通过自管理，敏捷团队来达到生产率的目的，每一次冲突都会是文化获胜。
文化通过组织的价值观、标准、信念和习惯表现出了自己，这些表现形式进而通过规范团队行动的方式产品质量产生影响。我的这一观点并非来自某个组织的报告说明，而是通过组织在每一个级别上的行为所得出的。首先，组织的价值观通常能够帮助团队排列出优先级最高的任务。比方如，一个组织高度重视简化设计，那么当它发现针对某个缺陷的修复会无意间导致用户体验的复杂度增加时，也许会选择撤消这个修复。对某个发布的整体质量就可能从该次发布中计划引进的那些新功能的实现是否优雅这一方面进行评估。
组织标准定义了什么被认为是可接受的行为，通常是通过组织跟踪记录。举例来说，之前的几次发布是否需要开发人员在发布之前用额外的时间来修复严重的缺陷。如果没有这个跟踪记录，那么在计划一个高质量的发布时，项目经理对团队的生产率的估算就有可能过于保守，因为团队可能无法接受用额外的工作时间来满足他们对质量的承诺。
组织的信念是指，对于事情应当表现出的方式已达成共识的想法和原则。比方说，开发人员的信念会让他们对编写的代码有主人翁意识及责任感，因而他们的代码就是他们勤奋和努力工作的结果。当主要缺陷追踪到他们的代码那里，这些开发人员会因为他们漏掉了什么而感觉到尴尬，并且试图尽快地修复。而某些组织信念正好相反，他们认为每一个项目和每一个改进代码的区域都会存在缺陷，并且认为这是意料之中的事。有了这样的信念，开发人员对在他们的代码中发现缺陷的反应速度就会比较慢。
文化的最后一个元素是组织习惯，它引导团队形成有规律的或通常不成文的倾向。举例来说，当决策发生的时候。对于一些组织，决策会推到会议室中最资深的人那里给出。然而其他的组织为了做出可接受的决定，可能会定义标准和使用一些证据，这些标准和证据是所有层级的人都适用的。观察一个团队如何决定待发布的代码质量是否足够好，会非常有指导意义。因为这可能是在发布期间影响质量最重要的一个决定。
所以，你如何通过文化来驱动质量呢？在他们的HBR 文章中，一篇打造质量文化，CEB的Ashwin Srinivasan 和 Bryan Kurey分享了他们最近一段时间以来对这个问题的研究。他们研究了来自于80个跨国公司的超过850名能够对质量产生影响的员工，找到了作为文化价值驱动质量的四个因素。
领导重视。关于质量，领导需要展示如何“付诸行动”。并且必须来自于上层的授意。你可以通过如下方式来达成这一点：特别要注意的一点是，当你要在组织中介绍或改变度量的时候。就像其他任何变化一样，至关重要的是在采取这个改变时要在大家的认同和强行执行之间权衡利弊。度量的风险在于，不同的团队可能已经在使用自己的度量方式了，他们会着重于强调他们所感兴趣的部分。因由于度量的目的是全面地测量和转变团队的行为，因此关键在于让所有的干系人（高层领导、产品经理、质量保证人员和工程师）认同并且坚持某些通用原则，你可以通过如下方式来达到：
有目的地建立一个跨职能的工作组。清晰地说明出，如果没有度量的情况下，当前存在的痛点，为什么必需要采取行动，以及常见的度量是如何帮助我们的，通过这些来激发大家对度量的需求。邀请那些有影响力的干系人，让来自于不同部门的高层领导、产品经理、质量保证人员和工程师来设计度量。在讨论的过程中，每一个参与者都代表了他们团队感兴趣的部分，也帮助了我们把度量在内部推广给其他人。选择一个好的引导师，并且请确保在度量设计完成之后，明确地要求参与者把这个结果推销给他们的同事。
对有价值的产出进行测量。让工作组首先识别出不同的干系人所关心的、他们理想中的定性的产品产出是什么。一旦这些识别出这些产出之后，然后再邀请小组人员返回度量设计，选择促进或偏离每一个产出需要的测量。比方说，假设你的产品是一个云应用，计算成本上升的速度比使用的增长速度还快，高层管理人员对此问题表示关注。工作组可能会识别出各种度量来测量有效性，例如各台服务器的CPU使用率，而这是可以在开发和测试阶段进行监控的。一旦这些度量最终被确定和使用，请展示给你的团队并告诉它带来的影响是什么。
对跨团队的度量进行标准化。让工作组创建模板或者仪表盘，因此所有的团队可以以此进行度量的查看。邀请每一位参与者展示他们特定团队的结果，并且确保各个团队统一使用这些标准工具。因为每个职能部门都对该流程表达了自己的观点，并且清晰地设定了期望。因此这些度量就可以让每个人在以后工作中使用。
