軟體專案管理的兩大主流管理模式分別是傳統專案管理和敏捷專案管理。

傳統專案管理通常採用的是瀑布式、部分迭代開發模式，要求在專案建設時，需求足夠明確、文件足夠規範，迭代過程中需求變更越多、越晚，對專案影響越大，會影響到專案的交付質量。

敏捷專案管理作為新興的專案管理模式，簡化了傳統專案管理的繁瑣流程和文件。以 Scrum 為代表，歡迎需求變更，在客戶需求不明確的時候，以在較短的週期內開發出可用的軟體為目標，來幫助客戶描述自己的需求。迭代過程中的需求變更會加入到專案繼續迭代需求池，豐富專案的產品功能。

一、管理流程

完整的專案管理流程可以總結分為五個過程組：啟動、規劃、執行、監控、收尾

1、傳統專案管理

傳統的專案管理要對專案的所有過程進行管理和風險把控，並要求在不同環節的有文件輸入和輸出。比如，PMBOK 第五版對專案整合管理的過程組做了文件輸入和輸出的整理，如下圖。

但是，專案管理主要是對範圍、進度、成本、質量、人力資源、溝通、風險、採購和干係人進行管理，每個環節都存在啟動、規劃、執行、監控和收尾過程。

如果採用傳統的專案管理模式，每個環節都必須要進行嚴格的規劃，一旦出現規劃以外的變更，都需要經過批准後才能執行改變。

2、敏捷專案管理

敏捷專案管理簡化了繁瑣的流程和文件管理，主張團隊內部的面對面溝通和交流。以 Scrum 為代表，簡單、持續整合、不斷交付、價值優先、擁抱變化的原則在面對時刻變化的市場經濟和不斷髮展的技術時變得十分友好。敏捷專案中，專案管理計劃分不同的等級，可以用一個洋蔥圖來表示，也就是洋蔥計劃圖，如下圖。

戰略和投資規劃在敏捷專案管理的最外層，由更廣泛的組織管理系統來處理。由外往內，不斷切分專案計劃，最後實現最小週期的可行性版本迭代。對複雜或不明確的客戶需求進行合理的分割，最終實現總體上的統一。

二、風險控制環節

專案風險在任何專案中都存在不確定性，一旦發生，會對專案造成積極或消極的影響，如範圍、進度、成本和質量。

1、傳統專案管理：

傳統專案管理要求專案在規劃過程中規劃風險管理、識別風險，並且對風險進行定性/定量分析，給出風險應對方案。雖然已知的風險可以在被識別和分析後採取應對措施，但正是因為風險的不確定性，要求專案風險管理必須給未知風險或者已知卻又無法主動管理的風險分配一定的資源儲備。

所以，傳統專案管理會要求提供風險登記表，並且記錄風險應對措施在處理已識別風險及其根源方面的有效性，完成風險再評估和風險審計，直到風險被降到最低。

2、敏捷專案管理：

敏捷專案管理不同於傳統專案管理，開發評估是以工作量為導向而非時間導向。所以，在進行開發任務評估時採用的是相對估算而不是絕對估算，為風險留足了應對空間。同時，Scrum集合了一線人員的參與，經驗分享，集思廣益，將小型團隊轉化成獨立的管理者，更有利於問題的解決。

敏捷專案管理在專案沒有正式結束前，交付的可用軟體是允許風險存在的，並且是根據風險的優先順序來進行排期修復。

三、第三方業務風險控制服務企業專案管理分析

1、專案管理模式：外瀑布內敏捷（有人稱為“信封法”）

第三方業務風險控制服務行業目前還沒有發展出固定的行業標杆，大家都在競爭中追求最大範圍的滿足行業需求。在這樣的背景前提下，大部分專案都沒有明確和長久穩定的需求，Scrum 管理模式很好的滿足了這個行業的專案管理現狀。

但是，作為行業客戶，在大部分的商務場景下客戶都會希望透過固定成本合同來實現自己的利益最大化，問題是現在合同雙方都很難在專案開始時明確約定需求和最終實現方式。所以，在客戶不能接受 Scrum 時，通常會選擇外瀑布內敏捷的專案管理模式，滿足雙方的利益。

2、舉例：

如果把拍婚紗照作為一個專案，攝影師和新人作為專案主要成員，專案基本流程滿足：

選婚紗照的套餐（固定成本，確定基本需求）

拍攝（專案啟動）

挑照片（提交測試，開始驗收）

根據底片修圖（修復）

拿到照片（專案結束）

>>>>以上就是順序執行，瀑布式的結果。

然而，拍攝的過程中新人通常都會要求：

較短短時間內提出新增造型、內景換外景的要求（切換pose的任務）

配合攝影師完成拍攝環節的工作（透過迭代，完成專案）

>>>>以上就是內部快速迭代，敏捷式的結果。

很顯然，新人在拍婚紗照之前並不知道自己最終拿到的照片穿的會是哪套衣服，擺的會是哪個pose；但是，很清楚的是哪天拍照、哪天挑照片、哪天可以拿到照片，這套流程同時滿足了內部和外部需求。

只是，為了專案順利結束，可能在內部和外部需求時，並沒有要求完全以相同的速度前進，就像你不能以你配合完成攝影的速度去要求攝影樓馬上提供婚紗照。

四、第三方業務風險控制服務企業產品服務流程

其實，作為第三方風控服務的企業，專案服務流程基本上和拍婚紗照一樣：

五、傳統 VS 敏捷 ？ 適者生存

敏捷專案管理只是一個靈活的實踐框架，提供的是一套清晰遊戲規則，根據不同的環境可以提供一系列不同的途徑。

