傳統的瀑布式管理，應該被淘汰了嗎？
敏捷式管理，是現代最好的專案管理模式嗎？
選擇敏捷式專案管理，跟傳統式專案管理，可以從專案金三角：「範疇、時間、成本」來解答。
傳統專案管理，決解的通常是目標明確的專案目標，例如蓋一棟二十層樓高的房子、生產 iPhone 14 的手機保護殼等。而因為專案目標是明確的，成本跟時間通常就是依著這個專案目標去制定，拆解 WBS、畫甘特圖等，然後依計畫行事。
而敏捷式專案管理則不同，它面對的通常是一個不明確的專案目標，例如打造一個好用的繪圖軟體。好用、受歡迎不是一個可以量化、規格化的目標，即使專案經理有心去做預先規劃。這種情況之下，在可投入的資源量 (時間、成本) 固定的情況下，盡可能早的推出交付，測試是否符合市場的需求。而不是先做週延的規劃，方方面面的覆蓋了用戶的需求，再來進行工作拆解、執行。
所以，最簡單的差異就是這樣
傳統式 | 敏捷式 | |
範疇 | 固定 | 可變 |
時間 / 成本 | 可變 | 固定 |
如果你是個開發商，你的請款是依交付的範疇，那你最好用傳統式的專案管理模式，否則你會很難達成交付驗收的條件。應該沒有業主能夠接受，委託你蓋一棟房子，最後造出一艘船，仍欣然接受這樣的交付。相對的，只要你交出一棟二十層高，只用了一半的時間，你通常可以順利驗收結案。
但如果你是個產品經理，那在條件允許的情況下，你應該盡可能的採用敏捷式的專案管理模式。因為當專案總體範疇難以劃定，你難以精確的去拆解工作包後再逐步去完成。那讓範疇的決定盡可能的延後，就是敏捷式的策略。它跟傳統式最大的差異是，既然大的專案範疇無法定義，那就是把每次迭代的範疇變小，讓專案團隊在單位時間成本內，先完成優先級高的需求。而優先級高的需求完成了，剩下的需求可能其實就都不重要，只要團隊一直撿出當下優先級高的需求完成，便能逐步向 TA 心目中的最佳產品靠近。
前面提到，條件允許的情況下，應該盡可能的採用敏捷式管理來發展產品。
那什麼是條件允許？
團隊素質高：敏捷式開發強調團隊成員要互相補位，自主溝通，而不是靠一個專案經理來指派任務。也就是說，團隊成員需要有較高的成熟度要求，不管是對其它工作的理解、溝通合作的能力、填補縫隙工作、等。
變更的成本較低：這邊所謂的變動成本是一個相對值。當你的專案是需要先開一個 200 萬的模具，你可能很難用敏捷的方式邊做邊滾動 ( 除非你的專案總預算是 200 億) 。但如果比較偏向純人力作業，先做 A 需求或是先做 B 需求的影響不大，甚至 B 需求做完，放著 A、B 去做 C 需求，並不會因此承受額外的損失。
時間導向，允許範疇縮減：敏捷式管理更強調時間到就要發佈，因為需求總是做不完也無法確定的，所以用固定的時間，再來推動盡可能更多的產出。相對地來說， PO 就要能接受這樣範疇相對不確定的情況，不能因為想要包山包海而推遲迭代，心想著：我要做得再更完整一點、另一個需求對用戶來說也很重要…等等。
變更風險承擔：在產品研發的個案研究，不乏會出現 [ 原本要做遊戲、後來是單獨的相簿功能大成功 ] 這類的故事。但如果開發團隊被要求，除了交付出一套遊戲，否則拿不到錢。那不管用什麼方式進行專案管理，那你一定只會得到一套遊戲。即便是團隊做到一半就發現目前的專案方向可能會不如預期，相簿功能卻大受推薦；在產品失敗與個人考核面前，人性都會先顧好自己的考核。所以只有調整考稽機制，讓變更的風險不會由團隊來承擔，才能讓敏捷式管理的適應變化能發揮作用。
綜合前面提到的一些條件，可以發現敏捷式專案管理，比較適合在新創產品、小規模團隊、材料機具使用率較低(更多是研發人力) 的情境下適用。如果遇到跨組織、跨職能的專案協作，通常還是回到 PMBOK 暢導的傳統瀑布式管理為主。
Opmerkingen