需求變更照單全收

按照之前我們提到的專案管理金三角，只要時間、成本、允收條件一確定，就圈出了固定的範疇。專案只要圍繞在這固定的範疇，需求訪談不超過範疇邊界，開發的時候不鍍金，也沒有額外的需求變更，在沒有其他不可抗力的風險因素下，基本上都能如期、如質、如預算的完成專案。

【壞專案】
某PM屬於好好先生型的性格，只要遇到衝突場面，總是喜歡扮演委曲求全的和事佬。所以不同單位提出的需求有衝突時，PM就想盡辦法將大家的需求都納入，即使有些需求已經超出範疇。然後規格書簽定後，需求單位因為遺漏了一些功能，要求更改規格書。PM又在沒有與開發單位溝通的情況下，答應了變更需求。由於沒有需求變更計畫，是否變更完全由PM說了算，但PM通常又照單全收，於是專案變成一個看似永無止盡的專案，從Phase1做到Phase11都還沒做完就要EOS(End of Service)了。

【好專案】
某PM屬於公事公辦型的性格，在專案初始，就制定了詳細的範疇管理辦法，裡面當然也包含了需求變更管理流程。在需求訪談之初，PM就提醒規格書最終核定日期，並且聲明各單位簽核通過之後，任何一點變動都須走需求變更管理流程。流程中包含了各單位直屬長官的參加，向所有單位報告為何需要變更需求，變更所帶來的衝擊有多大。因此，所有單位的需求提出者，都戰戰兢兢的在規格書核定日前，將需求盤整清楚。若是真的有簽定後才新增的需求，需求單位會因為不想走繁瑣的需求變更管理流程，而選擇將新需求放置到系統上線之後再新增。專案團隊至始至終都在固定的範疇下努力，大家目標一致心理安定，過程中較少出現爭執的場面。

【點評】
專案範疇潛變(Scope Creep)是專案delay的一大殺手，我們幾乎可以說，只要管理好範疇，已經成功了80%。需求的大小，就是工作量的大小。有時候需求單位所謂的「一個小小功能」，所需要的工作可能就是額外多1個月。身為一名PM，應該要成為需求單位與開發單位的溝通橋樑，拉齊雙方對於一個功能所需花費的時間共識。大家針對各自所需目的，來權衡出一個大家都滿意的規格。若是PM為了當好好先生，導致接了一大堆範疇外的工作，讓開發團隊天天死亡行軍(加班)。好一點是破壞PM與開發團隊的信任，壞一點則可能是重要技術Key man離職，直接導致專案無法執行。

達成共識最好的辦法就是一開始就明訂規則，然後讓大家都參與規則的制定，有參與的人會有比較高的意願遵守規則。有規矩就能成方圓，大家按照計畫走，就能一起開開心心、順順利利的完成專案。

※PM_Coach目標:以成為「專案管理達人」為志業
歡迎加入Line社群(可匿名)討論專案管理
https://line.me/ti/g2/PaE0x_gPBuzIReP982aWwSphbpjx81Zw-LMlWg?utm_source=invitation&utm_medium=link_copy&utm_campaign=default
可掃QR code如下