啟示錄：打造用戶喜愛的產品之大爆炸式發布

　　Marty Cagan 發表於 2010年2月9日

　　譯者：唐豐能 / 審校：潘希穎 林航 徐定翔

　　什麼是“大爆炸”式發布?

　　這是指一個項目團隊經過數月的努力，構思讓自己的作品在一個大型新產品發布活動中一炮打響。

　　大爆炸式發布不等於瀑布式開發(有關瀑布式開發的來歷，請參考《啟示錄：打造用戶喜愛的產品》第27章)，但它是瀑布式開發中常見的最終環節。不止在瀑布式開發中會采用大爆炸發布，Scrum團隊實際上也被迫采用大爆炸發布。

　　為什麼大爆炸式發布會產生問題?

　　因為它幾乎從來都不順利。通常時間緊、任務重，要發布的版本內容總是越變越多(管理層都是急性子，只要他們想得到，總是希望加入更多的功能)。過不多久，問題就來了，你要麼大修大改，要麼痛苦地在功能上做裁減。

　　此外，采用大爆炸式發布的產品，幾乎沒有什麼時間可以讓你根據上線後的實際數據對功能進行調整。很多時候，結果和預期有出入，可此時已無力回天。

　　此外，一次性地做出過多的修改，網站的穩定性會受到嚴峻考驗，因為只有在上線之後你才能發現這些問題並嘗試解決它們。即使不存在穩定性方面的問題，用戶也會因網站一次性改動太大而心生反感。

　　既然有那麼多問題存在，為什麼還會選擇進行大爆炸式發布呢?

　　可能有以下幾個原因。

　　有時是因為營銷部門想舉辦一場大型的發布活動以達到震撼效果，他們覺得在活動准備好之前，產品不應該被曝光。還好我們不必像以前那樣經常做大型發布活動。即使舉辦了這樣的活動，也要明白大爆炸式營銷不等於大爆炸式產品發布。你可以采取循序漸進的方式開發產品，一點一點地發布新功能，最好讓用戶幾乎察覺不出什麼變化。

　　有時是因為主管定下的項目完成時間太具挑戰性，要按時完成任務，產品團隊不得不減少測試和發布的時間，以保證有足夠的時間用於產品開發。我知道這樣做也是逼不得已，但是產品不應該用這種方式開發。如果真的要按時發布，最好的方式就是采取增量式開發和部署。讓產品按時上線不一定要采用大爆炸式發布模式。

　　有些公司，特別是大公司，堅持進行項目審查和過程監督，從而“成功”地將團隊引向瀑布式開發，最後不得不選擇大爆炸式發布。例如，他們會說：“你可以繼續研究這一想法，但真正動手前，必須要通過評審。”於是發布任何功能之前，他們都要進行一次評審。這樣一來，不想把團隊引向瀑布式開發都難。也許你不得不給你的上司來場“匯報演出”，但你要做的事情還很多，別為了這點小阻礙就垂頭喪氣。事實上，你要是把原型和真實的用戶反饋拿來讓上司進行評審，沒准還能給他們留下一個好印象。評審一結束，就趕快繼續你的增量式構建、部署和測試吧。

　　所以，如果有人要求你采取大爆炸式發布，盡可能通過增量式設計、構建、測試及發布的方式來替代它。

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

　　本文節選自《啟示錄：打造用戶喜愛的產品》一書作者的博客。該書從人員、流程、產品三個角度介紹了現代軟件(互聯網)產品管理的實踐經驗和理念。特此感謝Marty Cagan先生授權。

　　文章來源：七印部落 轉載請注明出處鏈接。