怎麼判斷一個人對一件事是否了解透徹？其實就是“知其然”且“知其是以然”。項目管理這個崗位的人也是一樣，但因國内企業自身教育訓練較少，很多項目經理都是沒有基礎知識的情況下直接上崗，是以，可能會比較欠缺這塊的知識。
而時代的迅速發展又奠定了管理模式會在原有的基礎上更加優化和疊代，是以，作為項目經理，一定要清楚的知道這幾種基本的項目管理模型，才能舉一反三的靈活運用它，今天我們就來一起學習一下這四種項目管理模型。
01
瀑布模型 —— 按照流程一次性傳遞
瀑布模型是應用最廣泛，且最早出現的系統的項目管理模型，後續的模型很多都是在此基礎上演變而成的，是以要想透徹的了解各個模型的應用，知道瀑布模型是根本。
▍瀑布模型的六個階段
1）軟體計劃
通過市場調研以及和需求方的溝通，确定項目目标，進行可行性研究，以确定項目是否可行，利益幾何，用于判斷企業是否接受該項目。
2）需求分析
深挖需求方的所有需求，進行分析，以确定需求方最終想要達到的效果，進而保證做出客戶想要的産品。一般這個步驟需要和客戶反複确認，最終形成需求文檔，作為開發的依據。
3）軟體設計
了解了需求，這一步就要把需求系統化，根據需求的内容思考怎麼呈現的實作，比如設計系統構架，設計系統界面、設計資料庫、設計開發接口等，最終會形成架構設計文檔。
4）程式編碼
系統架構已經清晰，接下來就是和程式員溝通，把設計結果通過程式代碼變成使用者可使用的操作平台。
5）軟體測試
編碼完成且在其相應的平台上也可操作，這個時候就需要測試人員站在使用者的角度，按照需求文檔進行詳細的測試，對于不合理或者不正常營運的部分提出疑問，然後程式人員修複，所有疑問解決，形成測試報告。
6）運作維護
軟體開發完成，即可投入使用。但不可保證使用者使用中是否會出現問題，是以項目團隊可能需要繼續維護，修複錯誤和增加功能。
▍舉個例子
比如，客戶要制造出一個小汽車。
- 首先，客戶提出想法，想要一個舒服的擋風遮雨的代步工具（初步需求）。
- 客戶一開始可能并不清楚想要什麼樣子（對需求沒有那麼清晰）。
- 項目經理開始找客戶确認：用途是什麼，想要幾個座位，想要什麼風格，什麼時間完工，預算多少等等（需求确認）。
- 項目經理根據客戶需求做商業分析，市場調研，項目成本思考，對比工期和預算，評估是否可做，是否值得做（可行性研究）。
- 評估确定可行，約定價錢和時間，簽訂合同（細想，制定項目計劃）。
- 項目經理和客戶确認需求，例如幾個座位，是否有智能裝置等等（需求分析）。
- 設計出原型圖和客戶确認，設計需要什麼組成部分，例如輪胎怎麼做，方向盤怎麼做等（軟體設計）。
- 開始正式制作零件群組裝（程式編碼）。
- 這個時候客戶來看，隻能看到零件，比如方向盤、輪胎等（中間客戶看不到結果，隻有最後能看到結果）。
- 做到這客戶可能說，空間太小了，四個座不夠要六個座。這意味着設計圖要重新調整，做好的車殼需要加長等（瀑布模型不能做到随時響應變更，越到後期代價越大）。
- 零件制作好，且組裝完成，測試人員進行測試，是否滿足品質要求，是否需要修改（測試）。
- 最後通過驗收，客戶開走車子。
▍優缺點
優點：
- 計劃性較強，每個階段都有其明确的任務，讓軟體開發過程可控。
- 很好的分工協作，産品經理、項目經理、開發、測試等都有其相應的工作。
- 品質有保證，每個階段都有相應的文檔留存和評審，可以幫助在動手之前思考的更清晰。編碼結束後也會有按照需求文檔嚴密的測試，讓品質更有保障。
缺點：
- 難以靈活的響應需求變更，對于最初不清楚需求的客戶不友好。
- 工作量分布不均勻，項目安排是階段性的，很多從業人員不能同時做事，可能會導緻人力的浪費，比如導緻程式員開發時，測試人員需要等着結果。
- 進度控制難度加大，若前期進度受阻，就不得不壓縮後續各階段時間。
- 不能及時給客戶回報，到最後才能看到結果。
▍适用範圍
- 使用者對需求非常清晰，且在開發過程中沒有或很少變化；或者市場上已經有穩定的開發流程，項目進行過程中很少有變化。
- 使用者對實時看到效果沒有要求。
02
增量模型 —— 按子產品分批次傳遞
瀑布開發模型是一個一次性傳遞的過程，也就是說這一個項目通過了這六個“軟體計劃→需求分析→軟體設計→程式編碼→軟體測試→運作維護”開發步驟，整個的項目就算完成了。
但是增量模型是一個分子產品傳遞的過程，它是把“需求分析→軟體設計→程式編碼→軟體測試”這四個步驟摘出來，運作了多次，然後完成的整個項目。
如果還拿上面的小汽車作為例子的話，就是先制作輪胎、然後制作方向盤，再後面是汽車殼等。而且制作輪胎時也要通過需求分析→軟體設計→程式編碼→軟體測試”這四個步驟，且如果子產品沒有依賴關系的情況下，還可以并行開發。
- 系統子產品化，可以分批次的傳遞産品，使用者可以及時得到回報，了解項目的進展。
- 分批次開發降低了開發的風向，一個開發周期的問題不會影響整體開發進度。
- 開發順序靈活，可以根據元件優先級，成員的時間進度進行優先級排序。
- 要求待開發的項目可以進行系統化模考劃分。
- 子產品并行進行，很可能導緻成員工作的并行進行，例如，在做某一子產品内容的同時，需要更改另一子產品的bug内容。
因為增量模型的基礎是子產品化，是以這種項目管理方式更适合于：需求清晰且能子產品化的項目。
03
疊代模型 —— 按時間分批次傳遞
由于市場的快速變化，導緻現在很多項目客戶自身也不知道需求是什麼，是以為了應對這種情況，出現了疊代開發模型，每次隻設計和實作産品的一部分，然後逐漸完成更多的功能。
每次設計和實作一個階段叫做一個疊代，整個過程就像一個完整的項目一樣，包含軟體計劃、需求分析、設計、實作與測試驗收等過程，就相當于進行了一次小瀑布，疊代結束時都要完成一個可以運作的傳遞版本。
我們繼續拿小汽車舉例：在最初客戶提出需求是需要一個代步工具，開發團隊需求不是很清晰的情況下，做了一個滑闆車，使用者看過之後覺得不對，我需要它速度再快點，而且再舒服一點。
那麼第二個版本可能就做了一個電動車讓客戶使用，客戶使用了之後呢？還是覺得不滿意，這個不能遮風擋雨呀，這個時候團隊成員就為這輛車加了棚子，是一個帶棚子的電動車，再次送出給客戶。
然後，使用者再提出需求，再次疊代......就這樣一直提出需求，一直疊代完成需求變更解決問題。
注意：在疊代模型中，整個項目會被拆分成一系列的小疊代。通常一個疊代的時間都是固定的，不會太長，例如 2-4 周。每次疊代隻實作一部分功能，做能在這個周期内完成的功能。
▍增量模型與疊代模型的區分
- 增量模型是按照功能子產品來拆分；而疊代模型則是按照時間來拆分，看機關時間内能完成多少功能。
- 還是用制造汽車來了解，增量模型則是先做輪胎，再做方向盤，這樣一個個子產品來完成。
- 而疊代模型則是先做一個滑闆，主要功能代步滿足，然後再更新成電車，代步還有速度，這樣一步步疊代成最終的小汽車。
- 靈活的響應需求變更，做最符合客戶需求的産品。
- 快速傳遞産品，降低了産品無法按照既定進度進入市場的風險。
- 有頻率且短時間内持續有産品傳遞，使用者可以及時得到積極的回報。
- 團隊成員并行工作，有利于節省時間和人力
- 項目的整體時間不好預估，隻能短時規劃項目進度。
- 對項目經理和團隊成員的要求較高，需要快速應對變化的能力，且一精多專。
某些部分來講，疊代模型就是應對變化而生的，是以它更适用于需求不确定的高風險項目。
04
快速原型模型 —— 低成本快速的确認需求
由于種種原因，在需求分析階段得到完全一緻、準确、合理的需求說明是很困難的，是以為了解決這個問題，讓雙方的了解達成一緻，出現了快速原型模型方法，也叫原型模型。
它是指得到需求後迅速建造一個可以運作的軟體原型，給到使用者測試，搜集回報，然後反複修改确認，直至開發出的軟體能真正反映使用者的需求。
但在原型開發過程中，并沒有經過嚴謹的系統設計和規劃，可靠性和性能都難以保障。是以在實際的軟體項目中，針對原型模型的這種快速、低品質的特點，通常有兩種處理政策：抛棄政策和附加政策。
抛棄政策是指原型隻應用于需求分析階段，在确認完需求後，原型将會抛棄，實際開發時，将重新開發所有功能。
附加政策則是将原型應用于整個開發過程，原型一直在完善，不斷增加新功能新需求，直到滿足客戶所有需求，最終将原型變成傳遞客戶的軟體，這個政策和疊代模型優點類似。
▍原型設計工具
因為原型制作要求快速，是以并不一定需要像傳統代碼一樣都需要重新編碼，有很多原型工具支援快速生成原型，比如 Axure、墨刀等，簡單的拖拽就可以實作簡單的界面和互動，同樣可以達到确認需求的目的。
- 開發速度快，使用者意見實時回報，對需求精準的把控，可以減少設計中的錯誤和開發中的風險，同時也減少了對使用者的教育訓練難度，而提高了系統的實用型。
- 因為和使用者互動友善，有利于提高使用者的滿意度，是以有助于短時間内産品的推廣。
- 所選用的開發技術和工具不一定符合主流的發展。
- 快速建立起來的系統結構加上連續的修改可能會導緻産品品質低下。
- 抛棄政策中的模型，可能會出現“模型可以但真實實作有困難”的情況，再和客戶溝通更改較難。
過程明确、涉及面窄的小型系統；大型系統的需求階段，用于和客戶明确需求。
好了，到此，内容就講完啦，如果對你有幫助，記得點贊分享 哦~
需要項目管理資料合集的同學可先關注然後私信我哦