瀑布模型和靈活模型是當下流行的兩種項目開發管理模式。總的來說，ToB的傳統型企業采用瀑布模型的居多，新興的以網際網路業務為主的ToC類企業采用靈活模型的居多，這是由兩者所開發産品的特點決定的。但是，随着傳統企業不斷和網際網路融合，以及市場使用者特點的不斷變化，對開發模式的選擇并不能單純的做到“一刀切”，非此即彼，而需要根據企業和項目本身的實際情況靈活選擇。
一、什麼是瀑布模型
瀑布模式是科技公司早期普遍采用的一種開發模型，是由 Winston W. Royce在1970年提出來的。瀑布模式是一種具有明确的需求、明确的計劃表、明确的資源投入和明确的預期結果的一種開發模式，是一種“強計劃型”項目管理模式。
瀑布模式具有如下典型特點：
1、将項目的開發過程嚴格的劃分成各個開發階段：需求分析、概念設計、總體設計、詳細設計、工程實作、單元測試、內建測試、系統驗證、釋出上線等。
2、每一個階段的完成時間稱為裡程碑節點，瀑布模型嚴格定義了各個裡程碑節點的入口和出口要求。每到一個裡程碑節點，必須組織項目相關部門進行嚴格的評審，如果達不到出口要求，下一階段的工作就不展開。
3、重視和強調過程資料，每個階段需要輸出的過程資料都有嚴格的規定，且有相應的模闆。
4、嚴格控制需求變更，一般來說，需求分析階段通過了之後，需求不再變更。如果需要變更，必須經過詳細的論證，并通過嚴格的審批才能變更。
5.瀑布模型把每個開發階段的輸入以及每個領域的分工都定義得非常明确，每個階段的人員隻要關心自己階段的工作，按照階段輸入輸出要求完成自己的工作。
圖檔來自網際網路
瀑布模型的優點：
1、需求閉環，計劃明确，能夠更好的控制産品的開發周期和成本，更容易讓投資人感到項目可控。
2、嚴格控制各階段的輸入和輸出，通過把握每個階段的過程品質，最終保證整個産品的釋出品質。
3、整個過程可追溯，所有過程資料及其變更情況非常完整齊全，有利于開發團隊的技術傳承，可以做到人員流失的情況下，産品品質仍然精益求精。
瀑布模型的缺點：
1、需求固定，需求變更代價大，試錯成本高。
2、過程資料多，開發人員抵觸較大。
3、開發過程流水線化，開發人員如同流水線勞工，創造性思想被抑制。
二、什麼是靈活模型
靈活模型是1990年代随着網際網路興起逐漸引起廣泛關注的一種新型軟體開發模式，注意這裡說的是軟體，靈活模型目前大多用于軟體開發。
靈活開發是一種以使用者需求進化為核心、疊代和循序漸進的開發方法。首先把使用者最關注的軟體原型做出來并傳遞給使用者，使用者在實際場景中發現問題并給予回報，研發人員快速修改彌補需求中的不足，提供新的版本給使用者繼續使用。上述過程不斷疊代，直到使用者滿意。
靈活模型的特點：
1、強調與客戶的互動和溝通過程，需求不斷變化。
2、根據變化的需求形成一個個story，不斷疊代開發版本。
3、開發過程中，始終保證客戶有可用的版本。
4、更重視疊代版本的快速釋出，減少輸出不必要的文檔。
圖檔來自網際網路
靈活模型的優點：
1、始終保持客戶需求的響應，對客戶提出的回報意見快速修改并提出版本。
2、根據客戶的需求快速提供原型和版本，始終保證客戶有版本可用。
3、靈活模型是開發人員更喜歡的一種模式，開發過程短平快，更容易出成果，且過程文檔少。
靈活模型的缺點：
1、需求不固定，産品開發過程不可控，開發成果無法預期。
2、由于缺乏完備的過程資料和必要的限制，開發成果的繼承性差，核心人員流失将導緻後續版本的開發困難。
3、由于需求變化比較随意，版本疊代更像是一個試錯過程，版本返工的幾率比較高。
三、開發模式的選擇
看了上述對瀑布模型和靈活模型的特點及其優缺點的總結，相信我們對如何選擇這兩種開發模式應該心裡有數了。瀑布模型更适合于需求穩定且開發周期較長的項目，靈活模型更适合于需求不固定且需要快速搶占市場的項目。
适合瀑布模型開發模式的産品有：
1、硬體類産品，包括元器件産品、晶片産品、闆卡産品、整機産品等，硬體産品一般都有明确的版本規劃，需求固定且開發成果可預測。硬體類産品一般也不允許随意變更需求。這些産品大部分是面向企業使用者的，也有面向個人使用者的，比如掃地機器人、智能音箱等。
2、大型通用軟體産品，如系統軟體、辦公類軟體、工具類軟體、平台類軟體等，這類軟體産品一般都是一代代推出，每一代産品都有很強的規劃性。這些軟體有面向企業的，也有面向個人的，但總體上都是工作中用到的，很少有生活中用到的。
3、招投标中标的一些業務軟體，一般在标書中已經明确軟體的需求範圍和開發周期。這些軟體大部分都是企業使用者。
适合靈活模型開發的産品有：
1、面向個人使用者的一些app軟體，例如移動端app、小程式等，也包括一些網際網路生活和娛樂平台類軟體。
2、面向企業使用者定制開發的業務系統軟體，需求粒度比較粗，開發成果需要和客戶不斷的溝通和修改。
3、需要快速提供給客戶版本，搶占市場的軟體。
四、瀑布模型和靈活模型的融合
既然我們知道了瀑布模型和靈活模型的特點及如何選擇，那是不是就很容易确定項目選擇何種開發模式了呢？實際上沒有那麼簡單，任何問題都需要結合曆史情況和具體實際來分析。而且，對一個企業來說，開發模式的轉變，意味着整個産品研發管理體系的變革，是需要深思熟慮的。
有的企業，一直是采用瀑布模式的，現在情況變化了，很多項目的需求沒法确定，客戶的需求總是變，看起來似乎應該變成靈活模式比較好。但是，之前的經驗證明，公司采用瀑布模式是非常成功的，現在因為個别原因，就變成靈活模式，風險實在太大。大家想想瀑布模式和靈活模式的優缺點就知道了，瀑布模式也是有其很多優點的，尤其投資人和企業管理者喜歡瀑布模式。
還有的企業，産品可能比較适合靈活模式，但是行業管理要求不允許。有些行業有必須的資質要求，而要滿足這些資質要求的産品研發管理體系，非瀑布模式不可。
這些情況，就需要我們具體問題具體分析了，面對這種情況，不妨考慮采用“瀑布+靈活”的融合模型。
華為的IPD（內建産品開發）流程大家都知道，名氣很大，花了十多年的時間從IBM學來的，事實也證明華為的IPD是成功的，為華為的崛起立下了汗馬功勞。是以，很多科技型企業的産品研發模式都學習和效仿IPD流程。管理咨詢行業，也有很多人專門講IPD流程。而IPD就是一個典型的瀑布模型，但IPD又不僅僅是瀑布模型。很多效仿IPD流程的企業，就是因為沒有正确了解IPD的核心思想，是以往往将IPD搞得不倫不類。IPD的核心思想，是将産品當做一項投資來管理。這句話要展開說的話，内容太多。網絡上關于IPD的介紹很多，本文不再贅述。在華為的IPD變革曆程中，IPD始終是站在組織戰略的高度來把握方向，確定組織是在做正确的事。核心的過程包括産品包需求管理、立項論證、跨多個部門的協作團隊、嚴格的技術評審等等。
這裡舉IPD的例子，是想告訴大家，IPD作為最經典的瀑布開發模型，也是與時俱進的。基于IPD的産品論證和開發過程是非常長的，而且在整個過程中，需求不能變。華為在IPD運作了十幾年後，發現這種模式越來越難以滿足實際的要求。客戶希望産品快速上市，客戶的需求也總是變化，産品試錯成本太高等等。
2009年，華為正式在全公司範圍推廣靈活方法和相關實踐，并逐漸将其融入到IPD流程中。在靈活推廣過程中，華為制定了“項目級—>版本級—>産品級”靈活三步走政策，并将靈活理念和實踐完全融入IPD 流程中。
所謂項目級靈活，主要是以IPD流程下大版本的某個項目組為機關，在項目的某個階段或某些階段實施靈活開發，聚焦單個項目的快速疊代。
所謂版本級靈活，主要是以版本為機關，按照IPD流程立項的産品包需求向最終客戶分批傳遞産品版本，加快對使用者和市場的響應速度。
所謂産品級靈活，在立項階段就拆分産品包需求，按照更小的産品包需求立項并向最終客戶分批傳遞産品，整個流程完全遵循IPD流程，但是産品包需求更小了，以此達到快速推出産品的目的。
圖檔來自網際網路
是以，華為IPD的這種改革，就是瀑布模型和靈活模型融合的典型案例。但這種三個級别的融合更适合規模比較大的企業，對于中小型公司來說，如果必須要采用瀑布模型，又要面向客戶需求的不斷變化，不妨采用“瀑布+項目級靈活”的模式為主，同時盡量吸收版本級靈活和産品級靈活的精髓，将産品包或者版本需求規劃得粒度更細一點，更精準一點，以便于快速推出産品版本。
版權所有，未經允許，禁止轉載。
————————————
撰稿人：張星河
二十餘年科技行業産品與研發管理實踐、職業經理人、科技公司創始人
記錄和分享真實的管理實踐經驗
![Android Data Binding 技術[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)