Marty Cagan 发表于 2010年2月9日

译者：唐丰能 / 审校：潘希颖 林航 徐定翔

什么是“大爆炸”式发布？

这是指一个项目团队经过数月的努力，构思让自己的作品在一个大型新产品发布活动中一炮打响。

大爆炸式发布不等于瀑布式开发（有关瀑布式开发的来历，请参考《启示录：打造用户喜爱的产品》第27章），但它是瀑布式开发中常见的最终环节。不止在瀑布式开发中会采用大爆炸发布，Scrum团队实际上也被迫采用大爆炸发布。

为什么大爆炸式发布会产生问题？

因为它几乎从来都不顺利。通常时间紧、任务重，要发布的版本内容总是越变越多（管理层都是急性子，只要他们想得到，总是希望加入更多的功能）。过不多久，问题就来了，你要么大修大改，要么痛苦地在功能上做裁减。

此外，采用大爆炸式发布的产品，几乎没有什么时间可以让你根据上线后的实际数据对功能进行调整。很多时候，结果和预期有出入，可此时已无力回天。

此外，一次性地做出过多的修改，网站的稳定性会受到严峻考验，因为只有在上线之后你才能发现这些问题并尝试解决它们。即使不存在稳定性方面的问题，用户也会因网站一次性改动太大而心生反感。

既然有那么多问题存在，为什么还会选择进行大爆炸式发布呢？

可能有以下几个原因。

有时是因为营销部门想举办一场大型的发布活动以达到震撼效果，他们觉得在活动准备好之前，产品不应该被曝光。还好我们不必像以前那样经常做大型发布活动。即使举办了这样的活动，也要明白大爆炸式营销不等于大爆炸式产品发布。你可以采取循序渐进的方式开发产品，一点一点地发布新功能，最好让用户几乎察觉不出什么变化。

有时是因为主管定下的项目完成时间太具挑战性，要按时完成任务，产品团队不得不减少测试和发布的时间，以保证有足够的时间用于产品开发。我知道这样做也是逼不得已，但是产品不应该用这种方式开发。如果真的要按时发布，最好的方式就是采取增量式开发和部署。让产品按时上线不一定要采用大爆炸式发布模式。

有些公司，特别是大公司，坚持进行项目审查和过程监督，从而“成功”地将团队引向瀑布式开发，最后不得不选择大爆炸式发布。例如，他们会说：“你可以继续研究这一想法，但真正动手前，必须要通过评审。”于是发布任何功能之前，他们都要进行一次评审。这样一来，不想把团队引向瀑布式开发都难。也许你不得不给你的上司来场“汇报演出”，但你要做的事情还很多，别为了这点小阻碍就垂头丧气。事实上，你要是把原型和真实的用户反馈拿来让上司进行评审，没准还能给他们留下一个好印象。评审一结束，就赶快继续你的增量式构建、部署和测试吧。

所以，如果有人要求你采取大爆炸式发布，尽可能通过增量式设计、构建、测试及发布的方式来替代它。

原文链接：http://www.svpg.com/big-bang-releases/

本文节选自《启示录：打造用户喜爱的产品》一书作者的博客。该书从人员、流程、产品三个角度介绍了现代软件（互联网）产品管理的实践经验和理念。特此感谢Marty Cagan先生授权。