Seven Shipping Principles
22:54 Share

欢迎收听Rework播客，这是37signals制作的播客，主题是如何更好地工作和经营你的业务。我是你的主持人Kimberly Rhodes，一如既往地，我与37signals的联合创始人Jason Freed和David Heinemeier Hansen一起。本周，我想深入探讨37signals网站上的一篇文章，名为“七大发布原则”，这是我们关于如何以可持续的节奏发布、塑造和构建软件的指导方针。David，如果我没记错的话，我相信是你写的。让我们一起回顾一下这七个原则。我们不会对所有原则都进行详细的探讨，但我认为其中一些对大家来说非常重要和有趣。第一个原则，我们只发布优秀的作品。我认为这是不言自明的，但请告诉我们你对此的一些想法。这实际上是促使我写下这些发布原则的出发点。它听起来不言自明。

但是，当你花费数周时间做某事，时间不够了，你已经构建了一些东西，一些你可以让自己勉强接受发布的东西时，它实际上并不那么不言自明。

但它不应该发布，因为它不够好。而“好”实际上是一个相当高的标准。它比“可以”更好。我们本可以写道，我们发布“可以”的软件。你知道吗？我相信在一些机构中，这实际上也是一个很高的标准，但这不是我们的标准。我们的标准是优秀的软件。

通过将此作为标准来表达，它给了我们说不的权利。它给了我们权利说，是的，我们在这个功能、这个周期上花费了相当多的时间，但它还不是好的软件。所以我们不会发布它。我们将摒弃那种总是要交付一些东西的本能，并意识到，偶尔——这相当罕见——我可以回忆起只有少数几次我们不得不将此作为

停止块。这不会发布，因为它不够好。但它也是那些事情之一，我认为我们在之前的播客中讨论过，对“我们只发布优秀的作品”的最终检验是在最后时刻。这也是我写下这个的原因之一，就是说，你知道吗？这只是事实。优秀的软件是对你所构建内容的全面评估。它不是这里的一小部分，那里的一小部分。它是

所有的一切，正如它准备发布一样。通常情况下，当我们准备好发布或想要发布时，就是当我们完成所有部分的组装时。所以难怪这是最终检验，决定它是否应该发布。

我写下它部分原因是因为这是Jason和我经常扮演的角色，我们是发布前最后一关。但如果组织中有更多的人感到有权这样做，因为它是写下来的，那就太好了，基本上可以说，你知道吗，我们需要在这里暂停一下。也许这个项目，无论出于什么原因，只是没有及时完成。

这并不是很大的羞辱。事实上，我有时会对我们的发布率有点怀疑。我认为我们的发布率可能太高了，你不应该目标是发布所有你着手做的工作的100%。你应该目标是发布，我不知道，

80%、90%、95%。但其中一定有一些部分不够好。因为否则，要么你就是有史以来最好的软件制造商，这极不可能，要么你的标准根本达不到要求。所以发布优秀的作品。

优秀的软件，一些我愿意使用的软件，这必须是标准。这就是我们把它写下来的原因。好吧，我想补充一点小事。就像最近有很多关于MVP的讨论等等。我认为这是我们对MVP的一个问题，即最小可行产品。这标准太低了。它也像人们用它来测试想法一样。我看到David最近写了一条很好的推文，内容是：

测试不完整、敷衍的想法并不能真正让你得到你想要的结果。这就是为什么这些东西必须优秀。因为如果你想评估某件事是否优秀，你必须拿出一些你认为优秀的东西，而不仅仅是最小可行产品。因为你将得到关于它的最小可行反馈，这也不是很好。所以这就是这个想法。当你把一些东西放到世界上……

它也应该是一个完整的想法。它可以比你最初想要的小，但它需要是一个完整的想法，而不是某种部分的、敷衍的、半成品的东西。它可以是半成品，而不是敷衍的，但半成品需要优秀。你发布的东西必须优秀。它不能仅仅是某事物的敷衍版本。

