傳統 vs 敏捷 ？第三方業務風控服務企業項目管理分析

軟件項目管理的兩大主流管理模式分別是傳統項目管理和敏捷項目管理。

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

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

管理流程

完整的項目管理流程能夠總結分爲五個過程組：

啓動、規劃、執行、監控、收尾

傳統項目管理

傳統的項目管理要對項目的全部過程進行管理和風險把控，並要求在不一樣環節的有文檔輸入和輸出。好比，PMBOK第五版對項目整合管理的過程組作了文檔輸入和輸出的整理，以下圖。

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

若是採用傳統的項目管理模式，每一個環節都必需要進行嚴格的規劃，一旦出現規劃之外的變動，都須要通過批准後才能執行改變。

敏捷項目管理

敏捷項目管理簡化了繁瑣的流程和文檔管理，主張團隊內部的面對面溝通和交流。以 Scrum爲表明，簡單、持續集成、不斷交付、價值優先、擁抱變化的原則在面對時刻變化的市場經濟和不斷髮展的技術時變得十分友好。

敏捷項目中，項目管理計劃分不一樣的等級，能夠用一個洋蔥圖來表示，也就是洋蔥計劃圖，以下圖。

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

風險控制環節

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

傳統項目管理：

傳統項目管理要求項目在規劃過程當中規劃風險管理、識別風險，而且對風險進行定性/定量分析，給出風險應對方案。雖然已知的風險能夠在被識別和分析後採起應對措施，但正是由於風險的不肯定性，要求項目風險管理必須給未知風險或者已知卻又沒法主動管理的風險分配必定的資源儲備。

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

敏捷項目管理：

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

敏捷項目管理在項目沒有正式結束前，交付的可用軟件是容許風險存在的，而且是根據風險的優先級來進行排期修復。

第三方業務風險控制服務企業項目管理分析

項目管理模式：外瀑布內敏捷（有人稱爲「信封法」）

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

可是，做爲行業客戶，在大部分的商務場景下客戶都會但願經過固定成本合同來實現本身的利益最大化，問題是如今合同雙方都很難在項目開始時明確約定需求和最終實現方式。因此，在客戶不能接受 Scrum時，一般會選擇外瀑布內敏捷的項目管理模式，知足雙方的利益。

舉例：

若是把拍婚紗照做爲一個項目，攝影師和新人做爲項目主要成員，項目基本流程知足：

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

• 拍攝（項目啓動）

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

• 根據底片修圖（修復）

• 拿到照片（項目結束）

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

然而，拍攝的過程當中新人一般都會要求：

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

• 配合攝影師完成拍攝環節的工做（經過迭代，完成項目）

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

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

只是，爲了項目順利結束，可能在內部和外部需求時，並無要求徹底以相同的速度前進，就像你不能以你配合完成攝影的速度去要求攝影樓立刻提供婚紗照。

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

其實，做爲第三方風控服務的企業，咱們的項目服務流程基本上和拍婚紗照同樣，更靈活的是在選擇套餐前，咱們提供了免費測試環節，基本流程知足：

第三方風控企業流程

一、私有化部署、免費測試、提供測試報告（根據互聯網業務流量提供免費的業務風險分析和風險預警支持）

二、確認需求、新增需求（若是驗證了風險，並要求作出更多的風險預警能夠增長需求）

三、提供定製化開發，知足新需求（新項目啓動）

四、短週期迭代（敏捷迭代、測試、上線的流程）

五、客戶端部署/升級，確認效果（流量分析、分析報告）

六、部署/升級問題處理（bug修復）

七、項目結束（項目結束）

拍婚紗照流程

一、提供婚紗照套餐樣本

二、選定婚紗攝影套餐、指定服裝和內、外景需求

三、開始拍攝

四、較短短期內完成換裝、換景（切換pose的任務）、再拍攝的工做流程

五、挑選照片

六、根據底片修圖

七、拿到套餐照片

傳統 VS敏捷 ？適者生存

敏捷項目管理只是一個靈活的實踐框架，提供的是一套清晰遊戲規則，根據不一樣的環境能夠提供一系列不一樣的途徑。

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

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

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

閱讀參考

某博主po的一個頗有趣的「敏捷和瀑布」對比例子，給你們做爲閱讀參考：

敏捷開發

• 客人到餐館來點菜（新項目）

• 不肯定客戶想吃什麼的時候，一般選好餐廳後會先看看餐廳的菜單（客戶每每提不出具體的需求）

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

• 後廚開始準備（項目啓動）

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

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

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

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

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

• 客人吃完，很滿意（基本知足了所有的要求）

瀑布模型開發

• 客人到餐館來點菜（新項目）

• 不肯定客戶想吃什麼的時候，一般選好餐廳後會先看看餐廳的菜單（客戶每每提不出具體的需求）

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

• 後廚開始準備（項目啓動）

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

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

• 再過了二十分鐘，十個菜都一塊兒上來了（項目最終一次交付）

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

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

• 因而，後廚只給客戶加了鹽，加了辣

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

做者簡介
阿木豈安科技項目經理 基礎開發出身，主要負責豈安科技安全Saas產品和項目的平常進度管理。