打造质量文化-InfoQ

每个公司都想用高质量的产品来取悦客户，并且很多组织为了达到这个目的，都很自然地注重于流程改进。但是组织文化会吞噬策略，那么，应当如何打造质量文化呢？

产品质量是工程师团队通过软件开发周期来紧密监控的一项。多数情况下，我们融合了外部质量测量和内部质量测量。外部质量测量是对客户可见的部分，例如缺陷、可靠性或安全性。内部质量测量是对客户不可见的部分，例如对规格标准的遵循度、可维护性如何、代码的有效性或者代码库的大小。而当需要对外部、内部质量进行很大程度上或者重复性提高的时候，工程师团队通常专注于流程改进作为提升质量的方法。毕竟，产品的质量见证了创造它们的流程质量，难道不是吗？

产品也是创造它们的文化产物。麻省理工学院马丁信托创业中心的总经理 Bill Aulet，同时也是麻省理工斯隆商学院的资深讲师，提醒我们：文化会吞噬策略，并且，我质疑流程也一样会被文化所吞噬。当组织文化与流程改变的精神相冲突时，例如当命令式与控制式的文化试图通过自管理，敏捷团队来达到生产率的目的，每一次冲突都会是文化获胜。

文化通过组织的价值观、标准、信念和习惯表现出了自己，这些表现形式进而通过规范团队行动的方式产品质量产生影响。我的这一观点并非来自某个组织的报告说明，而是通过组织在每一个级别上的行为所得出的。首先，组织的价值观通常能够帮助团队排列出优先级最高的任务。比方如，一个组织高度重视简化设计，那么当它发现针对某个缺陷的修复会无意间导致用户体验的复杂度增加时，也许会选择撤消这个修复。对某个发布的整体质量就可能从该次发布中计划引进的那些新功能的实现是否优雅这一方面进行评估。

组织标准定义了什么被认为是可接受的行为，通常是通过组织跟踪记录。举例来说，之前的几次发布是否需要开发人员在发布之前用额外的时间来修复严重的缺陷。如果没有这个跟踪记录，那么在计划一个高质量的发布时，项目经理对团队的生产率的估算就有可能过于保守，因为团队可能无法接受用额外的工作时间来满足他们对质量的承诺。

组织的信念是指，对于事情应当表现出的方式已达成共识的想法和原则。比方说，开发人员的信念会让他们对编写的代码有主人翁意识及责任感，因而他们的代码就是他们勤奋和努力工作的结果。当主要缺陷追踪到他们的代码那里，这些开发人员会因为他们漏掉了什么而感觉到尴尬，并且试图尽快地修复。而某些组织信念正好相反，他们认为每一个项目和每一个改进代码的区域都会存在缺陷，并且认为这是意料之中的事。有了这样的信念，开发人员对在他们的代码中发现缺陷的反应速度就会比较慢。

文化的最后一个元素是组织习惯，它引导团队形成有规律的或通常不成文的倾向。举例来说，当决策发生的时候。对于一些组织，决策会推到会议室中最资深的人那里给出。然而其他的组织为了做出可接受的决定，可能会定义标准和使用一些证据，这些标准和证据是所有层级的人都适用的。观察一个团队如何决定待发布的代码质量是否足够好，会非常有指导意义。因为这可能是在发布期间影响质量最重要的一个决定。

所以，你如何通过文化来驱动质量呢？在他们的 HBR 文章中，一篇打造质量文化，CEB 的 Ashwin Srinivasan 和 Bryan Kurey 分享了他们最近一段时间以来对这个问题的研究。他们研究了来自于 80 个跨国公司的超过 850 名能够对质量产生影响的员工，找到了作为文化价值驱动质量的四个因素。

领导重视。关于质量，领导需要展示如何“付诸行动”。并且必须来自于上层的授意。你可以通过如下方式来达成这一点：

_ 跟踪质量度量。_ 定义高层领导、产品经理、质量保证人员和工程师都认同的有意义的质量测量。
_ 让你的度量可见。_ 经常把在会议中提到它们，并且和你的团队定期地回顾评审。
_ 用质量做取舍。_ 对最小质量级别创建清晰的定义和规范，当邻近发布时需要做出取舍时，就可以在会议中使用它们。当团队看到质量度量用于决策的取舍时，他们就会了解为什么要重视质量了。

特别要注意的一点是，当你要在组织中介绍或改变度量的时候。就像其他任何变化一样，至关重要的是在采取这个改变时要在大家的认同和强行执行之间权衡利弊。度量的风险在于，不同的团队可能已经在使用自己的度量方式了，他们会着重于强调他们所感兴趣的部分。因由于度量的目的是全面地测量和转变团队的行为，因此关键在于让所有的干系人（高层领导、产品经理、质量保证人员和工程师）认同并且坚持某些通用原则，你可以通过如下方式来达到：

