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

陆陆其其明明ss BBlloogg MMyy TTeecchhnniiccaall EExxppeerriieennccee,, CCaarreeeerr,, BBooookkss 第第一一版版做做 不不好好，，但但照照样样发发布布 分类： 我的书 2013-03-30 19:16 204人阅读 评论 (0) 收藏 举报 我曾经发布过的软件中没有一个能让我满意的。哪怕一个也没有 ！部分的原因是，像很多其他的软件开发者一样， 我是一个完美主义者。于是，有些问题就不可避免了： 开发计划太激进，时间太短了。我们需要更多的时间！ 我们碰到了原先没有预料到的技术问题，它逼着我们做了一个折中的解决方案。 我们的设计做错了，不 不在开发的过程中做出改变。 我们的团队出人意料地发生了内部摩擦。 客户跟我们想象中的不一样。 设计师、开发者和项 目管理团队之间的沟通效率没有我们想象中的那么高。 我们高估了自己学习新技术的能力。 这个清单还可以继续往下写。软件项 目失败的原因真是数不胜数 ！ 在项 目启动的时候，你憧憬着你的软件会成为软件工程历史上一座光彩夺 目的丰碑。然而在开发周期结束的时候， 你最终做出来的却只是那座丰碑的暗淡的影子。 看到这，你也许想要认输了——往开发计划里增加更多的时间，这样你就能在软件发布之前把它做 更好。毕竟， 软件的发布还 靠那些开发人员。 在这里我要告诉你，这种做法是错误的。 没错，你在这个项 目里把很多很多东西都做砸了。但是，你还把很多很多你尚且不知道的东西做砸了。除非你把软 件发布出去、送到用户和客户的面前，否则你无法知道那些做砸的东西到底是什么。我觉 ，用DonaldRumsfeld的 那首诗来说明这个问题再好不过了： 译者注：Donald Rumsfeld是美国的一位政治家和商人。他曾两任国防部长 （分别在第38任总统和第43任总统的时 候），是美国历史上最年轻的、也是最老的国防部长。 我们知道， 有一些已知的知道。 有些东西我们知道我们知道。 我们也知道， 有一些已知的未知。 也就是说， 我们知道有些东西我们不知道。 但还有些未知的未知， 就是那些我们不知道我们不知道的东西。 在项 目的收尾阶段面对那些无法避免的忧郁——在枪口之下妥协，还有很多令人不安的权宜之计、欠考虑的解决方 案——你可能会蹲下来，默默地舔着你的伤口。你也可能重整队伍，在将软件发布之前另外再花上几个月的时间去 修复那些问题。你可能还会 自我感觉 良好，因为你做了一个艰难的决定：你及时阻止了向全世界发布又一个错误百 出的半成品软件，确保了软件工程的质量。 不幸的是，跟发布带有缺陷的版本比较起来，这是一个更大的错误。 与其在与世隔绝的实验室里花上3个月的时间无聊地修复第一版里的问题，你不如把这3个月的时间用于倾听来 自真 实世界里使用你的软件的用户提出的反馈，尽管他们很烦人，但他们很虔诚、很专注。别把时间花在你想象中的软 件上。也别去想象你的用户。他们存在于真实世界里。你可以转过身去，利用来 自于真实世界的定向反馈，不仅可 以修复第一版里所有做 很差劲的部分，而且可以根据确凿的用户使用数据做出预测，从而能够让你把开发经费花 更有效益。 别误会，我不是说你应该发布像狗屎一样的东西。相信我，我们都是完美主义者。但现实是残酷的，它容不下我们 1 别误会，我不是说你应该发布像狗屎一样的东西。相信我，我们都是完美主义者。但现实是残酷的，它容不下我们 的完美主义。理智一些吧，抛开完美主义；要认识到，当你的软件在真实世界里的岩岸上崩溃的时候，让人失望是 难免的，但那是可以弥补的！重要的不是软件的初始状态有多么完美——事实上，有人认为， “如果你没有被你的 第一版软件搞 局促不安，那说明你还发布 不够早”——重要的是，你在把软件发布之后都做了些什么？ 你你的的团团队队对对用用户户反反馈馈的的响响应应速速度度会会为为你你的的软软件件定定下下基基调调，这是任何一次软件发布都不能起到的作用。那才是你 真正需要去提高的方面。不要再沉迷于柏拉图式的理想 （发布一款神话中的完美软件），而应该对你的用户和客户 做出及时的响应，并且通