【产品经理国外优秀博文翻译之2】大范围发布

玛蒂·卡根发表于2010年11月5日
 

原文地址：http://www.svproduct.com/big-bang-releases
 

标签：产品开发流程，大范围发布，瀑布模型

 

什么是“大范围”发布？

这是指团队为项目工作了数月之久，以期在一个大产品创建活动中促使产品上线。

请注意，大范围不一定与瀑布模型一样，但它是瀑布模型中很常见的结果。不过它也不限于瀑布模型。 Scrum 团队实际上也被迫进行大范围发布。

为什么这是问题？

因为它几乎从来都没有顺利过。通常时间很紧迫，因为这些大版本仅仅是趋于更大（如果在可预见的未来只有这么一个版本，根本不可想象管理层愿意等着在下一个版本中添加他们最喜欢的功能）。过不多久，你要么要处理大问题，要么痛苦地在功能上做裁减。

此外，通过大范围发布的话，只有很少的预留时间去应付基于上线之后的真实数据的调整。很多时候，事情并不完全像期望的那样，但此刻为时已晚。

同样，一次性地做出这么多的修改，网站的稳定性要经常接受考验，因为只有在上线之后你才能发现这些问题并尝试解决它们。即使没有稳定性方面的问题，用户也会因网站一次性被改动了太多地方而反应强烈。

那么，为什么会这样？

可能是这几个原因。

有时候，营销部门想进行一个大的发布活动，他们认为没有人能看到它，直到他们准备好了。幸运的是我们不像往常一样也做大的发布活动，但即使你这样做，你也不想混淆营销与产品的大范围。最好还是促使产品增量式开发，即使你禁用功能以让客户看不出来。

有时主管决定了一个咄咄逼人的日期，产品团队认为要按时达成的话就要最大限度地保证开发时间，减少测试和发布的时间。我知道直觉上说不过去，但这只是不怎样的软件工程。如果真的要按时发布，最好的方式就是增量构建和部署。不要通过大范围的流程而把上线日期搞乱了。

最后，有时候公司坚持进行项目审查或过程监督，来有效地推动团队的瀑布模型执行而进行“大范围”。特别是在大公司。例如，他们会说：“你可以继续研究这一想法，但在你真正开始做任何事情之前，必须要通过评审。” 接下来在真正发布任何功能之前，他们还需要进行另外一个评审。因此你可以发现这种监督形式可以推动团队进行瀑布模型的执行。在这种情况下，您可能需要为高管进行一个盛大的演示，但不要让这些阻止你做你需要做的。事实上，如果你把原型和真实的用户反馈拿来让高管进行评审，你将获得一个留下好印象的机会。然后，你仍然可以进行增量构建、部署和测试。

所以，如果有人要求你大范围发布项目，尽一切可能来避免它，并告诉他为数众多并进行增量式设计、构建、测试和发布的项目的命运。

 

 

PS:这篇文章的标题是"Big Bang Releases" ,我不知道翻译成“大范围发布”是否合适，纠结了很久。也恳请各位提提意见，一经采纳，马上修改，:)