傳統專案管理卻是一套中央集權制管理法，要求按計劃行事，任何環節發生變更都必須獲准後才能進行改變。

我們知道的是，第三方業務風險控制服務行業目前還沒有發展出固定的行業標杆，沒有一套可稱為標準的、行之有效的流程打通各個環節。更重要的問題——合同雙方都很難在專案開始時明確約定需求和最終實現方式。

在市場經濟不斷髮展、時刻變化的現代網際網路環境下，適應變化、擁抱變化的第三方業務風控服務企業的專案管理，才是友好的、可行的管理模式。

六、閱讀參考

一個很有趣的“敏捷和瀑布”對比例子，給大家作為閱讀參考：

1、敏捷開發

客人到餐館來點菜（新專案）

不確定客戶想吃什麼的時候，通常選好餐廳後會先看看餐廳的選單（客戶往往提不出具體的需求）

根據圖文選單，客人點了是個菜（根據原型和設計稿，基本確定了需求）

後廚開始準備（專案啟動）

配菜、炒菜，先上了兩盤，讓客人嚐了嚐味道（先提供可用例項給客戶用）

客人說還不錯，後廚繼續準備後面的菜，陸續上菜（不斷迭代，不斷測試）

上菜過程中，客人突然發現有個菜的味道太淡了，讓後廚加了點鹽又端上來了（敏捷的好處，可以不斷測試和需求變更）

又上了兩盤，不夠辣，又拿到後廚加了辣（敏捷的壞處，需求沒有提前明確，反覆迭代，增加了工作量）

到最後兩盤時，客人要求換兩個菜，還好沒炒（迭代的好處，隨時接受需求變更）

客人吃完，很滿意（基本滿足了全部的要求）

2、瀑布模型開發

客人到餐館來點菜（新專案）

不確定客戶想吃什麼的時候，通常選好餐廳後會先看看餐廳的選單（客戶往往提不出具體的需求）

根據圖文選單，客人點了十個菜（根據原型和設計稿，基本確定了需求）

後廚開始準備（專案啟動）

根據客人的下單配菜，炒菜（基本上不會主動去了解完整需求）

半個小時了，菜還沒上桌，客人餓極了（專案啟動後很長一段時間客戶什麼都看不到）

再過了二十分鐘，十個菜都一起上來了（專案最終一次交付）

客人說，有幾個菜挺好的，但是有個菜味道淡了，有兩個不夠辣，還有兩盤重複了想換掉（我是買單的，我要變需求）

這時候大堂經理來了，說，“味道淡了可以加鹽，不辣可以加辣，但是換菜不行，已經炒好的那兩盤菜也是要算成本的”（瀑布的壞處，需求變更比較麻煩）

於是，後廚只給客戶加了鹽，加了辣

客人吃完，不是很滿意，下次不來了（沒有滿足需求）

敏捷專案管理，簡稱APM，是近幾年來流行的一種專案管理方法。跟傳統的專案管理相比，它簡化了繁瑣流程和文件，框架靈活。針對敏捷專案，個人有成功開發交付完成的實踐經驗，當時用的低程式碼開發平臺，在這個領域上，天翎的MyApps是個不錯的選擇。簡單拖拉拽的方式，視覺化報表，交付週期短。

如今，專案管理的步伐越來越快。專案管理需要更靈活、更積極地，響應客戶的需求。

敏捷開發則是以使用者的需求進化為核心，採用迭代、循序漸進的方法進行軟體開發的一種方法。

敏捷的優勢日益顯現，目的是為了迅速響應市場與使用者的需求。由於開發週期短，對需求管理恰當，敏捷專案管理正在從軟體研發行業延伸到已經採取專案化的大部分行業中。

敏捷管理開發流程一般有“待開發”“開發中”“待測試”“返工”“待發布”幾個區塊，所有任務由任務操作者負責流轉至於下一個步驟，這樣任何一個人專案成員都能看到任務的完成情況。

敏捷專案經理應考慮的措施

目標透明視覺化科學的組織架構上下級共同參與流程跟蹤，流程簡化組織文化和績效管理相契合

Scrum的應用

1、任務管理

需求分配

需求是在迭代中實現的。在哪個迭代中分配哪些需求，一般是按照客戶設定的優先度，從高到低地實施。

需求分解成可執行任務

敏捷軟體開發中，將開發工作細分為任務，每個人自發地選擇任務，一項任務完成後，自己再給自己分配下一項任務。把工作分解到可以分配給個人的程度，叫任務。

2、快速響應

當發生變更的時候我們需要做的是對變更做出快速的響應，這一點跟傳統的瀑布模型是有本質上的區別。

3、跟蹤進度

任務執行過程，團隊就會開始使用高度可見任務看板跟蹤任務的進度情況。

團隊使用任務板跟蹤每個功能的任務進度，待辦任務生成任務流程圖，團隊任務展示透明。

契合團隊OKR管理，支援多工建立，分解成父子級任務，幫助每個人更直觀看到各種內容和進展情況，資料全流程沉澱，方便後續查詢和覆盤處理。

敏捷專案管理的核心是敏捷二字，敏捷聽起來是一個挺高大上的一個詞，解讀之下不過是我們通常說的高效率 ，對於大多數企業來說，效率是發展過程中需要面臨的一大難關，而攸信所提出的AEES敏捷執行解決方案，以數字310位為方案的第一要義，即3秒找到10個結果，符合當下企業轉型所需要的敏捷特質，內外協同的同時，也為組織發展增值提效。