從被主管罵到學會把關，我的需求控制血淚課

剛當上專案經理時，我最常遇到的噩夢就是：專案明明已經進行到一半，甚至系統都快開發完了，客戶或使用者才突然丟出一大堆沒聽過的需求——可能是全新功能，也可能是大改現有架構。

這意味著開發團隊得回頭重工。對身為 PM 的我來說，這代表專案成本暴增、時程延宕，最後老闆還會扣我一頂「管理不力」的帽子。

為此，我絞盡腦汁想控制這些在專案後期才冒出來的「範圍蔓延（Scope Creep）」。我試過強硬拒絕系統開發完成後的所有修改，結果被客戶客訴；我也試過乖乖照規矩走，把所有需求都提「變更申請（Change Request, CR）」，結果被變更管制委員會（CCB）的主管狗血淋頭，罵他們時間寶貴，別拿雞毛蒜皮的小事來煩。

就這樣，我在需求管理這條路上跌跌撞撞了好幾年，總算摸索出一些實戰心得。如果你也正因為無止盡的需求變更而痛苦，不妨繼續往下看，我是如何控制這些「許願池」般的用戶需求。

你是不是也忘了問：專案為什麼存在？

不知道你們接到一個新專案時，腦中浮現的第一個念頭是什麼？過去的我，直覺反應永遠是：「這個專案要做什麼？」

沒錯，我第一時間關心的，是我跟團隊要做出什麼東西。是一個 HR 系統？還是 ERP 系統？系統要有什麼功能？我們有多少時間能搞定？

但我卻從來沒有關心過我的客戶（專案發起人），他當初為什麼要拍板啟動這個專案？他希望透過這個專案達成什麼目標（Why）？是想提升效率、增加營收？還是為了提升資安層級、為未來的擴充做準備？

現在回頭看，我會說：「搞懂專案為何而生，是控制需求最重要的一步。」因為如果你不知道「為什麼要做」，只把眼光放在「做什麼」，就等於把開槍的權力交給了別人（業務單位）。他們提出的所有要求，在你眼裡都會變成「必須滿足的絕對存在」，你根本無從拒絕。

專案章程（Project Charter）才是你的救命稻草

說到控制需求，很多人第一時間想到的是走「變更申請」。但就像我前面說的，太多的變更申請不僅會拖垮團隊的正常作業，也會讓高層管理者覺得煩躁。

因此，最高明的做法，是先確立專案「因何而立」。而找到這個答案的最佳途徑，就是你的「專案章程」。

專案章程裡，通常會明確寫出專案存在的最終目的。舉個例子，曾有客戶想要一套新的 HR 系統，原因是舊系統太老舊、難以擴充，且使用了許多已經停止支援的軟體，存在資安隱憂。

得知這個「真正目標」後，我第一時間要求團隊做什麼？我不再是跑去跟業務部門訪談他們的工作流程，而是請他們開放現有系統的權限，讓團隊仔細盤點系統的整體功能與架構。

所以，當我收到業務單位提出各種五花八門的要求時，我會請他們說明：「這個需求跟我們的『專案目標』有什麼關聯？」如果 IT 部門的人要求我不要使用來路不明的外掛套件，並說明這能降低資安風險，這時我才會請團隊評估這個變更對開發中系統的影響。

舉例來說，當時業務單位跑來許願：「既然要換新 HR 系統，能不能順便加一個 AI 自動篩選履歷的功能？」如果以前的我，可能就傻傻地拿去問工程師能不能做、又或者已經思考應該如何滿足對方的要求。但在我重新檢視專案章程的目標是「解決舊系統資安問題與平順轉移」，我便能理直氣壯且委婉地回覆：「AI 篩選是個超棒的想法！但我們這次的首要任務是確保大家下個月薪水能安全、準時地發放，不被駭客攻擊。AI 功能我們把它列入 Phase 2（第二期）的優化清單，好嗎？」用「大目標」來擋「小需求」，對方通常無法反駁。

這招不僅能保護團隊寶貴的開發時間，更能確保專案不會偏離當初設定的航道。

明確界定專案範圍，是控制的起點

以前的我，其實不太懂「專案範圍」到底指的是什麼。對於軟體開發專案，到底該怎麼界定範圍，我才能理直氣壯地向變更管制委員會提出變更申請？換句話說，我當時的痛點是：我不知道該怎麼說服需求提出方，讓他們明白「你現在提的這個，不在原本的範圍內，這是新加的！」

對 PM 來說，如何界定範圍，直接關係到後續你能否有效控制各種天馬行空的要求。一般來說，專案始於一些概念性或大方向的需求。在最初期，你可能會聽到使用者抱怨系統哪裡難用、效率低落，或是希望系統具備某些功能。

當專案正式立案，團隊了解使用者需求，且雙方對解決方案達成共識後，就應該訂定出專案的「基準線（Baseline）」。也就是說，團隊必須清楚知道：系統要完成哪些功能？涵蓋哪些使用情境（Use Cases）？以及預計的完成時間。

這三個面向共同組成了專案的「初始基礎範圍」。後續任何的更改或細節補充（例如：使用者突然希望在 A 功能輸入資料後，系統要能自動同步到 B 功能，以減少重複輸入與人為錯誤），在管理的角度上，都必須被視為「變更」。

回想我過去犯下最大的錯誤，就是在收集完需求、產出設計方案後，沒有要求團隊產出「詳細的功能細節設計」，導致使用者根本不清楚每一個功能完成後，具體的「驗收條件（Acceptance Criteria）」有哪些。

這種「模糊地帶」，對專案後期的控制是極度致命的。因此，建立清晰的範圍組成與界定，絕對是 PM 控制專案必不可少的一步。

千萬不要只寫「系統要能匯出報表」這種模糊的範圍。明確的驗收條件應該長這樣：「使用者能在報表介面，點擊按鈕後，於 5 秒內匯出包含當月所有員工出勤紀錄的 CSV 檔。」更好的做法可能是報表內的每一項數字的資料出處及計算公式都詳細列明。當你把細節定義到這個程度，並讓客戶簽字確認，專案後期那些「我以為報表會有圖表啊」、「我以為可以匯出 PDF 啊」、「我以為你們懂如何計算的啊」的爭議，就會瞬間消失。

結語：變更不是壞事，失控才是

當你有了明確的「專案目標（Why）」作為濾網，又有「基準線與驗收條件（What）」作為尺規，你就能在第一線擋下 80% 不合理的需求（例如直接告訴客戶這屬於第二期專案）。剩下那 20% 真正會影響架構、需要追加預算的重大變更，你再整理成完整的 CR 送交 CCB。這時候，CCB 的主管不僅不會罵你，還會覺得你是一個懂得把關、有判斷力的專業 PM。

身為專案經理，接到變更需求並不代表專案失敗。真正的失敗，其實是專案目標不明確、範圍沒有清晰界定，進而在後續開發過程中引發的全面失控與混亂。

下次當客戶又在專案後期提出新需求時，請在心裡默念這三個步驟：

1. 問 Why：這符合專案章程的最終目標嗎？

2. 看 What：這在我們當初簽字確認的基準線與驗收條件內嗎？

3. 再談 How：如果真的要做，我們該如何啟動變更申請（CR），並評估對時程與成本的影響？

學會畫清邊界，才是專案經理掌握控制權的真正開始。