有目的地建立一个跨职能的工作组。清晰地说明出，如果没有度量的情况下，当前存在的痛点，为什么必需要采取行动，以及常见的度量是如何帮助我们的，通过这些来激发大家对度量的需求。邀请那些有影响力的干系人，让来自于不同部门的高层领导、产品经理、质量保证人员和工程师来设计度量。在讨论的过程中，每一个参与者都代表了他们团队感兴趣的部分，也帮助了我们把度量在内部推广给其他人。选择一个好的引导师，并且请确保在度量设计完成之后，明确地要求参与者把这个结果推销给他们的同事。
对有价值的产出进行测量。让工作组首先识别出不同的干系人所关心的、他们理想中的定性的产品产出是什么。一旦这些识别出这些产出之后，然后再邀请小组人员返回度量设计，选择促进或偏离每一个产出需要的测量。比方说，假设你的产品是一个云应用，计算成本上升的速度比使用的增长速度还快，高层管理人员对此问题表示关注。工作组可能会识别出各种度量来测量有效性，例如各台服务器的 CPU 使用率，而这是可以在开发和测试阶段进行监控的。一旦这些度量最终被确定和使用，请展示给你的团队并告诉它带来的影响是什么。
对跨团队的度量进行标准化。让工作组创建模板或者仪表盘，因此所有的团队可以以此进行度量的查看。邀请每一位参与者展示他们特定团队的结果，并且确保各个团队统一使用这些标准工具。因为每个职能部门都对该流程表达了自己的观点，并且清晰地设定了期望。因此这些度量就可以让每个人在以后工作中使用。

消息的可靠性。成功的经理人都会根据与团队的共鸣度谨慎地选择正确的方式去沟通有关质量方面的消息。做好这一点也许需要经过一些试验。从不同的内部或外部的干系人的视角来沟通产品质量，看看如何激发你的团队。例如以下几种方式：

_ 客户满意度。_ 采访或调查客户对产品的整体满意度，在过程中注意以语言引导他们的情绪。
_ 演示中的销售体验。_ 就像任何一个销售代表会告诉你的一样，在预期演示的时候出现产品崩溃会带来十分严重的伤害，并且会让销售代表很难堪。应该注意了解销售代表在演示产品中的表现，以及他们在演示中产品所表现出的可靠程度。
高层领导的看法。在很多组织中，高层领导（尤其是创始人）喜欢动手尝试新的产品功能。在邻近发布时，邀请他们参与使用，并且询问他们的体验。

同事参与。一旦他们开始彼此参与度量时，你的团队可能会将质量深入内心，你可以通过下面不同的步骤来鼓励团队：

在设计阶段创造一些仪式。在设计讨论阶段，帮助你的团队开发一个流程来评估不同设计方案对质量的影响。为团队准备一些问题，让他们回答他们所考虑的每一个方案对质量的影响，并且在发布之后展示这些问题是如何对整体的质量做出贡献的。
邀请同事评估。在定期的状态审核会议中，为你的团队展示最近的质量度量情况，并且要求每个人站在他们的立场做自己的评估。哪些是他们同意的，哪些是他们对结论有分歧的？不管答案是什么，只要邀请团队做他们自己的评估，就会让他们注意到质量。
鼓励结对编程。如果定期实施结对编程，尤其是在初级的和资深的开发人员之间进行结对，这会鼓励大家在设计和实施的阶段讨论质量的问题。鼓励你们团队的资深开发人员在每一次结对编程的过程中进行讨论。

员工的主人翁意识和授权。你可以给你的团队授权，让他们做质量决策，并且通过这个结果，他们会感到更强的主人翁意识。可以考虑到用以下方式实现这一点：

识别质量贡献者。创建个人的质量测量 (例如每名开发的缺陷、也许根据项目的复杂度会变大)，提供可见性，并在团队中赞誉那些获得优秀结果的人。创建一个仪表板，清晰地显示每个人与同事的对比。并且将这个结果用到会议中。
创造竞赛意识。对于大的项目，可以考虑给那些编写出最高质量的代码，表现出众的员工颁奖。确保在开始的时候就宣布这个竞赛，并且说明衡量标准。你会从中获得很大乐趣。
创造学习机会。邀请那些交付最好记录的团队成员参加午饭演讲活动，让他们分享创建高质量的方法、他们所做的设计决定和最近项目的一些产出。在准备这个演讲时，鼓励团队成员展示在他们在某一个功能实施时如何与质量方法的连接，客户、销售代表或者高层领导如何体验。

我在小型和中型软件公司已拥有 15 年的工程和产品管理经验，我发现有两个最强有力的方法来影响文化，即创造一些仪式和认可成就。仪式可以让惯例（锻造团队特性）在背后强有力推动，以实现让团队达成共识。同时要建立奖励成功的方案，建立团队成员的激励机制，从而让他们在决策之后能够感受到一种主人翁意识，并且专注于他们最在乎的部分。

我的第一次创业经验让我学会到了这些，我曾经是一个年轻的工程师，刚刚从学校毕业，我们的工程副总裁会定义发布周期中的各个阶段，以控制源代码库的改动。在发布早期的“绿色阶段”，我们的代码库是开放的，可以进行任意更改；发布中期的“黄色阶段”意味着只接受低风险的改变；并且在最后阶段的“红色阶段”意味着每一个改动都必须经过同事的评审，达到一定的质量标准才可以通过。回顾过去，我们的副总裁持续地在传播我们当前所在的阶段（证明了领导层的重视），并且在红色阶段的同事评审真的帮助我们将质量导向深入内心，通过认可成就明智地加强了同事们的参与。这个结果就是很强的团队认同和价值分享，这是我直到今天还要坚持的。

关于作者

Jonathan Levene 目前在波士顿担任高管教练，专注于工程经理和高管的领导力开发。他在小型和中兴企业中产品开发组织中有 14 年的资深经验。之前在工程、产品管理、销售、市场和业务开发上担任不同岗位。Jonathan 为工程经理和高管们提供一些工具和以证据为基础的培训，并且指导一些项目，例如领导有效的虚拟团队和自管理团队，在其他方面影响领导人，发展最佳性能的技术人才。关于工程师领导力的文章和工具，请访问这里或者通过邮箱联系本人 jonathan@levenecoaching.com 。