好的，我将阅读下一个原则的开头，因为我认为它很有趣。我会听听你的看法。下一个原则是，当我们有信心时，我们就发布。我们在播客中经常谈论信心和直觉反应。它说，我们进行自动化和探索性测试的原因是，我们可以充满信心地发布工作，它不会造成重大问题。但是，究竟需要多少信心，这取决于团队和问题的严重性。David。

我认为当我们谈论量化时，当我们谈论我们对该产品有如此这般测试覆盖率时，这在软件开发领域经常出现。我记得曾经有人说过，我需要90%的测试覆盖率，这基本上意味着，在你产品中的所有代码行中，所有90%的代码行都将被测试。

或者他们有一个测试比率。我们为每一行生产代码编写三行测试代码。这是我听说过的比率。我总是觉得……

这什么也没告诉我。如果你机械地编写所有这些代码，我需要为每一行生产代码编写三行代码，无论你正在实现的是完全琐碎和普通的，还是你正在实现一些如果出现错误会使人们损失数千美元的东西，或者在最极端的严重性情况下，有人可能会因此而严重受伤或更糟。

你没有考虑到上下文。你应该对仅仅是不便甚至可能是美学问题的问题应用更少的最终严谨性，而不是我正在损失数百万美元或正在将人们置于危险之中。这就是严重性阶梯的意义所在。

我认为这是看待信心问题的绝佳方法。因为你对什么有信心？你真的有多自信？所以我们通常会相信它不太可能。这几乎就像举证责任一样，对吧？就像我们的……

排除合理怀疑。作为举证责任，这比我忘记了下面的那个叫什么要高得多。某种优势证据。是的。诸如此类。对。就像在法律界，他们阐明了这些严重性级别。如果你要判处某人死刑，你最好确信无疑。如果你对某些合同有争议，对吧。

这严重性要低得多。我们不必以同样的严谨性来处理它。我们甚至可能不需要12名陪审员来裁决这个问题。我们试图以同样的方式看待这一点，我们所做的许多工作都属于中间领域。你知道吗？如果它不起作用或存在错误，那不是很好，但我们也可以快速修复它。

有时我们的工作。我已经发布了很多修复程序，我知道这里没有问题，顺便说一句，总会有问题。但问题不会那么大。然后当我们修改例如我们所说的Queen Bee（我们进行所有计费的地方）时，我们在这里承担更高的举证责任。我们希望进行更多测试。它们必须更有条理。我们希望进行更多审查，对吧？

但这种仪式感必须与之成比例。而我所看到的最大错误是选择一种协议，一种仪式级别，并将其应用于所有内容。将其应用于琐碎的事情，现在你……

丹麦语有一句谚语，用大炮打麻雀。你正在用大炮打麻雀。这只是杀鸡用牛刀。与此同时，如果你真的在将人们置于危险之中，或者你可能会损失数十万美元，那么这个过程也可能不够。因此，拥有这种流畅感

信心。这就是我喜欢“信心”这个词的原因。它不仅仅是，它不是一个数字刻度。它不会像一到五一样。它再次是一种直觉。这需要一段时间来训练。

我经常看到初级程序员进来，他们想尽可能安全地做所有事情。然后它需要永远，对吧？他们想编写一百万个测试。他们想为一行生产代码编写五行测试代码。然后他们将无法发布。他们将无法适应我们六周的周期。他们会将两周的项目变成五周的项目。然后他们很快就会意识到，你知道吗？啊，

啊，好的，我刚才做的所有这些仪式，因为那是协议，我实际上做不到，也无法完成我想完成的事情。我现在必须衡量和校准它们，使其与严重性成比例。这就是魔法发生的地方，在这些权衡中。我也认为这是乐趣发生的地方。没有什么比经历更令人沮丧的了

毫无意义的清单，胡扯的清单，就像，哦，我必须这样做，因为图表上是这样说的。对。当你做一些你知道不成比例的事情时，你知道它不适合正确的事情时，这只会让人泄气。感觉就像你是在空转，浪费时间。如果有什么不同的话，我宁愿犯点牛仔式的错误。对。我们不制造起搏器。对。

