译自《如何让你慢下来：一种建设方式》，作者 AJ。
在科技界，软件已成为一种宗教。在软件驱动的竞争行业中，公司面临着巨大的压力，需要先于竞争对手发布新产品和新功能。一种常见的方法是设定为期两周的激进期限，由一小群开发人员以流水线方式工作，以达到不可更改的发布日期。
但如果这不是打造产品的最佳方式怎么办？
过去 12 年来，我一直在经营一家软件公司，在此之前，我学习过软件工程，并获得了计算机科学（编程系统）博士学位。虽然敏捷和现代软件方法论中蕴含着一些智慧，但它们并不是我们今天构建软件的方式。
加速开发的承诺往往会产生相反的效果。此外，无休止的开发节奏和不令人满意的开发方式导致开发人员精疲力竭并辞职。尽管经济存在不确定性，
不到一半的开发人员表示他们对目前的工作非常满意。
我们使用的方法使工程师能够以正确的方式构建正确的功能，而无需设定截止日期。它支持精益团队自主设计整个功能，而不仅仅是孤立构建的组件。而且，至关重要的是，它涉及对客户实施纪律，不承诺新软件的交付日期。最终结果，也许令人惊讶的是，是一个产生更高吞吐量的开发过程：单位时间内交付的功能更多。
我鼓励您考虑这种开发方法，而不是默认导致高水平技术债务和开发人员流动率的行业规范。
截止日期对软件开发的影响不同于对其他学科的影响。它们可能会产生严重的长期负面影响，鼓励开发人员提交不合标准、目光短浅的代码以满足截止日期。这会导致代码质量差、工程决策不当（事后修复成本高昂）以及工程师沮丧。
因此，虽然在任何时候，投入开发人员似乎都是完成工作最快的方式，但实际上负面影响会不断积累，导致随着时间的推移，开发的新软件越来越少。
听起来很直观，如果你进展顺利，就必须尽可能快地行动，但在软件开发中，你很少会直线前进。通常，你会从一个高优先级问题曲折地走向下一个高优先级问题，修复过去的问题和由于最后期限压力而引入的错误。
如果你一直直线慢跑，你可能会跑得更远，而且不会那么累。
软件截止日期优先考虑速度而不是质量
许多领导者对软件的看法与他们对业务其他部分的看法相同：由截止日期驱动的运营节奏。就像营销团队必须在 10 月 31 日之前制作节日广告活动，或者财务团队必须在月底结账一样，工程团队也需要在规定日期之前发布新产品或新功能。
这种想法忽视了这样一个事实：开发软件与其他商业实践有着根本的不同，因此它不适合在最后期限前完成任务。以下是三个重要原因：
让我们分解一下。
代码库非常复杂
首先，很难预测实现一个新功能（即使是一个简单的功能）需要多长时间，因为它很少是单独完成的。相反，新功能通常会添加到现有的代码库中，并且它们的细微差别（例如有关安全性、性能和可维护性的问题）通常只有在编写代码时才会发现。
而且由于代码相互依赖性如此之强，为一个好的实现添加新功能通常需要重写新功能所依赖的其他代码。这就与预设的截止日期产生了冲突：当工程师深入研究代码时，当截止日期临近时，他们常常不得不走捷径——“意大利面条式代码”、“脆弱的实现”等等——即使他们知道实现某些东西的正确方法，仅仅是因为截止日期没有预料到，无法适应这些挑战。
高标准正确性
其次，“正确”在软件中的含义与在营销计划或销售策略中的含义不同。你可以在固定的截止日期前写一份足够好的新闻稿，如果它可用且真实——即使它并不完美——它也可以发布。然而，在代码中，任何偏离理想的情况都被视为缺陷，必须进行分类。它可以被忽略（导致客户愤怒），也可以在生产中以高昂的成本修复——通常比发布前修复的成本高出几倍。截止日期将更多的错误推向生产，导致工程人员花费更多时间来修复这些昂贵的生产错误，而为客户构建新功能的时间更少。
错误决策不断累积*
第三，糟糕的实施和架构决策的下游效应会不断加剧。营销人员今天可以写出糟糕的新闻稿，明天却可以写出好的新闻稿。但新代码依赖于旧代码：其功能、结构和使用的范例。即使没有明显缺陷的代码也可能存在这些缺陷。现在草率地决定如何构建应用程序可能会使以后添加新功能变得更加困难，从而随着时间的推移减缓开发速度。这种“技术债务”是工程部门的祸根。它可以让您今天更快地发布特定功能，但代价是损害未来的开发。
人越多问题越多
当您试图在某个截止日期之前发布一项关键新功能时，您通常会指派很多工程师来处理它。然而，大型工程团队面临两大挑战：巨大的沟通成本和孤立的实施。这些挑战降低了工作效率和质量。
当每个开发人员只负责一个大型实现的一小部分时，他们就不得不花时间相互协调，即便如此，结构性问题也会使交付高质量的实现变得困难。想象一下，如果后端团队更改 API 以向前端公开关键信息，前端工程师的工作就会容易得多。进行此类更改所需的沟通和重新排序量通常非常大，大多数工程师根本不会费心。
更重要的是，最好的实现不仅仅是针对每个部分进行局部优化，而是针对整个功能进行全局优化，并在整个堆栈中进行一致的实现。这些实现在大型团队系统中几乎不可能实现，因为除了能够预见所有问题的全知架构师之外，没有人有权力在没有超人级沟通能力的情况下做出所有必要的更改。
取消最后期限并缩减团队规模
我们如何构建一个能够提供高吞吐量、高质量代码并让工程师满意的系统？
首先，从取消截止日期开始。在我们的模型中，工程师决定何时发布功能。因此，他们能够做出原则性的工程决策，决定现在实施什么，以后实施什么，从而交付比在两周截止日期前做出决策更好的代码。
其次，较小的团队被分配到不同的功能，并被赋予更大的范围。由于团队规模较小（通常只有一名工程师！），因此可以同时开发许多新功能。这些单独的程序员或小团队负责从后端到前端的整个实现。没有每日站立会议，也没有不必要的沟通。而且由于工程师控制着全栈实现，他们可以就如何构建他们的功能做出原则性的工程决策，而不受他们碰巧拥有的代码库部分的限制，从而提供更具凝聚力的实现。
这两种理念的共同点在于，它们为原则性决策提供了制度支持，因为今天的良好决策将带来明天更好的结果。当工程被视为一个没有编写代码、正确性要求或任何其他可能产生下游影响的角色的部门时，这一基本事实很容易被忽视。
违反直觉的结果是，尽管单个项目需要更长的时间才能交付（没有最后期限、团队规模较小），但整体生产率却更高：我们有更多的项目正在进行和完成，每个工程师可以完成更多工作，因为他们花更少的时间处理关键生产错误和技术债务，而花更多时间在高质量的代码库中编写代码。
工程师们也更开心了。他们不必因为截止日期提前而去解决自己引发的问题。他们可以更自由地合作，因为他们不必在帮助同事和紧迫的截止日期之间权衡利弊。而且，由于他们没有被局限在代码库的某个特定部分，他们可以不断学习新概念并应对新挑战。其下游的好处是更强大的文化和更优秀的工程师。
让您的顾客满意
你可能会问：我们如何在没有最后期限的情况下准时交付产品？首先，事实证明，工程师喜欢交付代码，而且由于他们拥有整个功能，因此他们非常积极地希望看到他们的项目取得成果。
其次，我们的工程师不会凭空做出决定。他们明白，在竞争激烈的行业中，交付软件是我们的主要市场优势，我们的用户依靠新功能保持竞争力，我们像其他任何企业一样奖励高绩效。
第三，我们拥有大量的支持和透明度；领导每周都会与团队一起检查软件进度，以解决任何障碍。我们不会放任事情发展，让每个人都按照自己的方式行事。我们不会随意设定影响工作质量（和乐趣）的最后期限。
另一个常见问题是，我们如何承诺在特定日期向客户提供特定功能，答案是，我们不承诺。我们的客户很高兴，因为我们生产高质量的软件，并且比竞争对手更频繁地提供新功能。请记住：我们方法的重点是我们随着时间的推移发布更多软件。
然而，我们确实与客户分享了我们的产品路线图，以便他们能够影响其方向和优先级。但是，如果潜在客户说：“我们必须在 10 月之前提供此功能，否则您将无法赢得我们的业务”，我们会拒绝，因为这样做会损害我们产品的质量并损害其他客户的利益。令人惊讶的是，很多时候这些潜在客户都会理解我们提供的价值并无论如何都会签约。对于那些没有签约的人，我们知道他们会回来，因为我们会在一两年内走得更远。
这种模式需要领导层的纪律性和营销部门的理解，尽管我们今年可能会因为这一政策而失去三笔交易，但明年我们将凭借尖端产品赢得 30 笔交易。
长期策略将赢得胜利
我们的模式注重长期成果，而非短期成果，因此并不适合每家企业。例如，仍在确定产品与市场契合度的早期初创公司需要快速试验以了解市场需求。他们可能希望快速测试假设，因此优先考虑少数功能的速度，而不是众多功能的吞吐量。
然而，一旦他们建立了产品与市场的契合度，他们的工程目标就会从以实验为主转变为以执行为主。他们会知道需要构建什么才能在行业中取胜，现在他们只需要尽快实现目标。我们的模型最适合他们。
软件开发的黄金三位一体就是拥有一支快乐、积极进取的工程师团队，他们编写高质量的代码并发布大量功能。工程师喜欢在我们的系统上工作，因为他们对自己的工作负责。他们不必为了满足任意的最后期限而牺牲技术上可靠的实现；他们总是在学习新技能和新领域，而不是被孤立在代码库的狭窄部分；他们不会不断地在生产代码中救火；他们以高频率发布有意义、有凝聚力的解决方案。这种对高质量代码的重视推动了开发吞吐量，最终使整个企业和我们服务的用户受益。
本文首发于云云中生（），欢迎大家访问。