項(xiàng)目管理的四大模型，項(xiàng)目經(jīng)理必知
怎么判斷一個人對一件事是否了解透徹?其實(shí)就是“知其然”且“知其所以然”。項(xiàng)目管理這個崗位的人也是一樣，但因國內(nèi)企業(yè)自身培訓(xùn)較少，很多項(xiàng)目經(jīng)理都是沒有基礎(chǔ)知識的情況下直接上崗，所以，可能會比較欠缺這塊的知識。
而時代的迅速發(fā)展又奠定了管理模式會在原有的基礎(chǔ)上更加優(yōu)化和迭代，所以，作為項(xiàng)目經(jīng)理，一定要清楚的知道這幾種基本的項(xiàng)目管理模型，才能舉一反三的靈活運(yùn)用它，今天我們就來一起學(xué)習(xí)一下這四種項(xiàng)目管理模型。
01
瀑布模型 —— 按照流程一次性交付
瀑布模型是應(yīng)用最廣泛，且最早出現(xiàn)的系統(tǒng)的項(xiàng)目管理模型，后續(xù)的模型很多都是在此基礎(chǔ)上演變而成的，所以要想透徹的了解各個模型的應(yīng)用，知道瀑布模型是根本。
▍瀑布模型的六個階段
1)軟件計劃
通過市場調(diào)研以及和需求方的溝通，確定項(xiàng)目目標(biāo)，進(jìn)行可行性研究，以確定項(xiàng)目是否可行，利益幾何，用于判斷企業(yè)是否接受該項(xiàng)目。
2)需求分析
深挖需求方的所有需求，進(jìn)行分析，以確定需求方最終想要達(dá)到的效果，進(jìn)而保證做出客戶想要的產(chǎn)品。一般這個步驟需要和客戶反復(fù)確認(rèn)，最終形成需求文檔，作為開發(fā)的依據(jù)。
3)軟件設(shè)計
了解了需求，這一步就要把需求系統(tǒng)化，根據(jù)需求的內(nèi)容思考怎么呈現(xiàn)的實(shí)現(xiàn)，比如設(shè)計系統(tǒng)構(gòu)架，設(shè)計系統(tǒng)界面、設(shè)計數(shù)據(jù)庫、設(shè)計開發(fā)接口等，最終會形成架構(gòu)設(shè)計文檔。
4)程序編碼
系統(tǒng)框架已經(jīng)清晰，接下來就是和程序員溝通，把設(shè)計結(jié)果通過程序代碼變成用戶可使用的操作平臺。
5)軟件測試
編碼完成且在其相應(yīng)的平臺上也可操作，這個時候就需要測試人員站在用戶的角度，按照需求文檔進(jìn)行詳細(xì)的測試，對于不合理或者不正常運(yùn)營的部分提出疑問，然后程序人員修復(fù)，所有疑問解決，形成測試報告。
6)運(yùn)行維護(hù)
軟件開發(fā)完成，即可投入使用。但不可保證用戶使用中是否會出現(xiàn)問題，所以項(xiàng)目團(tuán)隊可能需要繼續(xù)維護(hù)，修復(fù)錯誤和增加功能。
▍舉個例子
比如，客戶要制造出一個小汽車。
首先，客戶提出想法，想要一個舒服的擋風(fēng)遮雨的代步工具(初步需求)。
客戶一開始可能并不清楚想要什么樣子(對需求沒有那么清晰)。
項(xiàng)目經(jīng)理開始找客戶確認(rèn)：用途是什么，想要幾個座位，想要什么風(fēng)格，什么時間完工，預(yù)算多少等等(需求確認(rèn))。
項(xiàng)目經(jīng)理根據(jù)客戶需求做商業(yè)分析，市場調(diào)研，項(xiàng)目成本思考，對比工期和預(yù)算，評估是否可做，是否值得做(可行性研究)。
評估確定可行，約定價錢和時間，簽訂合同(細(xì)想，制定項(xiàng)目計劃)。
項(xiàng)目經(jīng)理和客戶確認(rèn)需求，例如幾個座位，是否有智能設(shè)備等等(需求分析)。
設(shè)計出原型圖和客戶確認(rèn)，設(shè)計需要什么組成部分，例如輪胎怎么做，方向盤怎么做等(軟件設(shè)計)。
開始正式制作零件和組裝(程序編碼)。
這個時候客戶來看，只能看到零件，比如方向盤、輪胎等(中間客戶看不到結(jié)果，只有最后能看到結(jié)果)。
做到這客戶可能說，空間太小了，四個座不夠要六個座。這意味著設(shè)計圖要重新調(diào)整，做好的車殼需要加長等(瀑布模型不能做到隨時響應(yīng)變更，越到后期代價越大)。
零件制作好，且組裝完成，測試人員進(jìn)行測試，是否滿足質(zhì)量要求，是否需要修改(測試)。
最后通過驗(yàn)收，客戶開走車子。
▍優(yōu)缺點(diǎn)
優(yōu)點(diǎn)：
計劃性較強(qiáng)，每個階段都有其明確的任務(wù)，讓軟件開發(fā)過程可控。
很好的分工協(xié)作，產(chǎn)品經(jīng)理、項(xiàng)目經(jīng)理、開發(fā)、測試等都有其相應(yīng)的工作。
質(zhì)量有保證，每個階段都有相應(yīng)的文檔留存和評審，可以幫助在動手之前思考的更清晰。編碼結(jié)束后也會有按照需求文檔嚴(yán)密的測試，讓質(zhì)量更有保障。
缺點(diǎn)：
難以靈活的響應(yīng)需求變更，對于最初不清楚需求的客戶不友好。
工作量分布不均勻，項(xiàng)目安排是階段性的，很多工作人員不能同時做事，可能會導(dǎo)致人力的浪費(fèi)，比如導(dǎo)致程序員開發(fā)時，測試人員需要等著結(jié)果。
進(jìn)度控制難度加大，若前期進(jìn)度受阻，就不得不壓縮后續(xù)各階段時間。
不能及時給客戶反饋，到最后才能看到結(jié)果。
▍適用范圍
用戶對需求非常清晰，且在開發(fā)過程中沒有或很少變化;或者市場上已經(jīng)有穩(wěn)定的開發(fā)流程，項(xiàng)目進(jìn)行過程中很少有變化。
用戶對實(shí)時看到效果沒有要求。
02
增量模型 —— 按模塊分批次交付
瀑布開發(fā)模型是一個一次性交付的過程，也就是說這一個項(xiàng)目通過了這六個“軟件計劃→需求分析→軟件設(shè)計→程序編碼→軟件測試→運(yùn)行維護(hù)”開發(fā)步驟，整個的項(xiàng)目就算完成了。
但是增量模型是一個分模塊交付的過程，它是把“需求分析→軟件設(shè)計→程序編碼→軟件測試”這四個步驟摘出來，運(yùn)行了多次，然后完成的整個項(xiàng)目。
如果還拿上面的小汽車作為例子的話，就是先制作輪胎、然后制作方向盤，再后面是汽車殼等。而且制作輪胎時也要通過需求分析→軟件設(shè)計→程序編碼→軟件測試”這四個步驟，且如果模塊沒有依賴關(guān)系的情況下，還可以并行開發(fā)。
▍優(yōu)缺點(diǎn)
優(yōu)點(diǎn)：
系統(tǒng)模塊化，可以分批次的交付產(chǎn)品，用戶可以及時得到反饋，了解項(xiàng)目的進(jìn)展。
分批次開發(fā)降低了開發(fā)的風(fēng)向，一個開發(fā)周期的問題不會影響整體開發(fā)進(jìn)度。
開發(fā)順序靈活，可以根據(jù)組件優(yōu)先級，成員的時間進(jìn)度進(jìn)行優(yōu)先級排序。
很好的分工協(xié)作，產(chǎn)品經(jīng)理、項(xiàng)目經(jīng)理、開發(fā)、測試等都有其相應(yīng)的工作。
質(zhì)量有保證，每個階段都有相應(yīng)的文檔留存和評審，可以幫助在動手之前思考的更清晰。編碼結(jié)束后也會有按照需求文檔嚴(yán)密的測試，讓質(zhì)量更有保障。
缺點(diǎn)：
難以靈活的響應(yīng)需求變更，對于最初不清楚需求的客戶不友好。
要求待開發(fā)的項(xiàng)目可以進(jìn)行系統(tǒng)化模考劃分。
模塊并行進(jìn)行，很可能導(dǎo)致成員工作的并行進(jìn)行，例如，在做某一模塊內(nèi)容的同時，需要更改另一模塊的bug內(nèi)容。
▍適用范圍
因?yàn)樵隽磕Ｐ偷幕A(chǔ)是模塊化，所以這種項(xiàng)目管理方式更適合于：需求清晰且能模塊化的項(xiàng)目。
03
迭代模型 —— 按時間分批次交付
由于市場的快速變化，導(dǎo)致現(xiàn)在很多項(xiàng)目客戶自身也不知道需求是什么，所以為了應(yīng)對這種情況，出現(xiàn)了迭代開發(fā)模型，每次只設(shè)計和實(shí)現(xiàn)產(chǎn)品的一部分，然后逐步完成更多的功能。
每次設(shè)計和實(shí)現(xiàn)一個階段叫做一個迭代，整個過程就像一個完整的項(xiàng)目一樣，包含軟件計劃、需求分析、設(shè)計、實(shí)現(xiàn)與測試驗(yàn)收等過程，就相當(dāng)于進(jìn)行了一次小瀑布，迭代結(jié)束時都要完成一個可以運(yùn)行的交付版本。
我們繼續(xù)拿小汽車舉例：在最初客戶提出需求是需要一個代步工具，開發(fā)團(tuán)隊需求不是很清晰的情況下，做了一個滑板車，用戶看過之后覺得不對，我需要它速度再快點(diǎn)，而且再舒服一點(diǎn)。
那么第二個版本可能就做了一個電動車讓客戶使用，客戶使用了之后呢?還是覺得不滿意，這個不能遮風(fēng)擋雨呀，這個時候團(tuán)隊成員就為這輛車加了棚子，是一個帶棚子的電動車，再次提交給客戶。
然后，用戶再提出需求，再次迭代......就這樣一直提出需求，一直迭代完成需求變更解決問題。
注意：在迭代模型中，整個項(xiàng)目會被拆分成一系列的小迭代。通常一個迭代的時間都是固定的，不會太長，例如 2-4 周。每次迭代只實(shí)現(xiàn)一部分功能，做能在這個周期內(nèi)完成的功能。
▍增量模型與迭代模型的區(qū)分
增量模型是按照功能模塊來拆分;而迭代模型則是按照時間來拆分，看單位時間內(nèi)能完成多少功能。
還是用制造汽車來理解，增量模型則是先做輪胎，再做方向盤，這樣一個個模塊來完成。
而迭代模型則是先做一個滑板，主要功能代步滿足，然后再升級成電車，代步還有速度，這樣一步步迭代成最終的小汽車。
▍優(yōu)缺點(diǎn)
優(yōu)點(diǎn)：
靈活的響應(yīng)需求變更，做最符合客戶需求的產(chǎn)品。
快速交付產(chǎn)品，降低了產(chǎn)品無法按照既定進(jìn)度進(jìn)入市場的風(fēng)險。
有頻率且短時間內(nèi)持續(xù)有產(chǎn)品交付，用戶可以及時得到積極的反饋。
團(tuán)隊成員并行工作，有利于節(jié)省時間和人力
缺點(diǎn)：
項(xiàng)目的整體時間不好預(yù)估，只能短時規(guī)劃項(xiàng)目進(jìn)度。
對項(xiàng)目經(jīng)理和團(tuán)隊成員的要求較高，需要快速應(yīng)對變化的能力，且一精多專。
▍適用范圍
某些部分來講，迭代模型就是應(yīng)對變化而生的，所以它更適用于需求不確定的高風(fēng)險項(xiàng)目。
04
快速原型模型 —— 低成本快速的確認(rèn)需求
由于種種原因，在需求分析階段得到完全一致、準(zhǔn)確、合理的需求說明是很困難的，所以為了解決這個問題，讓雙方的理解達(dá)成一致，出現(xiàn)了快速原型模型方法，也叫原型模型。
它是指得到需求后迅速建造一個可以運(yùn)行的軟件原型，給到用戶測試，搜集反饋，然后反復(fù)修改確認(rèn)，直至開發(fā)出的軟件能真正反映用戶的需求。
但在原型開發(fā)過程中，并沒有經(jīng)過嚴(yán)謹(jǐn)?shù)南到y(tǒng)設(shè)計和規(guī)劃，可靠性和性能都難以保障。所以在實(shí)際的軟件項(xiàng)目中，針對原型模型的這種快速、低質(zhì)量的特點(diǎn)，通常有兩種處理策略：拋棄策略和附加策略。
拋棄策略是指原型只應(yīng)用于需求分析階段，在確認(rèn)完需求后，原型將會拋棄，實(shí)際開發(fā)時，將重新開發(fā)所有功能。
附加策略則是將原型應(yīng)用于整個開發(fā)過程，原型一直在完善，不斷增加新功能新需求，直到滿足客戶所有需求，最終將原型變成交付客戶的軟件，這個策略和迭代模型優(yōu)點(diǎn)類似。
▍原型設(shè)計工具
因?yàn)樵椭谱饕罂焖伲圆⒉灰欢ㄐ枰駛鹘y(tǒng)代碼一樣都需要重新編碼，有很多原型工具支持快速生成原型，比如 Axure、墨刀等，簡單的拖拽就可以實(shí)現(xiàn)簡單的界面和交互，同樣可以達(dá)到確認(rèn)需求的目的。
▍優(yōu)缺點(diǎn)
優(yōu)點(diǎn)：
開發(fā)速度快，用戶意見實(shí)時反饋，對需求精準(zhǔn)的把控，可以減少設(shè)計中的錯誤和開發(fā)中的風(fēng)險，同時也減少了對用戶的培訓(xùn)難度，而提高了系統(tǒng)的實(shí)用型。
因?yàn)楹陀脩艚换シ奖�，有利于提高用戶的滿意度，所以有助于短時間內(nèi)產(chǎn)品的推廣。
缺點(diǎn)：
所選用的開發(fā)技術(shù)和工具不一定符合主流的發(fā)展。
快速建立起來的系統(tǒng)結(jié)構(gòu)加上連續(xù)的修改可能會導(dǎo)致產(chǎn)品質(zhì)量低下。
拋棄策略中的模型，可能會出現(xiàn)“模型可以但真實(shí)實(shí)現(xiàn)有困難”的情況，再和客戶溝通更改較難。
▍適用范圍
過程明確、涉及面窄的小型系統(tǒng);大型系統(tǒng)的需求階段，用于和客戶明確需求。
來源: 慧翔天地PMP
以上是關(guān)于項(xiàng)目管理的相關(guān)信息，以供大家查看了解。想要了解更多項(xiàng)目管理信息，第一時間了解項(xiàng)目管理相關(guān)資訊，敬請關(guān)注唯學(xué)網(wǎng)項(xiàng)目管理欄目，如有任何疑問也可在線留言，小編會為您在第一時間解答!
