(此圖片由 AI 生成)

今天來看看如何應對專案變更。在專案管理的世界裡，「變更」幾乎是一種常態。商業市場會變化、技術會突破、競業會推出新功能、客戶需求會改變...等等，所有這些都可能導致專案範疇的變更。

但無論怎麼變，重點都在於如何有效地應對變更，確保專案仍能達到既定的目標，根據不同的專案管理方式，有不同的變更應對方式：

預測（瀑布）式

在預測式（瀑布式）專案管理中，變更被視為需要嚴格控制的事件。由於專案的範疇、時間和成本在一開始就已經確定，因此變更會帶來相當大的風險。這就是為什麼在這種專案管理模式中，專案變更需要進入 ICC變更控制流程。

什麼是 ICC 變更控制流程？

Integrated Change Control（簡稱 ICC）變更控制流程 是用來管理專案變更的一系列步驟，它的目的是確保所有變更都是經過審慎評估和批准的。流程通常包括以下步驟：

1. 變更識別

所有的變更請求必須提交紀錄。不論變更請求源於專案內（如團隊成員、公司高層）或外部（合作廠商或客戶）。這些請求應以書面形式記錄，並包含變更原因及預期影響。

再次強調，要記錄，就算老闆一句話說要改，也要記錄下來，書面紀錄是很重要的，這樣後續團隊、CCB 變更控制委員甚至利害關係人或未來的老闆本人才有個紀錄可以參考。

2. 變更評估與分析

PM 要先對變更請求進行初步評估，以確定變更的有效性和必要性。撇除公司老闆或高層的隕石，如果是利害關係人(例如：客戶或內部需求部門)，又在那邊亂提案，那 PM 在這關就應該要先擋下來，而不是直接過度承諾。

評估與分析這一步驟可以先篩選掉不符合專案目標或不具合理性的變更請求。

3. 變更評審

將變更請求提交給變更控制委員會（Change Control Board, CCB）進行審核，決定是否核准、拒絕或要求再多一點資料來進一步分析。

4. 變更執行

一旦變更請求獲得批准，PM 需更新專案文件，包括專案計劃、範疇基準、時間基準和成本基準。並通知所有相關方，包括專案團隊成員和利害關係人。

若變更未被批准，變更請求的拒絕原因和相關信息也需要進行記錄和通知。

5. 變更監控

持續監控變更的影響，確保它不會對專案造成不利影響。

什麼是 CCB 變更控制委員會？

前面提到了 CCB 變更控制委員會，這又是什麼東西？變更控制委員會 Change Control Board（簡稱 CCB )是負責審查和批准變更請求的委員會。CCB 通常由專案的主要利害關係人、PM 以及技術專家(通常是指團隊的技術主管或資深工程師，若沒有則是指外部顧問)組成。CCB 的作用在於：

• 評估變更的必要性：確保每個變更都有充分的理由和依據。
• 分析變更的影響：考量變更對專案的範疇、進度、成本和風險的影響。
• 做出變更決策：根據分析結果，決定是否批准變更，並為變更制定具體的應對策略。

Real World 現實世界的 CCB

其實 CCB 並不是一個真正會掛在 title 的職位，大家試想一下軟體工作中，如果 PM 或客戶說要改東西或者時程改變，通常會發生什麼？

這時候 PM 可能和公司內有技術決策能力的人（包含但不限於 SA、Frontend Team Lead、Backend Team Lead、Design Team Lead 或 Sr.Developer）討論，可能是正式會議，也可能只是在辦公室位置旁邊討論。

大家會討論為什麼要改？可以改嗎？會有什麼影響？例如時程不夠那該怎麼辦？UI 流程要怎麼調整..等等。這些磋商討論決定變更是否更改的會議，還有這些參與的人，就是 CCB 控制委員會。

也就是說 PMP/PMBOK 其實是把專案中面對變更時，負責變更討論的人與事抽出來，賦予一個理論性的名稱 Change Control Board，因為確實能參與討論的人，不一定會是專案執行的最前線員工。所以這時再回頭看前面的定義：CCB 通常由專案的主要利害關係人、PM 以及技術專家（通常是指團隊的技術主管或資深工程師，若沒有則是指外部顧問）組成，是不是對 PMP/PMBOK 就有點感覺了呢？

適應（敏捷）式

在適應式（敏捷）專案管理中，變更被視為一種常態，是專案發展的一部分。敏捷的核心精神是「擁抱變更」，因為專案範疇在開發過程中會根據反饋和學習進行調整。變更不再被視為威脅，而是一種提高產品價值的機會。

重新排列產品待辦清單

當變更發生時，PO 產品負責人要重新檢查和排列產品待辦清單，以確保所有項目依照最新的商業需求和專案目標進行排序。

隨後，敏捷團隊會根據新的優先順序從產品待辦清單中選取項目，並調整衝刺待辦清單。這樣，敏捷團隊就能在每個 Sprint 期間集中精力完成最重要、最有價值的工作項目，也就是說：如果該變更在產品待辦清單上優先度比較高，那麼下一個 Sprint 開始就能優先處理這些任務，這種方式能確保團隊始終在處理「最有價值」的事。

有關產品待辦清單和刺待辦清單，會在 Day20 和大家繼續介紹。

結語

我們作為 Client 端 Web 工程師，即使這個 Sprint 不變也許一個月後突然一顆隕石下來又要改了，輕者改 UI 重者改邏輯（然後還不知道改了能帶來什麼商業價值）根本家常便飯。但是實務上不可能要求不變更，這太難了，在學習 PMP/PMBOK 後，筆者我理解到心態不是要求不變更，而是要想辦法控制和引導變更，如同我在 Day11 文章所說，擁抱變化仍要有原則，不是甚麼都能躲在「價值」這面大旗後面肆意更改。所以怎麼控制變更也是 PMP/PMBOK 中一個重要的內容。