问题描述
有人提出了一个问题，即如果一家公司在交付软件方面的速度已经足够令客户满意，那么它是否仍需要DevOps呢？从业务的角度来看，DevOps是关于速度和质量的，对吗？在以下选项中，哪个适用于这种情况？
1. 他们进行或已经进行了足够水平的软件开发，无需进行任何更改。
2. 他们正在进行DevOps，但可能不知道或给它取了另一个名称。
3. 他们采用了与我们所知的DevOps完全不同且更好的方法，我们应该在为时已晚之前弄清楚这是什么（在情况变得糟糕之前）。
4. 他们犯了严重错误：他们的速度和质量低于他们的实际水平，而他们将在下一份财务报告中意识到这一点（前提是他们能够存活足够长的时间以查看报告）。
解决方案
以下解决方案针对问题中提到的不同观点进行了分析和讨论。
DevOps是不同的方法，也是更好的方法
一些人认为，DevOps并不仅仅是一种不同的方法，它是一种更好的方法。为了更好地理解这一观点，我们可以将问题放到另一个语境中，即工业时代、铁路和蒸汽锤的语境中：
问题重新提出：一家铁路公司在铺设轨道的速度已经足够，是否还需要蒸汽锤？
从商业角度来看，蒸汽锤的目标也是速度和质量，对吗？对于一家已经足够快速为客户铺设轨道的建筑公司来说，以下哪种情况可能适用？
- 他们以足够的水平铺设轨道，无需进行任何更改。
- 他们使用蒸汽锤，但可能不知道或将蒸汽锤称为其他名称。
- 他们采用了与传统蒸汽锤完全不同且更好的工具，我们应该在为时已晚之前找出它是什么。
- 他们犯了严重错误：他们的轨道铺设速度和质量低于他们的实际水平，当他们开始输掉合同时，他们将会意识到这一点。
显然，答案可能是第四种情况。这家假设的公司可能在下一份财务报告中看不到问题，可能需要几年时间，但最终将清楚地看到为什么竞争对手在仍在手工“铺设轨道”的企业面前表现出色。当然，他们可能已经开发出了一种效率更高、不易故障或故障率较低的柴油动力锤，但这不太可能。
认为他们能够胜过蒸汽锤的想法将使这家公司落后。当然，个别团队可能会发生蒸汽锤爆炸和瓦解的情况，也许在那种特定情况下，以传统方式进行操作可能更有效，但他们是规则的例外，问题可能是他们的蒸汽锤建造得很差和/或维护不善。
工业时代正在来临，铁路公司可以选择查看竞争对手，然后尝试获得自己的蒸汽锤，或者被落在后面，最终走向无关紧要和过时。
DevOps也不例外。它只是自动化的另一次迭代，公司可以选择拥抱或忽视，但后者可能会面临风险，就像忽视蒸汽锤一样。