以“质量”为宗旨的企业，通常有一系列的规章制度，甚至是繁重冗余的流程来限制软件开发过程中各种“有意”或“无意”威胁软件质量的行为。
以“效率”为宗旨的公司，通常没有严格的内部规章制度，甚至宽松到一个人就能轻松完成从删除数据库到跑路的过程。
大多数从事IT行业的人都知道，软件开发不同于一般劳动。 单纯增加人员并不能缩短开发周期。 也就是说，一个人开发一款软件需要10天的时间。 这并不意味着10个人可以在一天之内发展起来。 并且在软件开发过程中，由于需要“适应市场的快速发展”，往往会出现需求变化等不可预测的问题。 也就是说，前期所做的所有工作都可能因为某种需求而被推翻。
下面从质量和效率两个方面来阐述侧重点不同带来的问题。
我们首先假设公理P1：作为IT行业（开发、测试、产品等）的从业者都知道，软件开发具有一定程度的不可预测性。
那么在这个前提下，偏向“品质”的企业通常会做以下几件事：
在软件开发中，有很多方法可以实现一定程度的可预测性。 更常见的方法是增加变更需求的成本。 一旦进入开发阶段（包括设计阶段），不得随意改变需求。 这种方式对于开发者来说还是比较友好的。 开发人员不再被需求的随机变化所困扰，但这也对产品经理提出了更多的要求。 这就需要产品经理具备精湛的业务能力和一定的远见。 除了增加需求变更的成本之外，前期通常会做很多工作，包括需求评审、文档设计、设计评审等会议，而中后期则不断进行代码评审等工作软件开发。 这一系列的规章制度可以让软件开发不再随心所欲，而是有规律可循。 显然效率和质量的区别，这样的“传统”开发形式必然会带来效率的下降。 例如，我见过一些公司每年发布多达2个版本。 这在互联网飞速发展的今天是难以接受的。
偏好“效率”的企业，俗称互联网公司，通常会采用以下方法来提高效率：
目前一些互联网公司所倡导的“敏捷开发”，实际上是通过缩短开发周期，让软件变得更加可预测。 我们一开始就假设公理P1，软件开发具有一定程度的不可预测性。 而且开发周期越长，不可预测性就越大。 注重质量的公司可能更倾向于增加需求变更的成本，而注重效率的公司则缩短开发周期。 两者都是为了让软件开发变得可控。 但两种不同的方法会导致两种不同的倾向。
缩短开发周期确实会让效率更高，至少可以更快地适应市场需求。 那么为什么说缩短开发周期会降低质量呢？
事实上，这是显而易见的事实。 缩短开发周期理论上似乎可以缩短开发时间。 完成10项要求需要10天。 完成1个要求不是平均只需要1天吗？ 所以为了提高我的效率，快速响应市场变化，我采用了敏捷开发方式，既满足了效率要求，又满足了开发时间。 这种方法似乎并没有降低软件开发的质量。 有这种想法的人通常都是从未从事过技术研发的学生。 仍然回到公理 P1，软件开发具有一定程度的不可预测性。 我在做现在的开发的时候，我采用的设计基本上只适用于现在的商业模式，对于未来我几乎一无所知。 随着系统的不断快速迭代，新的功能不断地被添加到原有的系统中，修改和旧的功能被一次又一次地删除。 这对于软件开发者来说可以说是灾难性的。 没有一个系统架构师能够满足未来的所有可能性。 “世间唯一不能破的武功，就是快。” 速度很快，代码后院快要着火了。
世界上没有一家公司敢说我不注重质量，我只注重效率。 无论是什么公司，都会采取以下措施来保证软件质量。
某些惩罚方法简单而粗暴地将开发人员的错误数量与他们的表现联系起来。 然而，错误数量与性能直接相关的情况相对较少。 大多数情况下，是Bug的数量以及是否有新引入的Bug。 比较常见的惩罚方法之一，也能更好地促进软件质量的提高。
事实上，没有人能够完美平衡质量和效率。 当前的互联网公司大多采用快速迭代的开发方式。 但这并不意味着采用这种方式的公司一定质量低劣。
“快速适应市场变化”本身就是一种需求，而快速迭代的做法其实就是为了满足这种“需求”。 阿里巴巴集团CTO邢典曾表示，“早期，业务跑得比技术快，技术不断追赶业务，因为业务增长太快了。 这两年我感觉技术驱动商业，特别是人工智能的兴起。 之后包括我们的程序化交易、广告平台、千人、推荐、搜索、很多算法和AI，包括客户服务等，很多数据智能是用来驱动业务的。”1
“业务跑得比技术跑得快”，意味着要有一个快速迭代的过程。 后来的“技术驱动业务”就是说技术领先于业务，但技术却在追赶业务。 虽然没有提到质量，但我相信技术能够推动业务前进，因为有坚实的技术后盾，而坚实的技术后盾意味着超高的软件质量。
因此，在质量与效率的权衡中，我们不妨回过头来重新审视技术的重要性。 在满足“市场快速变化”需求的同时，不要忘记技术也会负债累累。 你欠的钱越多，它就越不可靠。
[1]《钛媒体独家对话：最详细揭秘阿里云顶层设计及底层逻辑》
质量和效率似乎是永远的敌人，尽管我们都希望质量和效率兼得。
以“质量”为宗旨的企业，通常有一系列的规章制度，甚至是繁重冗余的流程来限制软件开发过程中各种“有意”或“无意”威胁软件质量的行为。
以“效率”为宗旨的公司，通常没有严格的内部规章制度，甚至宽松到一个人就能轻松完成从删除数据库到跑路的过程。
大多数从事IT行业的人都知道，软件开发不同于一般劳动。 单纯增加人员并不能缩短开发周期。 也就是说，一个人开发一款软件需要10天的时间。 这并不意味着10个人可以在一天之内发展起来。 并且在软件开发过程中，由于需要“适应市场的快速发展”，往往会出现需求变化等不可预测的问题。 也就是说，前期所做的所有工作都可能因为某种需求而被推翻。
下面从质量和效率两个方面来阐述侧重点不同带来的问题。
我们首先假设公理P1：作为IT行业（开发、测试、产品等）的从业者都知道，软件开发具有一定程度的不可预测性。
那么在这个前提下，偏向“品质”的企业通常会做以下几件事：
在软件开发中，有很多方法可以实现一定程度的可预测性。 一种常见的方法是增加变更需求的成本。 一旦进入开发阶段（包括设计阶段），不得随意改变需求。 这种方式对于开发者来说还是比较友好的。 开发人员不再被需求的随机变化所困扰，但这也对产品经理提出了更多的要求。 这就需要产品经理具备精湛的业务能力和一定的远见。 除了增加需求变更的成本之外，前期通常会做很多工作，包括需求评审、文档设计、设计评审等会议，而中后期则不断进行代码评审等工作软件开发。 这一系列的规章制度可以让软件开发不再随心所欲，而是有规律可循。 显然，这样的“传统”开发形式必然会带来效率的下降。 例如，我见过一些公司一年发布多达2个版本。 这在互联网飞速发展的今天是难以接受的。
偏好“效率”的企业效率和质量的区别，俗称互联网公司，通常会采用以下方法来提高效率：
目前一些互联网公司所倡导的“敏捷开发”，实际上是通过缩短开发周期，让软件变得更加可预测。 我们一开始就假设公理P1，软件开发具有一定程度的不可预测性。 而且开发周期越长，不可预测性就越大。 注重质量的公司可能更倾向于增加需求变更的成本，而注重效率的公司则缩短开发周期。 两者都是为了让软件开发变得可控。 但两种不同的方法会导致两种不同的倾向。
缩短开发周期确实会让效率更高，至少可以更快地适应市场需求。 那么为什么说缩短开发周期会降低质量呢？
事实上，这是显而易见的事实。 缩短开发周期理论上似乎可以缩短开发时间。 完成10项要求需要10天。 完成1个要求不是平均只需要1天吗？ 所以为了提高我的效率，快速响应市场变化，我采用了敏捷开发方式，既满足了效率要求，又满足了开发时间。 这种方法似乎并没有降低软件开发的质量。 有这种想法的人通常都是从未从事过技术研发的学生。 仍然回到公理 P1，软件开发具有一定程度的不可预测性。 我在做现在的开发的时候，我采用的设计基本上只适用于现在的商业模式，对于未来我几乎一无所知。 随着系统不断快速迭代，新的功能一次又一次地添加到原有的系统中，修改和旧的功能一次又一次地被删除。 这对于软件开发者来说可以说是灾难性的。 没有一个系统架构师能够满足未来的所有可能性。 “世间唯一不能破的武功，就是快。” 速度很快，代码后院快要着火了。
世界上没有一家公司敢说我不注重质量，我只注重效率。 无论是什么公司，都会采取以下措施来保证软件质量。
某些惩罚方法简单而粗暴地将开发人员的错误数量与他们的表现联系起来。 然而，错误数量与性能直接相关的情况相对较少。 大多数情况下，是Bug的数量以及是否有新引入的Bug。 比较常见的惩罚方法之一，也能更好地促进软件质量的提高。
事实上，没有人能够完美平衡质量和效率。 当前的互联网公司大多采用快速迭代的开发方式。 但这并不意味着采用这种方式的公司一定质量低劣。
“快速适应市场变化”本身就是一种需求，而快速迭代的做法其实就是为了满足这种“需求”。 阿里巴巴集团CTO邢典曾表示，“早期，业务跑得比技术快，技术不断追赶业务，因为业务增长太快了。 这两年我感觉技术驱动商业，特别是人工智能的兴起。 之后包括我们的程序化交易、广告平台、千人、推荐、搜索、很多算法和AI，包括客户服务等等，很多数据智能是用来驱动业务的。”1
“业务跑得比技术快”，意味着要有一个快速迭代的过程。 后来的“技术驱动业务”就是说技术领先于业务，但技术却在追赶业务。 虽然没有提到质量，但我相信技术能够推动业务前进，因为有坚实的技术后盾，而坚实的技术后盾意味着超高的软件质量。
因此，在质量与效率的权衡中，我们不妨回过头来重新审视技术的重要性。 在满足“市场快速变化”需求的同时，不要忘记技术也会负债累累。 你欠的越多，它就越不可靠。
[1]《钛媒体独家对话：最详细揭秘阿里云顶层设计及底层逻辑》
