專案經理的必修課：不只是管進度，更是讀懂團隊的「節奏」

當我在開始學習管專案的時候，學到很多不同的專案管理方法，例如「瀑布」、「敏捷」、「迭代」、「層量」、「極限」等等，真的讓人頭痛。而且在技術那一邊，也有相似的名詞。就拿我自己行業為代表，軟體開發生命週期（SDLC）類型就有瀑布型、敏捷型、精益等一大堆。這這相似的名詞，到底指的是不是同一種東西呢？身為專案經理的我們，又應該如何理解它們，並讓他們能為我們所用呢? 這一編就讓我來簡單介紹一下它們吧。

專案生命週期：PM的管理指引

首先，什麼是專案生命週期 (Project Lifecycle)？

教科書的說法是「專案從開始到結束所經歷的一系列階段」。用我自己的說話來說，就是：「把未來的時間（從專案開始到結束）切成各個不同命名的段落。」

我把自己的專案切成「範圍」、「計劃」、「監控」和「收尾」四個階段，它分別代表專案最開始確定需求的時段、實施前的規劃時段(或中間的規劃深化時段)、實施其間的時段、完成專案並交接給營運的時段。

當然，不同的公司或 PMO (專案管理辦公室) 都可能有自己的劃分與命名方式。這裡的重點是，專案生命週期的劃分沒有絕對的標準答案，它往往與企業文化和行業特性有關。

那麼，把時間切成不同段落的意義是什麼呢？簡單來說，它給了專案經理一個清晰的管理框架，讓我們在每個階段都有明確的任務目標。例如在我的框架中，「範圍」這一階段，需要完成的是客戶確認專案需要解決的需求。而「計劃」這一階段很好理解的就是完成各種事情的計劃（某方面來說也叫制度）。「監控」這一階段就是計劃（或制度）的體現，專案經理需要的是確保一切都是在計劃之內。並且當事情出現問題時，對計劃作修訂，直到專案中一切技術相關的工作完成。當你清楚每個階段該做什麼，你的管理工作自然會更有方向感。當專案經理明白每一階段需要完成什麼事情後，即能更有目標地執行其管理工作了。

這裡，專案經理需要特別留意，在專案實際執行的過程中，可能會按照開發生命週期而重覆上述階段的某些部份。其中以「計劃」這一階段重覆的可能性最大。我們需要明白的是，現代專案的實施已經不再強調流水線式，而是要求專案具備更強的靈活性，我們需要透過多次由淺至深的規劃，來確保專案最終能產出預期的價值，而非僅僅是完成某個產品。

此刻，你可以問問自己：你的專案有明確的階段劃分嗎？你是否深入理解公司為每個階段設立的目標，還是只在按章辦事？完全不過問的情況下直接套用公司給你的框架。

當然，任何框架都必然簡化了現實的複雜性。專案經理仍需要判斷專案當下處於哪個階段，尤其是在面對五花八門的開發流程時。此外，團隊採用的開發方法（也就是我們接下來要談的開發生命週期），也會影響你在同一個專案階段的工作重點。這對於專案經理來說，不能只關注專案生命週期來管理，而是需要同時配合團隊的實際工作，來提供適當的管理及指導。

接下來，就讓我們深入了解那些多樣的開發生命週期吧。

開發生命週期：團隊的合作協議

在介紹完專案生命週期後，現在讓我們聚焦到團隊的實際工作層面——開發生命週期。

如果說專案生命週期是為了讓專案經理知道，在何時應該作何種管理活動的話；那麼，開發生命週期就是讓整個技術團隊知道，成員們如何協作，以及用什麼樣的流程和順序，來將一個想法變成實際的產品。

那麼把從零開始到完成產品的這段期間分成不同階段又是為了什麼呢？從管理角度看，當專案規模擴大到數十甚至數百人時，如果沒有清晰的流程，協調工作將是一場災難。開發生命週期透過定義工作的流程，劃分了不同階段的權責，讓管理變得更清晰。

最經典的作戰手冊，無疑是「瀑布式 (Waterfall)」模型。

它像一條生產流水線，嚴格規定了工作的邏輯順序：必須先完成所有的「需求分析」，才能移交給下一站做「系統設計」，接著是「開發」、「測試」，最後「部署上線」。每個階段都有其主要負責的團隊，權責分明。這種模式在需求極度明確、幾乎不會變動的場景下非常高效。

