如何避免專案超時的詛咒? 我的Scope Creep應對之道

Scope Creep : 由於產品目標不夠明確，導致無限的需求延伸

對於我撰寫的內容中提到的相關術語，我並不想要把網路上隨處都查得到的定義照抄過來，而是用我自己的邏輯進行思考後，得出我自己對於它們的理解。

"做我們這樣較小規模公司的專案，跟做其他大規模的公司企業的專案，你覺得哪個比較累?" 

在受邀參與客戶的尾牙場合上，坐在我隔壁的客戶老闆，抱著好奇的想法詢問我。

"你們家的比較累，三天兩頭就在那邊有新需求，不然就是朝令夕改，今天的說法打臉昨天的說法"

腦海中瞬間出現了 這句話，想當然耳也只是心想而已，要是真說出來還不得提頭來見。把各有需要注意的地方及都是不一樣的挑戰...等這些社交辭令使用完之後，我就順勢把話題轉去其他主題了。

但仔細想想，為什麼在專案的執行過程中，會一直蹦出似乎永無止盡的需求? Agile(敏捷開發)就算了，本來在迭代過程中不斷的去試錯來去蕪存菁；但在大部份Predictive(瀑布式開發)的專案，明明在當初作為合約報價依據的WBS都逐條細項列出，還是逃不了這個命運。

帶著這個疑問，我思考了些許時間，統整出在我的視角上，發現的幾個問題。

對產品/專案目標(Goal)的不明確，導致提出的新需求無法達成目標

怎麼說呢? 以我本身的其一專案為例，在一開始的Presale過程中我尚未參與該專案，但聽聞其他同專案的同事所述，在討論的過程中，業主想要開發一套"訂閱制"的專案管理APP，除了"自家公司可以使用"之外，還可以對外銷售，乍聽之下是個不錯的想法，但問題隨之而來。「Generalize vs Specialize , Which is rather important ?」在一開始的專案Planning階段，其實就必須協助業主明確定出該產品的北極星，也就是產品的方向。

若想做訂閱制，那功能及流程就得偏向大眾且普遍的使用習慣；但又想要自家公司可以使用，不免俗的就會有特規的想法與使用流程，造成衝突。若在一開始就決定好產品的重點方向，那在需求訪談的過程中，便會更加順遂。

例如："訂閱制"為重點，那在圖庫的分類層數設計上，我們便能馬上得出"市面上大多數類似產品APP都是採三層分類"的結論，而不是陪著Stakeholders們的"想要五層，原因是他們公司都是習慣這樣子用"這種想法打轉，甚至還需要花幾天做簡報來說服。

WBS的功能描述說明不夠明確，導致後來的需求各說各話

在發生問題的過程中，我回頭看這個專案的合約、WBS文件，發現這些功能項目在當初報價時，描述的非常模稜兩可。導致在需求訪談時同樣的功能，我們對於該功能理解的方式(We can)與他們理解的方式(They want)有所落差。

例如：部門設定作業，在WBS上僅寫"簡單的部門設定作業"，那簡單是到多簡單? 使用者能自行新增部門嗎? 部門之間有關聯嗎? 需要有部門的查詢嗎?...等，失之毫釐差之千里。

確立產品目標方向與精確描述功能是避免 Scope Creep 的重要環節

明確的產品目標方向能幫助我們在需求訪談時更有重點，避免無謂的發散；而詳細的功能描述則能確保我們與客戶對於需求的理解一致，減少後續的爭議與反覆。

更重要的是，做好這兩件事，我們便能在永無止盡的新需求中，清楚辨別哪些是必須完成的、哪些則可暫緩或拒絕，才能將寶貴的資源投入在真正重要的事情上。以上是我在專案管理上的一些心得分享，這些都是我在工作中實際體悟的點滴，希望能給大家帶來一些啟發。