质量和效率似乎永远都是一对冤家，尽管我们都希望既有质量，又有效率。
把“质量”当做宗旨的企业，通常都有一系列的规章制度，甚至是繁重且冗余的流程用来约束软件开发过程中种种“有意”或“无意”的威胁软件质量的行为。
把“效率”当做宗旨的企业，通常其内部并无严格的规章制度，甚至宽松到一个人都可以轻松地完成从删库到跑路。
从事IT行业的相关人员大多知道，软件开发不同于一般性的劳动，它并不能单纯地增加人手就能缩减开发周期，也就是说一个软件1个人开发需要10天，这并不意味着10个人就可以1天开发完成。并且在软件开发的过程中，由于需要“适应市场的快速发展”，常常伴随需求变更等不可预知的问题。也就是在前期所做的工作可能因为某个需求而全部推倒重来。
下面从要质量还是要效率两个方面来阐述，不同的侧重点所带来的的问题。
我们首先假设，公理P1：作为IT行业的从业者（开发、测试、产品等）都知道，软件开发具有一定的不可预知性。
那么在这个前提下，倾向于“质量”的企业通常情况下有以下做法：
- 通过规章制度让软件开发具有一定的可预知性
让软件开发具有一定的可预知性，这种方式有很多种实现，比较常见的手段是让需求变更的成本上升。一旦进入开发阶段（含设计阶段），需求不得随意变更，这种方式对开发人员相对比较友好，开发人员不再被随意变更的需求所打扰，但同时也对产品经理提出了更多的要求。这要求产品经理需要有高超的业务能力，以及一定的前瞻性。除了让需求变更的成本上升以外，通常也会在前期做大量的工作，包括需求评审、文档设计、设计评审等会议，在软件开发的中后期不断地进行代码评审等工作。这一系列的规章制度流程，能使得软件开发不再随心所欲，而是有章可循。显而易见，这样“传统”的开发形式，势必带来效率的下降。例如我曾经见过有的公司，一年最多发布2个版本。这在如今快速的互联网发展中是不可接受的。
而倾向于“效率”的企业，也就是通常所说的互联网公司对于效率的提升通常采取以下手段：
- 通过缩短开发周期使软件开发具有一定的可预知性
目前在部分互联网公司所倡导的“敏捷开发”实际上就是通过缩短开发周期来使软件具有一定的可预知性。我们在开头假设了了公理P1，软件开发具有一定的不可预知性。并且开发周期越长，不可预知性越大。注重质量的公司，可能更倾向于提高需求变更的成本，而注重效率的公司则缩短开发周期。两者都是为了使得软件开发变得可控。但两个不同的方式则导致了两个不同的倾向。
缩短开发周期的确会让效率变得更高，起码能更快的适应市场的需求。那为什么会说缩短开发周期会使得质量降低呢？
其实这是一个显而易见的道理，缩短开发周期，理论上来讲似乎就能缩短开发时间。10个需求需要做10天，平均1个需求不就只需要1天吗？那么我为了提高我的效率，快速响应市场变化，我就采取敏捷开发的方式，这样不就既满足了效率，同时也满足了开发时间，这样的做法似乎并不会降低软件开发的质量。这么想的通常是没有从事过技术研发的同学。仍然回到公理P1，软件开发具有一定的不可预知性。我在做当前开发的时候，所采取的的设计基本上只适用于当前的业务模型，对于未来几乎一无所知。随着系统不断地快速迭代，一次又一次的在原有的系统上叠加新的功能修改删除旧的功能。这对于软件开发者可以说是灾难性的，没有哪一个系统架构师能遇见未来的所有可能。“天下武功唯快不破”，快是快了，代码后院也快起火了。
天底下没有公司敢说我不注重质量，我只注重效率。无论是什么公司都会采取以下手段去保证软件质量。
- 通过一定的经济利益惩罚手段
一定的惩罚手段，简单粗暴地将开发人员的bug数与绩效挂钩。不过直接将bug数与绩效挂钩的情况比较少，大多情况是bug的reopen次数，以及是否有新引入的bug。其中reopen是较为常见的一种惩罚手段，同样也能较好地推动软件质量提升。
事实上，并没有哪一种绝对完美的兼顾了质量和效率，对于目前的互联网公司大多所采用的是快速迭代的开发方式。但这并不代表采用这种方式的公司质量就一定低下。
“快速适应市场的变化”这本身也是一种需求，采取快速迭代的方式实际上也是为了满足这一“需求”。阿里巴巴集团CTO行癫曾谈到过，“最早，业务比技术跑的快，技术一直追业务，因为业务增长实在太快了。前两年我觉得是技术推动业务，特别是人工智能兴起的之后，包括我们程序化交易、广告平台、千人千面、推荐、搜索大量用算法和AI，包括客服等等大量用数据智能在驱动业务”。
“业务比技术跑得快”，这意味着一定一个快速迭代的过程。而后来“技术推动业务”，意味着技术走在了业务的前面，反倒是技术追着业务打。这其中尽管并未提及质量，但我认为技术能推动业务不断向前跑，一定是因为有坚实的技术后盾做支撑，而坚实的技术后盾也就意味着有超高的软件质量。
所以，在质量与效率的权衡利弊平衡中，不妨回过头来重新审视技术的重要性。在满足“市场快速变化”这一需求的同时，不要忘记技术也会负债，欠得越多越不牢靠。