所以如果我们犯了轻微的错误，我们不会杀死任何人。所以我们应该稍微偏向牛仔风格。不要太多，以至于没有人想使用我们的该死的软件，因为它完全是一堆垃圾，充满了错误，他们不断遇到问题。这也不是很有益，对吧？但这两种东西之间有一个最佳点，适合你正在做的工作的背景。

好的，David，你提到了问题。所以我将跳到第四个发布原则，即我们在发布后拥有这些问题。我认为这很有趣，因为它与我们关于“一人经理”的理论有关。它说，如果你制造了混乱，就清理你自己的烂摊子。在发布后的一段时间内关注错误跟踪器。当他们从客户那里获得反馈时，成为支持的首要联系人。如果你做了这项工作，你就拥有了上下文，如果它歪了，你应该把它弄直。好的。

这完全是关于激励机制。如果你是一名产品设计师或开发人员，你可以把东西扔过墙，而不必担心它们是如何着陆的，或者它们着陆时会造成什么样的混乱，你将不可避免地变得不那么谨慎。你的信心计量器将失灵，因为你没有来自现实的反馈来校准它。你认为你做了足够的测试，因为你没有看到该死的错误。

你没有看到客户的该死的反馈。所以你与现实隔绝，与

每当你与现实隔绝时，你将不可避免地创造你自己的现实。哦，我发布了很棒的软件。我不知道你在说什么。这太棒了。我做了所有测试。测试并不重要。重要的是软件是否没有错误。这是最终结果。我们不是在寻找这些中间结果。我们不是在寻找你核对关于你写了多少测试的框。我们正在寻找

无错误的软件，或者足够无错误以达到我们所追求的严重性。所以我认为我们过去在这个问题上犯过错误。其中一些来自在我们拥有或完全尊重我们的冷却时间之前。这通常是冷却时间的魔力的一部分。我们的冷却时间。所以我们以六周为周期工作，然后在下一个周期开始之前有两周的冷却时间。

这段时间需要用于两件事。如果你没有一个一直运行到最后期限的项目，它需要你漫游和清理东西。但它本质上也是超时。如果你有一个一直运行到最后期限的项目，

但你需要在它投入生产后清理它。我们有过一些项目过于紧密地接连运行的情况。有人会做一个主要功能，他们会把它发布出去，然后砰的一声，他们就开始第二个项目了。然后，是的，谁来清理这个烂摊子？正如我们所说的，值班的人。现在他们坐在那里想，哦，我必须从第一性原理来理解这个功能。我没有构建它。

这实际上会在团队内部造成一些摩擦。我看到这种情况甚至在我们过去不那么尊重这一点的团队中也发生了。我认为这对于任何一方都不好。对于感觉自己只是被交给了一堆垃圾的人来说，这不好。

他们必须弄清楚这一切是如何运作的。而对于那些可以把垃圾扔过墙的人来说，这实际上也不好，因为他们学不到东西。他们实际上无法改进。他们无法测试他们的软件设计理论是否充分或良好，因为他们被剥夺了来自现实的反馈。我认为对于软件开发人员来说，有一个最佳点，他们可以从事新的工作，并且

但也可以在野外看到这些东西。这就是发布的乐趣，看到你构建的东西实际上被很好地使用，不是从两公里外，而是从最前面，你看到，哦，该死，是的，那里有一个问题。所以我认为，让公平原则发挥作用，你放进去的东西，你知道吗，你必须把它再拿出来，这对双方来说都是一件礼物。好的。

好的，这个，我觉得，Jason，这个可能同样适用于设计方面和编程方面，那就是如果不对，我们就不会发布。我知道你在几期播客前提到过我们正在开发HiRise六个月，完全重新设计了它。告诉我这如何适用于设计方面。是的，我会说它更偏向于产品方面，也就是所有方面。但我给你举个例子。所以我们现在正在Hay中开发一个功能。

