质量管理：层层卡点，一次把事情做对_一次就把事情做好成本总是低的反面例子

今天我们来聊一聊质量管理的话题。

说到质量，很多人会说：“工期太紧了，能按期提测就不错了，Bug 多一点也正常。质量好不好？不好说。如何提升？不知道，QA 会保证的呀。”

我见过的大部分程序员，对自己的代码质量要求还是很高的。不过但是，一旦遇到赶工压力，尤其是在 Deadline 之前，就很可能会把完成度很低的代码交出去，心想“反正有人给我检查，到时候再说吧”。但是，这个时候，这些代码就好比是一台“行走的 Bug 制造机”，后患无穷。

我曾经在一个技术债特别严重的部门中，面向各级程序员做过一轮抽样的访谈调研。调研的结果是，程序员们只有 27.2% 的时间在做真正产生价值的编码工作。但是，他们会花 20.7% 的时间，进行需求质量和代码质量问题所引发的 Bug 修复、返工和紧急上线工作。

质量成本分为两类：一类是事前防止失败的一致性成本；一类是事后处理失败的非一致性成本，包括内部 Bug 引发的返工成本，以及外部 Bug 导致的用户侧成本。

近些年来，越来越多的公司在严格控制测试人员的比例，鼓励开发人员通过各类技术手段从上游保障质量，就是因为越发地认识到：事后检查处理的代价其实是最高的。

实际上，质量是规划、设计、建造出来的，不是检查出来的。预防高于检查，预防错误的成本通常比在检查中发现并纠正错误的成本低得多。

我们都知道，一次性把事情做对的成本是最低的。而一次性把事情做对就意味着，我们要有意识地提升预防类工作的占比，从根本上降低内部 Bug 率和外部 Bug 率。在这个质量改进的过程中，开发人员是绝对的关键力量，而非测试人员。

那么