然而，商業世界瞬息萬變。

投資人不想再等專案完成後才能看到完成品，他們希望能儘早檢視成果，確保投資沒有偏離方向，也藉此降低風險。也能減低一些投資風險 。於是，「增量式 (Incremental)」 的開發方式應運而生。它的核心思想是「分批交付」，不再是一次性做出完整的產品，而是先交付一個核心版本，再逐步增加新的功能模組。

隨後，時代的腳步越來越快。

「快速佔領市場」比「推出一個完美的產品」更重要。在這種思維下，「敏捷 (Agile)」 的理念應聲而起。敏捷的核心目標，就是讓團隊能以最快速度向市場交付價值，並持續收集回饋進行優化。它相信世界上沒有所謂的「完美產品」，只有「持續進化的產品」。

從瀑布式到增量式，再到敏捷，你可以看到，不同的開發生命週期，本質上是開發團隊為了適應不同的商業目標，而演化出的不同工作流程與合作模式。

那麼身為專案經理的你，在認識這些「開發生命週期」有何幫助呢？ 下一節，就讓我來結合專案與開發兩種生命週期，說明它們如何共同影響你的專案成敗。

不只是兩條平行線：如何整合專案與開發生命週期

了解了兩種各有側重的生命週期後，讓我們來回答那個最重要的問題：為什麼專案經理必須理解團隊的開發生命週期，才能有效管理專案？

如果你細心閱讀了前文，就會明白不同的開發模式，是為了給投資者帶來不同的商業價值。瀑布式，承諾了一個可預測的未來，讓投資者能精準規劃資金；敏捷式，則承諾了更快的市場反應速度，讓產品能搶佔先機。

現在，試想一下：如果你作為 PM，完全無視團隊的作戰方式，只固守自己學來的一套管理流程，會發生什麼災難？

• 場景一：在敏捷團隊中強推瀑布式管理。
  你要求團隊在 Sprint 中途接收到一個新想法時，必須先填寫一份詳細的「變更申請單」，並等待下個月的委員會審批。這樣一來，敏捷最核心的「快速反應」優勢將蕩然無存，團隊還敏捷得起來嗎？

• 場景二：在瀑布式團隊中套用敏捷式管理。
  你告訴團隊：「我們不需要太詳細的前期規劃，邊做邊看吧！」這等於是親手摧毀了瀑布式對投資者最大的承諾——「確定性」。當投資者來問你專案的總預算和最終交付日期時，你將啞口無言，因為這個模式的根基已經被你動搖了。

因此，一位優秀的專案經理，在專案啟動之初，首要任務就是辨識專案的核心特性，與團隊共同選擇最合適的開發生命週期。這不僅是為了最大化滿足投資者的期望，更是為了讓自己能調整管理策略，成為團隊的助力，而非阻力。

那麼，專案生命週期的各個階段，要如何與開發生命週期配合呢？讓我們以瀑布式為例，做個簡單的推演。

瀑布式的核心是「預測」，團隊相信自己能完整地規劃出通往終點的道路。作為 PM，你的管理原則就是守護這條道路，盡可能避免偏離。

• 在專案的「啟動」與「規劃」階段，你的首要任務是引導團隊，將他們腦中那幅「完美的藍圖」鉅細靡遺地落於紙上，並獲得客戶的書面確認。

• 進入「執行」階段，你的角色轉變為「進度的守護者」與「風險的控制者」。你嚴格對照計畫，確保團隊的產出與約定一致，並主動為他們排除前進道路上的一切障礙。

看到了嗎？專案經理的工作，正是在專案的不同階段中，靈活切換自己的角色與工具，來支援團隊的工作流程。 當團隊的開發模式改變時（例如從瀑布換成敏捷），你的支援方式也必須隨之進化。

在未來的文章中，我將會更深入地探討，在不同的開發生命週期下，專案經理於各個專案階段中，具體應該採取哪些管理行為，才能真正有效地支持團隊、成就專案。

如果這篇文章對你有所啟發，請不吝給我一個鼓勵，也歡迎在下方留言，一起交流你的看法！謝謝。