第一版做得不好，但照样发布

我曾经发布过的软件中没有一个能让我满意的。哪怕一个也没有！部分的原因是，像很多其他的软件开发者一样，我是一个完美主义者。于是，有些问题就不可避免了：

开发计划太激进，时间太短了。我们需要更多的时间！ 我们碰到了原先没有预料到的技术问题，它逼着我们做了一个折中的解决方案。 我们的设计做错了，不得不在开发的过程中做出改变。 我们的团队出人意料地发生了内部摩擦。 客户跟我们想象中的不一样。 设计师、开发者和项目管理团队之间的沟通效率没有我们想象中的那么高。 我们高估了自己学习新技术的能力。

这个清单还可以继续往下写。软件项目失败的原因真是数不胜数！

在项目启动的时候，你憧憬着你的软件会成为软件工程历史上一座光彩夺目的丰碑。然而在开发周期结束的时候，你最终做出来的却只是那座丰碑的暗淡的影子。

看到这，你也许想要认输了——往开发计划里增加更多的时间，这样你就能在软件发布之前把它做得更好。毕竟，软件的发布还得靠那些开发人员。

在这里我要告诉你，这种做法是错误的。

没错，你在这个项目里把很多很多东西都做砸了。但是，你还把很多很多你尚且不知道的东西做砸了。除非你把软件发布出去、送到用户和客户的面前，否则你无法知道那些做砸的东西到底是什么。我觉得，用DonaldRumsfeld的那首诗来说明这个问题再好不过了：

译者注：Donald Rumsfeld是美国的一位政治家和商人。他曾两任国防部长（分别在第38任总统和第43任总统的时候），是美国历史上最年轻的、也是最老的国防部长。

我们知道，

有一些已知的知道。

有些东西我们知道我们知道。

我们也知道，

有一些已知的未知。

也就是说，

我们知道有些东西我们不知道。

但还有些未知的未知，

就是那些我们不知道我们不知道的东西。

在项目的收尾阶段面对那些无法避免的忧郁——在枪口之下妥协，还有很多令人不安的权宜之计、欠考虑的解决方案——你可能会蹲下来，默默地舔着你的伤口。你也可能重整队伍，在将软件发布之前另外再花上几个月的时间去修复那些问题。你可能还会自我感觉良好，因为你做了一个艰难的决定：你及时阻止了向全世界发布又一个错误百出的半成品软件，确保了软件工程的质量。

不幸的是，跟发布带有缺陷的版本比较起来，这是一个更大的错误。

与其在与世隔绝的实验室里花上3个月的时间无聊地修复第一版里的问题，你不如把这3个月的时间用于倾听来自真实世界里使用你的软件的用户提出的反馈，尽管他们很烦人，但他们很虔诚、很专注。别把时间花在你想象中的软件上。也别去想象你的用户。他们存在于真实世界里。你可以转过身去，利用来自于真实世界的定向反馈，不仅可以修复第一版里所有做得很差劲的部分，而且可以根据确凿的用户使用数据做出预测，从而能够让你把开发经费花得更有效益。

别误会，我不是说你应该发布像狗屎一样的东西。相信我，我们都是完美主义者。但现实是残酷的，它容不下我们的完美主义。理智一些吧，抛开完美主义；要认识到，当你的软件在真实世界里的岩岸上崩溃的时候，让人失望是难免的，但那是可以弥补的！重要的不是软件的初始状态有多么完美——事实上，有人认为，“如果你没有被你的第一版软件搞得局促不安，那说明你还发布得不够早”——重要的是，你在把软件发布之后都做了些什么？

你的团队对用户反馈的响应速度会为你的软件定下基调，这是任何一次软件发布都不能起到的作用。那才是你真正需要去提高的方面。不要再沉迷于柏拉图式的理想（发布一款神话中的完美软件），而应该对你的用户和客户做出及时的响应，并且通过基于他们的反馈持续改进和完善你的软件来展示你对他们的诚意。至于说你在为一个接近完美的软件发布而努力，你实际上在为一个错误的目标而浪费精力。

译者注：柏拉图（Plato，约前427年~前347年），古希腊伟大的哲学家，也是全部西方哲学乃至整个西方文化最伟大的哲学家和思想家之一，他和老师苏格拉底、学生亚里士多德并称为古希腊三大哲学家。柏拉图主义被认为是不切实际的，它宣称：理念形式是存在的、永恒的，并比世界中的现象更实在、更完美，甚至是惟一真正实在和完美的实体。

只要有可能的话，请尽早发布你的软件。然后把剩下的时间都用在基于真实世界的反馈进行的快速迭代开发上。不管你预算的时间有多少，你终将做出更好的软件来。这是毋庸置疑的！

请你相信我：即使第一版做得很差劲，坚持把它发布出去。