质量免费吗？

本文首发于个人网站「BY林子」，转载请参考版权声明。

---

两个场景

场景一：有限经费与质量改进

“要写自动化的单元测试、E2E测试，就会需要更多的钱，可是我们经费有限暂时做不了。”

“CI上配置SonarQube扫描，对于扫描出来的问题我们也没有经费修复，这个举措也是没法实现。”

……

某IT团队在推进质量改进系列举措的时候总能听到这样的声音，就是由于经费有限很多的举措都实施不了。这似乎成为了一个困扰许多团队的难题，因为供应商往往要求额外费用来支持自动化测试和安全漏洞修复等。

这种困境的核心问题在于，有限的经费似乎成为阻碍团队提高质量的主要障碍。其实，需要全面理解质量改进的投入：质量改进是一项短期支出，更是一项长期的投资。

短期内去修复已有的代码Bug、安全漏洞，或者在原本没有自动化测试的情况下去增补自动化测试，确实需要额外的投入，因为这不属于新功能开发部分的工作内容。但是，代码漏洞的修复可以提高代码整体质量，而自动化测试能对代码改动提供快速反馈，能更有效地保障软件的质量。从长远来看，这些举措的收益都是大于短期投资的。

场景二：业务压力与质量折扣

“我们业务方太强势，上线日期定了以后给到我们很大压力，我们完全是Deadline驱动，交付时间很紧，得满足最后期限，很难保障质量。”

“我们想跟业务方交涉，要保障质量他们得让我们有足够的时间和投入，但是业务方认为市场竞争太激烈，上线日期定了就不能动了，只能压缩我们的时间，同时也要求我们保障质量。”

某IT交付团队如此描述他们的现状，感觉很无助。这种情况下，团队往往感到被迫在时间和质量之间做出抉择，导致质量无法得到充分保障。

快速交付和高质量真的是矛盾的吗？其实不然，快速交付和高质量是完全可以和谐共存的。 通过合理的开发流程，小步迭代式开发，从需求源头开始把控质量，在每个环节做到快速反馈，实现缺陷预防，既可以做到短期内快速交付，也可以长期内保持高质量。

当然，过短的时间内要求开发过多的功能确实也是不现实的，尤其是需求都没有清晰描述还需要开发团队不断去澄清的情况。因此，负责交付的IT团队需要采取合适的策略跟业务方进行沟通。

IT跟业务方应该是同样服务于业务目标的，不应该是利益冲突的对立方，不能说“你不给我更多的时间我就没法交付更高质量的产品”，而是需要加强沟通与合作。IT需要跟业务方对齐业务目标，基于业务目标，考虑如何最大化业务价值的交付，并且能保障质量。 这就可能涉及到对需求重新梳理，进行价值排序，调整合适排期，对需求质量的把控等一系列的优化。

质量免费

美国管理学家菲利浦·克劳士比于1979年出版的书籍《质量免费（Quality is free）》被誉为质量革命的圣经，是管理学的经典名著，中文版也于2011年面市。虽然书的年代比较久远，且内容主要关于工业制造的质量，但核心思想对今天的软件交付一样是适用的：追求零缺陷，一次性把事情做对，质量不仅是免费的，长远来看能降低成本。

零缺陷理念

零缺陷的要旨是预防缺陷的态度，它的意思就是“第一次就把工作做对”，如此而已。

—— 《质量免费》 【美】菲利浦·克劳士比

软件交付确实比工业制造要复杂得多，而且今天的软件生态也存在居多不确定性因素，但我们同样可以以追求零缺陷的心态去开发软件，做好缺陷预防工作，减少返工浪费。

可能有朋友会记得我在讲质量是什么的时候提到过“质量不是零缺陷，不是…，不是…”，为什么现在我又提到要追求零缺陷呢？这两者表达的含义是有区别的。

1. 软硬件质量要求的差异

《质量免费》中提到的“零缺陷”是针对硬件制造来说的，我们知道硬件质量通常比绝大多数的软件质量要求要高，硬件产品中的某个零配件如果有缺陷有可能导致整个硬件产品不工作，而软件产品对于某些不是那么关键的功能甚至是可以允许带着缺陷上线的，只要能满足用户使用即可。

2. 质量不是零缺陷

质量不是零缺陷，意思是软件质量不能一味追求没有缺陷，而是要结合业务目标考虑，符合业务需求、能满足用户使用，当然，也会有相应的非功能需求需要满足。总之，软件质量要以业务价值驱动，只需做到恰到好处。

3. 软件开发也需要追求零缺陷

“零缺陷”虽然是从硬件制造行业提出，但其强调的是一次性把事情做对的关键理念。我们经常提到的质量内建就是强调的缺陷预防，在每个环节都尽量做好，将质量内建到软件产品中，这跟零缺陷理念是完全契合的。

软件开发中的“一次性”把事情做对

克劳士比在《质量免费》中提出了质量成本的概念，强调了预防质量问题的重要性。他认为花费在预防和纠正质量问题上的成本是“免费”的，因为这些成本相比于质量问题导致的损失来说是微不足道的。

我们从下图的变更成本曲线图也能清晰看到不同阶段成本的差异：

因此，如果能一次性把事情做对，实现缺陷预防，质量不仅是免费的，最终还是可以降低质量成本的。

当然，人无完人，加上软件开发的复杂性，要求所有人所有环节都能一次性把事情做对显然是不现实的，这也是我前面标题中给“一次性”加引号的原因。我们认为，质量内建并不是严格意义上的不能有任何缺陷暴露，而是需要在软件开发生命周期中尽早地把事情做对，并且通过持续的获取快速的反馈来纠偏。

质量内建可以理解为在软件开发全生命周期中，从需求到线上频繁地执行PDCA环，小步前进，持续反馈验证，及时调整改进。如下图所示：

软件行业质量内建相关实践

质量内建的核心主要有测试左移、测试右移、快速反馈和全员负责四个方面，对应的典型实践通常有（不限于）以下这些：

一些前沿的互联网科技公司，比如Google、Amazon和Facebook等，通过全流程的标准化和大规模的自动化将这些质量内建实践实施的更为到位，软件交付的质量和效能都得到了很大的提升。

（PS：思维导图原图可从我的博客网站网页顶端菜单栏【资源下载】页面下载，或点击此链接进入资源下载页面。）

总结

零缺陷就是要求尽可能把事情做对，实现缺陷的预防。软件行业的零缺陷理念不是一味追求没有缺陷，而是要做好质量内建，将质量做到恰到好处。

从头开始一次性把事情做对，质量就是免费的。很多人认为质量不是免费的，那是因为已经欠债了，需要花钱去还。

IT交付团队要跟业务方对齐业务目标，加强沟通与协作，从需求源头把控质量，共同追求质量和效率的平衡，以实现最大价值的交付。

【推荐阅读】

• 《质量免费（Quality is free）》，【美】菲利浦·克劳士比
• 团队为质量负责
• 敏捷测试的核心
• 构建测试的体系化思维（进阶篇）
• 敏捷团队的质量保障赋能
• 业务价值驱动的测试
• Google、Amazon和Facebook的质量内建实践思维导图

---

本文首发于个人网站「BY林子」，转载请参考版权声明。