作者／林家瑋, CISSP, PMP, PMI-RMP, PMI-PBA, PMI-ACP

專案管理，不僅僅是一門管理學科，更是一種融會了人性與溝通的藝術。在舞動專案管理的節拍時，我們因地制宜、靈活應變，有如根據地形選擇最適合的交通工具般，選用各種不同的專案管理方法論、工具和技術。當專案的需求可預期，技術明確，時程與成本都在掌握中時，選擇用瀑布式專案管理，也就是計畫驅動的方法論，來一步一腳印地實現目標。在需求模糊、技術複雜且市場環境如萬馬奔騰般多變的情況下，我們則會加入敏捷思維，選擇用Scrum方法論，使產品開發如柳條般柔韌，能快速因應環境與市場變化。那麼，如果把這兩種方法論融合起來時，將會迸出什麼樣的火花呢？接下來就以我在SaaS新創公司導入混合式專案管理的親身經歷，為大家揭開混合式專案管理的神秘面紗。

運用Sprint規劃：一步一步建立價值
首先，Scrum方法論的最大優勢在於其驚人的靈活性，和快速因應市場變化的能力。每個Sprint都能產出可以立即上線使用，並為客戶帶來最大價值的功能。接著我們還會在每個Sprint結束時進行回顧，持續回饋、調整與改善。在我們的產品開發團隊中，使用Scrum進行開發，並設定每個Sprint為兩週，確保能以最快速度回應客戶的需求。

在每個Sprint開始之前，企業會請產品負責人(Product Owner)將客戶需求轉化為一張張清晰且可產生客戶價值的使用者故事(User Story)，並放在Scrum Kanban上的產品待辦清單(Product Backlog)，以利後續的Sprint規劃。在每次Sprint開始的第一個會議，根據這些使用者故事進行三小時的Sprint規劃，決定在接下來的Sprint中需要完成哪些故事。Sprint規劃會議的過程中，產品負責人會針對每一張使用者故事進行說明並與開發人員(Developers)對話，當需求講不清楚或是開發困難的部分會進行討論並調整，如果大家對於使用者故事都沒意見，就會進行規劃撲克牌(Planning Poker)來做故事點估算，以評估每一張使用者故事所要付出的心力(Effort)有多少。這個過程不僅有利於產品負責人與開發人員對需求達成共識，也能大大降低因需求不明確導致的重製成本。每一張使用者故事都具有明確的目標，可以獨立完成，且可以在一個Sprint中完成。

透過各種桌遊與活動提升團隊協作氣氛
在Sprint期間，開發人員會根據Sprint待辦清單上的使用者故事進行開發。每天早上都會於固定時間進行一次15分鐘的Daily Scrum會議，會議中，每個開發人員會說明昨天做了什麼？今天預計做什麼？以及這段時間遇到的問題，如有需要討論問題如何解決，則於Daily Scrum會議之後再另外約一次會議處理。在每個Sprint的最後一天下午，會先進行1.5小時的Sprint審查會議，開發人員會展示這兩週完成的功能，並讓產品負責人與客戶直接操作，此時也是客戶進行回饋的時間。Sprint審查會議結束後，Scrum團隊全體會進行2小時的Sprint回顧會議，每一個人都必須寫兩張卡片，以提出整個Sprint的過程中有哪些地方做得好、哪些地方做得不好，並挑選出一兩個可以在下一個Sprint改善的點。

根據我的經驗，在Sprint回顧會議流程中，並非都採用相同的模式。我會細心根據每次專案團隊期望改善的目標，策劃出各式各樣不同的桌遊或活動，使回顧的氣氛更加生動有趣。例如：
一、透過「說書人」這款桌遊：
激發不常開口的工程師更好地表達他們的想法。透過這樣的遊戲模式，工程師得以在輕鬆的環境中展現他們的想法，並與其他團隊成員共享。

二、透過「傳情畫意」這款桌遊：
鼓勵團隊面對面溝通，降低過度依賴文字訊息的情況。

三、透過「報到」(Check in)的活動：
進一步提升團隊的同理心並豐富會議的氛圍。此活動讓每個人都有機會分享自己的感受，進而增進彼此的理解和連結。

長期規劃與高階主管的溝通需求
然而，如同各種工藝品需要適當的工具和方法，Scrum也並非萬能。對於那些需要長期規劃，或是要規劃一年、三年甚至是五年的產品功能Roadmap，就需要更計畫導向的規劃方法。尤其是在與股東、公司負責人或高階主管定期溝通進度與報告時，他們更習慣看到熟悉的標準格式，例如：工作分解結構(WBS)、時程表(Timeline)、責任分配矩陣(RACI)以及進度超前或落後的狀況……等報告。這就是我們為何要加入瀑布式專案管理的主要原因。

瀑布式專案管理，如同壯觀的瀑布般有順序且連續，它將專案切分成一個個順序性的階段，從整體規劃、需求分析、架構設計、功能開發、QA驗證，再到上線維護，每個階段都有明確的投入與產出，必須在進入下一階段前，完成上一階段的工作。這種方法理論上十分適用於需要長期規劃與產出大量文件做為交付成果為主的專案。

結合Scrum與瀑布式的優勢：混合式專案管理
在實際操作時，我們會依照產品功能需求、時程、成本與資源限制，使用瀑布式專案管理方法來規劃產品功能Roadmap，然後採用「OPPM（One Page Project Management，一頁紙專案管理）」，來管理與監控接下來半年到一年要開發的功能。在OPPM上的日期區間，同時會標註此為第幾個Sprint，以映射到Scrum開發團隊的Sprint開發週期。接著，將WBS的每個工作項目映射到相對應的使用者故事，以確保Scrum開發團隊完成的成果，能與瀑布式專案管理的規劃步調一致。這種方法讓專案團隊在保持產品開發靈活性的同時，也能對產品開發的整體進度有明確的掌控。

在SaaS產品開發過程中，專案團隊巧妙地將Scrum與瀑布式專案管理的優勢結合，形塑了專屬於我們公司的混合式專案管理方法。團隊成員利用Scrum來進行產品開發，以應對變動無常的市場環境與強大的競爭者；另一方面，又透過瀑布式專案管理來進行整體產品的一年、三年，甚至五年的產品功能Roadmap規劃，並產出高層管理者希望看到的報告格式。這種混合式專案管理方法巧妙地融合Scrum的調適性和瀑布式專案管理的預測性，進一步讓開發團隊產出更高的客戶價值之外，更有效地滿足了關鍵利害關係人的期望。

混合式專案管理方法結合了Scrum與瀑布式專案管理的優點，讓團隊在面對各種複雜的專案時，更能因應市場變化，產出有價值的增量，除了對開發成果更有信心之外，也同時滿足利害關係人的管理需求。管理者應融會貫通、逐步改善，以在複雜多變的VUCA時代中維持競爭優勢。