最初它能够使用键盘、J和K或箭头来回移动电子邮件。由于一些技术原因，我们无法在我们想要的所有地方做到这一点。所以它只能在少数几个地方工作。所以我们就是这样构建它的。我正在使用它。这里有些不对劲。就像一种气味，用David的话来说，就像有什么东西闻起来不对劲一样。就像

是的，在大多数情况下它都能工作，但这里有一个不寻常的边缘情况。我可能会经常发现自己处于这个角落，而且它不起作用，这很令人沮丧，我不知道为什么。我无法向人们解释。我的意思是，我可以从技术上解释，但是，

这很尴尬。这将是一个非常令人不满意的解释。所以我们暂时放弃了这个。我们可以发布它，因为它大部分都能工作。但我认为，是的，让我们暂时放弃一下。我们想做什么？所以我们现在想做的是，我们基本上想让它更容易快速浏览你的未读邮件。

你可能想要使用键盘的原因是因为你想查看一个然后转到下一个，然后转到下一个。你想快速浏览它们。这个想法是快速浏览它们。这就是这个想法。在大多数情况下，键盘比鼠标更快。所以我们退后一步说，好的，所以我们想这样做。还有其他方法可以做到吗？

我们查看了我们在Hay中已经使用的方式，它恰好是一个有趣的布局，我们将事物堆叠在一起。在计算机上滚动非常快，无论是在移动设备还是台式机上。就像，如果我们只是让你滚动浏览你的未读邮件，这样你就可以回复一些你需要的邮件，标记一些你不需要回复但想标记为已读的邮件，然后当你完成后，如果你想，就说标记所有为已读。就像，

也许我们可以这样做。所以我们开始尝试以一种方式解决问题，开始使用它，本可以发布它，但它并不完全正确，退后一步，从更广泛的角度看待它，并提出了一个我认为更好的想法。当我读到David写的那段话时，这就是它对我的意义。

它也可以是一件审美的事情，比如比例不对，按钮不在正确的位置等等。但对我来说，更多的是，这是否在做它应该做的事情？这是它能做的最好的方法吗？不是最好的方法，因为总有更好的方法，我想。但这感觉像是解决这个问题的正确方法吗？我们真的找到了问题的根源吗？我们是否在角落里留下了一些未知的魔法功能？我会说，让我解释一下这意味着什么。我不喜欢特殊的规则，基本上，或者我应该说隐藏的规则。我称这些为魔法角落。这是我自己的愚蠢……

内部版本。但基本上，当有隐藏规则时，比如，箭头在每种情况下都能工作，但只有这四种情况除外。没有人知道这一点。没有人会知道这一点。当他们遇到它时，他们会问我们问题。我们必须解释这些隐藏的条件。好吧，在这种情况下，如果你有这种情况，这将不起作用。我不喜欢这些。

所以每当我遇到这些情况时，我都会退后一步，我想，我不确定这是对的。我认为我们还不能发布这个。也许有时我们可以，但很多时候我们不能。让我们想出一个不同的方法，这样我们就不会有这些隐藏的规则。这就是我对这个特定原则的理解。我不知道这是否是它的本意，但这就是我的理解。我认为与此相关的推论或相关的事情是，当事情变得困难时，当有些事情不太起作用时，你

你应该总是质疑前提。为什么这么难？正如Jason所说，我们在这里想做什么？我认为在这个具体的例子中，我们从一个

解决方案而不是问题开始。所以解决方案是，我想能够使用键盘快速浏览我的电子邮件。好的。这与退后一步，进一步查看问题并不相同。我想更快地处理我的电子邮件。这是一个更通用的版本。这与键盘无关。它甚至与从一个到另一个无关。它关乎一个基本的前提。当我们遇到这些技术问题时，为什么解决方案在所有情况下都不起作用，

这正是发布原则应该做的事情。它只是提醒你，等等，让我们退后一步。这很难是有原因的。

