這些年來，許多學習專案管理的朋友，在初學專案管理時都一頭栽入專案管理工具與框架，卻未曾了解更源頭的問題，包含：
「為什麼需要學專案管理？」
「專案管理能解決什麼問題？」
「專案管理不能解決什麼問題？」
「為什麼案子總是做不好？」
「怎麼樣才能做好一個案子？」
在學習一門知識時，我建議大家必須先從問題開始思考，當你對這些問題有了基本的認知，接著開始去找幾個framework、methodology或best practice，然後看看它們用什麼樣的流程與工具來解決你所面對的那幾個問題，唯有經過這樣的過程，你對這門知識才會有更清晰的認知。
PMP或Scrum這類的framework或best practice的出現，都是累積了足夠多的實務案例，並將常見的問題以 框架、流程、方法、工具 來封裝，讓其他人更容易上手。但若你未試圖理解它背後要解決的問題，你就容易錯用。
不管工具有多好，若你運用的場合不對，它就不是個好工具。
CMMI與PMP真的不好嗎？
剛出社會時，我在一家ERP軟體公司從事研發工作，我在哪裡接觸到非常正規的軟體工程，也見識到當研發流程與業務特性匹配時的高效，以及不匹配時產生的諸多問題。在2000年初期，軟體發展大多仍依循瀑布式(Waterfall)方法，必然得先進行需求收集、分析、設計，使得進入開發與測試，經過一道道程式後將成品完整的交付。
我在ERP軟體公司的那些年，我也參與了CMMI Lv4(軟體成熟度模型)的導入與認證，過程中 我見識到CMMI的嚴謹之處，同時也體會到嚴謹背後帶來的低效與冗餘。 由於當時我所負責的產品處於需求不明確，市場性待驗證的狀態，若要依CMMI的規則產出完整需求清單與完整的分析檔，估計是不可能。
因此在過程中我試著提出用假設性需求，以及用雛型替代成品來進行市場驗證。出乎意意料的，這個提議獲得CMMI顧問團隊的認同，而這也是我對CMMI有所改觀的轉捩點，公司內推動小組的負責人告訴我：
「CMMI本來就是一個模型，每家公司得依自己最適合的方式建構流程，但最終須能達到CMMI要求的水準。」
2011年，我開始負責SaaS相關業務，也首次接觸了敏捷觀念以及Scrum，與此同時，互聯網開始進入火爆增長，所有的企業都在求新求快，技術團隊也被要求要具備更靈活、更彈性、更迅速，只是一兩年時光，大陸的公司都在討論敏捷開發，而少有人討論PMP、CMMI所談的瀑布式專案管理與研發流程管理方法 (註：PMI後來也提出ACP這套敏捷框架)。
2013年，我開始在團隊中大量引用敏捷觀念，透過頻繁的交付來驗證用戶與市場需求，也在技術社區中與許多朋友交流專案管理與軟體發展方法，我看見愈來愈多人想擁抱敏捷，同時我也發現，許多人因崇尚敏捷，而對PMP及CMMI抱持著嚴重的偏見。
2015年，我進入互聯網公司後，人人口中所談的都是敏捷，若你在討論過程中提到CMMI或PMP，就會有人露出鄙視的眼神。他們誤以為過去專案做不好，是CMMI與PMP所造成的，卻未曾思考過，或許專案失敗的真正原因不在流程與工具，而是運用的那些人。
瀑布式與敏捷並存，可能嗎？
我曾在先前的文章中提過，我認為組織長大到一定規模後，必然會出現混合式的組織架構，當企業內外部狀況穩定，需求的變化性較少，可預測性高，功能型組織是相對適合的組織架構；而當需求變化性較大，不確定性高，變平化的產品型或戰鬥小組可能是更適合組織架構。
而相同的概念，其實也適用於專案管理方法，當你特別強調 分工程序、輸入(input)、輸出(output)與權責，這與功能性組織不謀而合，傳統的專案管理方法可能非常合用；反之，若你強調快速回應、迭代等敏捷特性，則與產品型組織或戰鬥小組更加匹配。
所以，瀑布式與敏捷方法並存在一家公司內，可能嗎？
我的答案是「肯定的」，當我們把重點放在解決問題，而非落入比較方法或工具的優劣時，我們便會理解，沒有必要硬要逼所有人套用相同的工作流程與方法，除非真有必要性。
經過這些年的實戰運用，我試著將這種混合式的專案管理方法整理成如下的框架，多數的專案都是介於完全不確定與完全確定之間，面對不確定性高專案，敏捷方法、分工模糊的戰鬥小組相對較佳，然而面對確定性極高的專案，Waterfall與分工明確的功能型或專案型團隊則相對適合。以目標導向來看，很多時候我們甚至該採用混編的方式同時進行專案。
追求敏捷，但更要重視專案管理基本功
在帶領團隊時，我特別強調專案管理的基本功，因為 我認為多數的問題都是出在基本功不夠扎實。在專案開始前與進行中，一般我會對PM提出很多問題，以確保專案能如原先預期。
在專案啟動階段，一般會由團隊先就已知資訊先擬定draft plan，內容陳述專案要 做哪些事？打算如何進行？由誰來做？預計花費多少時間？以及得到什麼樣的結果？
「這個專案中有哪些不確定性，它們可能會導致你無法準時交付？」
而當團隊將計畫產出後，我會問PM這個問題。從這個問題的回答中，我便能有效檢視PM對這個專案的把握度有多少。
專案管理早期的主要問題大多是「要解決的問題不明確」、「需求不夠清晰」、「專案的deadline太趕」、「不確定人力資源能否配合」、「對工作的估時過長或過短」、「技術可行性待驗證」、「老闆可能還會改動需求」等。
而這些，就是導致專案行階段會頻繁發生變更(change)的重要原因。
這些不確定性，都可能是專案執行時期的風險，你可以選擇在規劃前期就想辦法處理這些不確定性，也可以選擇在執行時，透過變更管理來因應這些不確定而帶來的更動，而成熟的PM會將這些不確定性有效控管，並以面對風險的方式去處理。
敏捷雖強調擁抱不確定性，並歡迎隨時的更動，但不意味著我們要對那些不確定性置之不理，而是要儘快的讓不確定成為確定。
敏捷強調不斷進步與回饋，透過一個又一個專案的磨練，讓我們能把需求看得更清楚，對時程估算更準確，能更有效對齊老闆的期待，而要做到這些，團隊就需要逼著自己不斷進步，透過反覆的迭代，將不確定性一一消除。
若你對Scrum架構有所研究，你便會發現best practice裡頭強調的架構，其實正是針對上述幾個最常見的專案不確定性而來。
針對時程，Scrum強調固定的交付週期，以1–4周為佳；
針對團隊，強調最好是feature team，在過程中也盡可能避免團隊成員同時參與多個專案；
針對範疇，根據迭代週期與team的資源，由Product Backlog中挑選能完成的工作項目；
加上每個迭代的週期較短，工作總量較小，若過程中發生變更或插單，其實影響的範圍相對較小，等待時間也較短，對變更的因應能力自然較強，若你正確的引入Scrum，這將是你可期待的結果。
先思維，後框架、工具
在學習專案管理或其他知識時，我非常建議大家一定要先建立思維，先了解我們要解決的問題，也就是背後的「Why」，例如要確保工作能如期如質的交付。並圍繞著為什麼去找尋別人是用什麼樣的框架與方法去解決的，也是就「How-to」，例如PMP或Scrum，而在框架與方法之下，又分別選用了什麼樣的工具，這就是「What」，例如WBS、user story等等。
學習過程，一定要先搞懂要解決的問題，並進一步思考為何框架的設計與工具能解決我們遭遇到的問題，並思考它的適用範圍。
唯有如此，我們才能跳脫被框架與工具，而不為物所役。
本文由游舒帆授權轉載自其> Mediuam。
《數位時代》長期徵稿，針對時事科技議題，需要您的獨特觀點，歡迎各類專業人士來稿一起交流。投稿請寄edit@bnext.com.tw，文長至少800字，請附上個人100字內簡介，文章若採用將經編輯潤飾，如需改標會與您討論。
（觀點文章呈現多元意見，不代表《數位時代》的立場。）
