前陣子公司一位新同事得知我有 PMP 證照後，突然沒來由地問我「執行專案時，該選擇敏捷 Scrum 或是傳統 Waterfall 的專案管理方式？」他說自己目前依照過去在學校以及前公司學習的經驗，埋頭專注把規格書寫好，以為交給工程師之後，過一段時間就能看到成果，沒想到兩周後工程師非但沒有任何進展，還反過頭來怪他規格不明確，也沒有經過排程，根本不應該插案處理，害他頓時顏面無光。我聽完他的苦水後，反問他三個問題：「你對 Scrum 和 Waterfall 了解多少？」、「你認為公司的管理和策略風格比較偏向哪一種？」、「你認為你的專案團隊屬於哪一種類型？」他搖搖頭，一臉苦惱的模樣......

1. Scrum 和 Waterfall

傳統的 Waterfall 手法，顧名思義，就像瀑布流下的水一樣，無法再回頭。Waterfall 的管理方式起源於 1970、以製造業為主的年代，因此講求效率與交期，特色是低變動，可透過標準化程序管理，所以執行上要求每個環節一棒接一棒逐一進行：工業廠房先處理原料，再進行加工，最後才是包裝與出貨；軟體公司則由企劃先撰寫規格，經過 UI 設計、系統分析，最後才交棒給工程師開發，越下游的工作者修改的彈性越小，多半只能聽命交辦事項行事。

由於資料科技漸趨發達，軟體與網路相關產業蓬勃發展，傳統的 Waterfall 不見得能夠滿足所有的管理需求，因此才有敏捷（Agile）管理的出現，其核心理念是「顧客導向、即時回應、快速迭代」。敏捷管理中最為人熟知的就是 Scrum 管理框架，Scrum 團隊約為十名成員左右，以一個接一個不超過一個月的 Sprint 週期（註1）進行開發，每個 Sprint 相當於一個小型的專案，必須有特定的交付產出，並且在下一個 Sprint 收集用戶回饋，予以修正，藉由這種快速進入市場測試水溫的方式，讓產品搶得先機。

Scrum 看似比 Waterfall 多了許多彈性，但為了能夠維持高效產出，團隊成員必須在 Sprint 運作週期內高頻率溝通，這對彼此作業模式不同的成員來說，是一項非常大的挑戰。同時，敏捷管理弱化了文件的作用，若開發過程中沒有妥善的版控管理，日積月累疊床架屋之後，可能會招來更大的技術債以及陷入規格混淆不清的窘境。

2. 公司的管理與策略風格

初步了解 Scrum 與 Waterfall 的差異後，PM 大致可以知道自己該具備什麼能力，以及該如何引導團隊進行，一般來說，Waterfall 容錯率較低，因此初期的規劃階段相當重要，PM 對於規格的掌控必須精準到位，這也是軟體公司 PM 通常具備技術能力的原因之一。Scrum 則更強調溝通，PM 要快速整合不同成員的意見，針對產品做出修正，對市場需求敏感度也相對較高。

然而，真正決定管理辦法的，往往不見得是 PM 本身。PM 除了領導專案前進之外，也需要對利害關係人與 sponsor 負責，不同的管理方式有不同的回報機制，如果 PM 無法理解公司老闆的管理風格，忽略了主管們的期待，那麼團隊運作得再好，可能也會不斷受到老闆的特別「關愛」。例如公司策略一向較為保守，希望產品經過多次琢磨與品質驗證後才能對外推出，但 PM 卻使用敏捷手法快速將產品推向火線，其結果大概可想而知。

3. 團隊的屬性

即便管理方法符合公司期待，團隊成員是否充分了解自己所扮演的角色？特別是 Scrum 這種講究溝通頻率的運作方式，假設有任何一位成員不肯拋棄過往的作業模式，堅持會議、溝通會影響自己的工作節奏，那麼 Scrum 預構築的敏捷陣型就會出現缺角，其他人很可能要耗費比以往更大的心力才能達到相同的成效。

在 Scrum 團隊中，主要的角色只有三種：Product Owner、Scrum Master（註 2）和團隊成員。成員中不論設計師、工程師、行銷人員等，基本上不會區分資深工程師、技術主管或任何階層高低的差異，凡事講求對等溝通，各自對專案目標提供最有效的建議，這對於較不擅長團體討論的人來說，需要一些時間適應，比起面對面溝通，他們更喜歡自己靜靜閱讀文件，咀嚼其中的細節。

當團隊中有成員無法適應管理方式，PM 務必及早調解與輔導，比起要求團隊交付管理所需的資料、進行表定的會議，更重要的是讓他們理解管理的精神與期望解決的問題，例如選擇 Scrum 管理框架是為了盡早進入市場取得用戶反饋、修正產品功能，因此需要精實、即時反應的開發隊形；選擇 Waterfall 則是因應專案的變化性小，可控性高，因此需要專注單一流程的進行，同時也讓完成任務的成員釋出資源，加入其他專案的運作。團隊成員越理解管理的目的，才越能發揮自身在專案中的最大價值。

事實上多數的企業不一定會執行純粹的 Waterfall 或 Scrum 管理方式，特別是軟體、資訊等講求迭代速度的相關產業，企業可能使用種混搭的形式，例如規劃與設計階段採用 Waterfall 產出初版的企劃規格文件，進入開發階段時，則採用類似 Scrum 的方式，每日召開會議確認進度，輔以腦力激盪等會議來彌補規劃階段的不足，討論出較佳的施工工法，最後再依 2-3 週的頻率安排每次開發的範疇，確保團隊維持固定的產出。

使用哪一種方法進行專案或產品開發的管理，並沒有絕對好或壞，每一種方式都有其優缺點，重要的是找到最適合自己和團隊的運作方式。我那可愛的新同事聽完我的說明後，點點頭說，「管理只是一種手段，還是要回歸問題的核心去思考，才能做出最佳的選擇，對吧？」

註1 : Sprint 中文翻譯為短程衝刺，意思是開發團隊固定一個週期完成某些任務並推向市場，一般約為 2-3 週。在 Sprint 開始前會先將產品需求切分為數個小範疇任務（product backlog），接著藉由排程安排每個 Srpint 可消化之任務（srpint backlog），Sprint 開始時經過 Planning Meeting 並估算工時，確認最終交付標的，接著就是一段密集的衝刺開發，期間每天需 5-10 分鐘的會議快速對焦（Daily Meeting），並在 Sprint 結束時召開 Review Meeting 確認成果，以及後續可改善的方向。每個 Sprint 結束後，緊接著就是下一個 Sprint 開始，不斷循環。

註2 : Product Owner，簡稱 PO，負責管理產品需求，並且向團隊說明需求的成員，也是最了解問題背後價值的人。Scrum Master，類似專案 PM 的角色，但更偏重於團隊管理、流程運作，以及協助團隊排除外在干擾的人，由於需要和開發人員密切合作，因此經常有具有技術背景的同仁擔任。