我们可以让它变得容易吗？编程中有一句很棒的谚语，其本质是，如果你要进行艰难的更改，首先要使更改变得容易，然后使容易的更改变得容易。现在，使更改变得容易可能很难，但这就是你在概念上和实践上清理事物的方式。我们需要清理一下我们试图解决的问题的概念。

而且正如这些发布原则经常发生的那样，为什么它们被称为发布原则，而不是开发原则，是因为那一刻的清晰度是在最后时刻出现的。当所有部分都重新组合在一起时，它就会出现。这通常是你真正可以退后一步质疑整件事的唯一时间。这是对的吗？

这就是为什么我们需要把它写下来的原因，因为你还有其他的影响。我们完成了。我们正在发布，对吧？就像它被称为发布原则一样，因为我们准备把它推向世界。那时你需要暂停。那时最艰难的暂停需要发生，因为你可以推动部署。它可以发布出去，你可以说服自己，你正在发布的东西比什么都没有好。

这是一个非常低的举证责任。我从不想或很少想处于这种情况，在这种情况下，我们签署了比什么都没有更好的东西。我的意思是，这是一种多么令人沮丧的工作方式。比什么都没有好？那是你的标准？就像不存在或其他什么？无论那是什么，即使它是完全的垃圾？

我的意思是，拜托。你必须把你的目标定得比什么都没有好一点。所以这是一些事情，当我听到我的内心独白说比什么都没有好时，我会尝试让自己编码。只有一种反应，对吧？它只是与这个相连。如果不对，我们就不会发布。比什么都没有好。不要有这么低的标准。稍微抬起你的下巴。为即将发布的东西感到自豪。比什么都没有好。

好的。最后一个我想深入探讨的是最后一个。我们根据自己的胃口发布。David，你谈到了我们六周的周期和两周的冷却时间。我确实想读一句我发现很有趣的话，它说，就像一家伟大的公司可能是一只价格过高的糟糕股票一样，如果一个伟大的计划被追求远远超过了胃口，它也可能成为一个错误。是的。

我很想听听你对此的看法。然后，如果你有一些例子，也许是我们突破了胃口的界限。我认为在编程领域作为一个普遍的原则，这通常被称为镀金。你拿一些东西……

它有存在的理由。你只是装饰它。你只是，上面有很多装饰。上面有很多装饰。还有所有这些其他的东西，因为你想让它完美，这也是贯穿这一切的一种压力，完美是优秀的天敌。

而优秀是我们想要做的。第一个原则是，我们发布优秀的作品。第一个原则不是我们发布完美的作品。这可能是一个完全的陷阱。而且通常情况下，这种完美掩盖了实际上更深层次的问题。你正在完善一个对有缺陷的前提的特定解决方案。这毫无乐趣。我更愿意对一个伟大的前提，对一个伟大的见解有一个足够好的解决方案，

我认为这就是我们有时必须权衡的东西，对吧？当我们试图在短时间内完成事情时，就像这六周的周期一样，我们必须权衡我们内部的质量，我们前提的质量，我们设计的质量以及实现本身。

当我被迫在这两件事之间做出选择时，我总是会选择清晰的概念，总是选择清晰的想法，清晰的路线。如果你看看Jason提到的例子，在你的电子邮件之间来回切换，使用键盘以更传统的方式跳转到另一个实际上相当复杂。

就像我们必须做一些复杂的工作才能使缓存正确。我可以这样看，这很聪明。这是对它的巧妙实现。是的，这是对有缺陷的前提的巧妙实现。因为现在我看到我们想出的另一个解决方案，我想，哦，是的，我们只是在重复使用我们已经拥有一些实现位，但它被用于服务于对人们实际想要做什么的一种相当新颖的见解。♪

好的。好吧，我会链接到37signals.com/thoughts上的七大发布原则。但在此之前，Rework是37 Signals制作的。你可以在我们的网站37signals.com/podcast上找到节目说明和文字记录。完整的视频片段可在YouTube上观看。如果你对Jason或David关于更好地工作和经营你的业务有任何疑问，请给我们留言708-628-7850。你可以发短信到这个号码，或发送电子邮件到[email protected]。