原文作者：Matt Mullenweg 原文链接

很多企业家崇拜史蒂夫‧乔布斯 (Steve Jobs)。他们说乔布斯是一个完美主义者。从 1 Infinite Loop, Cupertino【译注：苹果公司地址】走出的产品每一件都尽善尽美，让极客们垂涎三尺。他们的口号是，决不妥协！

我喜欢苹果公司的原因则与此相反：他们从不惧怕向世人展示不成熟的 1.0 版产品。

我记得我的第一台一代 iPhone。就像是等待餐厅的席位，或者是酒吧外的长队，数小时的等待让我的第一次「滑动解锁」甜美许多。我觉得我就像在《星际迷航》(Star Trek) 里手持着三度仪 (tricorder) 一样。但是，这个 AT&T 网络上的「三度仪」时常打不通电话，耳机接口跟我手头任何一个上百美金的耳机都不兼容，没有第三方应用程序，没有复制、粘贴，而且还反应奇慢，粘滞得就像糖浆一样。

现在我们知道了，令人抓狂的是，当这台最原始的 iPhone 带着所有这些缺陷发布的时候，在苹果总部的某个秘密房间里，已经有了 3GS 的可用原型机。这台机器有着更快的处理器、更好的电池寿命、正常的耳机插口……一切都那么完美。乔布斯可能已经带着它到处跑了。这件事情是多么痛苦，当你已经把一切都修复的时候，还得听着别人的批评。因为你得等组件价格降到合适区间，还要把 App Store 的一些 bug 修复一下。

也许，我不知道，他们就真的那么淡定？在 WordPress 的发展过程中，有一段黑暗时期，或者说，失去的一年。2.0 版是在 2005 年 12 月 31 日发布的，而 2.1 版是在 2007 年 1 月 22 日。凭着这两个日期，你或许会猜想，我们的开源阵营发生了分裂，有内部分歧。而事实刚好相反，2006 年是 WordPress 取得突破的一年：当年下载量达到 150 万次，同时，还有很多高质量的博客开始转用 Wordpress。这些增长的名气吸引了更多更好的开发者加入项目，使我们能以前所未有的速度开发新功能并修复问题。

真正把我们搞死的是「再加一件事情」(one more thing) 。我们当年可以轻易地发布三个大版本，只需要划下一些界限，标上「完成了」，然后提供出去。问题是，距离上次发布的时间越长，你的压力和期待就越大，然后你就会轻易地「再加一件事情」，以期让某个特性特别耀眼。对于某些项目，这真的就会永远持续下去。

我可以想象，在 iPod 或者 iPhone 发布之前，一定有团队给出同样的建议：负责复制、粘贴功能的同志就要完成任务了。我们知道莫博士 (Walt Mossberg) 一定会因为缺少这个功能而对我们说三道四的，既然如此，不如我们就等这个功能完成再发布吧。其实，如果你在第一个版本发布的时候不觉尴尬，你就已经等待太久。

苹果漂亮的手法在于他们淘汰自己产品的速度。我想，这也使「让事情先发生」的信条变得容易实施。就像我之前所说，距离上一次发布的时间越久，压力就越大。不过，如果你现有的代码还不足以支撑一个版本升级，而六个星期后你能让版本号提升 0.1，事情也不算太差。这就像旧金山和洛杉矶之间的航班，即使你错过了这班，下一班也就在一个小时之后，没什么大不了的。亚马逊的 Kindle 是这方面的标杆，每年一款新型号。

实践就像是创意赖以生存的氧气。你永远不能完全地预测公众的反应，除非你让他们直接尝试。这意味着，你没有发布的产品每一天都在失去生命，因为缺少了真实世界带来的氧气。更糟糕的是，开发并不是在真空环境下进行的——如果你突然有了个绝佳的想法，可以肯定的是，这世界上还会有两三个团队独立地产生了同样地想法，而且也在为此工作，或者，他们的想法是你所没能想到，却会对你的市场造成冲击的。（想想所有的播客公司——包括 Ev William 的 Odeo——在 iTunes 内置播客功能前后的处境。）

尽早发布能让你获得听取真实意见的竞争优势，在最好的情况下，这能够帮助你预测市场方向；最坏的情况，它也能给你带来几个你能咨询的核心用户。没什么能代替现实这个大熔炉。

或许你认为你的生意与众不同，你只有一次公关的机会，在 TechCrunch 把你公布于世时，一切都得完美呈现。但是，如果你只有一次获得关注的机会，那你就搞错了。

在 2.0 到 2.1 那失去的一年之后，WordPress 社区建立了一个颇为激进的发布计划，一年发布三个主要版本。对此，我们执行的还不错。只是在 2009-2010 时期有点松懈，因为我们再一次陷入了「再加一件事情」的误区。但是，更根本的是，WordPress 仍然是一个经过封装的软件，更新对于用户来说是种负担，我们需要想办法让它传播出去。

这就是我深爱 Web services 的原因，也是 Automattic 专注于服务的原因。在 WordPress.com，我们每天部署二十或三十次，公司里的每个人都可以这么做。我们检测部署到数百台服务器的速度，如果太慢（超过 30 到 60 秒），我们就想新办法优化它。在这种短期快速迭代的环境下，最重要的事情并不是你发布出去的代码有多么完美，而是在需要的时候你能多快地撤销更新，因为这样一来，出错所带来的代价就很小，只是一分钟级别的问题。有些人能在几分钟内让想法成型、写出代码，更重要的，发布给真实用户。我想不出比这更好的测试方法。