最近參加了幾個同事帶領的專案，發現有個普遍現象就是 PM 直接跳下去開始用 excel 排程工作，寫得很詳細，時間也 okay。但專案進行到後期，發現有很多重要工作漏掉。追溯到原頭，發現他們沒有先去思考這個專案該完成什麼東西，也沒找利害關係人討論。導致這些案子後期有很多要拼命追趕的任務，有的重要交付物甚至在結案之後都沒完成，只能當結案後待辦事項。這些現象的通病其實就是沒有在專案一開頭做好範疇管理的工作分解結構 WBS。

WBS 是個系統化的工具，藉由階層式圖表的呈現，將龐大模糊的專案拆解成一個個具體的小項目。這份資料需在專案初期規劃階段就該製作，協助團隊與利害關係人釐清專案該完成的交付物，並以文件化，讓整個專案在初期就有清楚全貌。
 

使用這工具有什麼好處?

1. 讓團隊跟利害關係人在專案該交付的成果取得共識

初期規劃最怕就是漏東漏西。但有這個工具的輔助，團隊可在早期就辨識出該做的東西。因為有文件化，就能跟利害關係人取得共識，降低模糊地帶。避免專案做到最後，客戶抱怨怎麼這個漏，那個也漏，甚至衍生訴訟衝突，降低客戶對專案成果滿意度。

2. 團隊知道應該要專注在什麼工作上，減少不必要的浪費

這份文件可以幫助團隊知道什麼工作該做，什麼工作不需要也不該做，使團隊專注在最重要的交付物上。隨著專案進行，WBS 資料也會滾動式調整，新增以前未知，專案進行到一半才新發現要補上工作；或是刪減掉團隊或客戶決議不執行的項目，避免浪費資源做出客戶不需要的東西。

3. 可重複利用增加下次類似專案的成功率

文件若有完整的留下來，往後進行類似的專案，可重複再利用。這不僅能減少學習曲線，也可幫助專案時程與成本評估更加精準，專案成功機率會大幅提高，客戶滿意度也會提高。經驗傳承給其他專案團隊也相較容易很多。

該如何使用這個工具來規劃? 我建議可以從三種角度來拆解

1. 從產品的組成分解

這常用在新產品開發。一個產品通常是由幾個系統組成，每個系統由好幾個零件組成。舉個例子，最基本的腳踏車是由五個系統組成: 車架、轉向系統、傳動系統、煞車系統、車輪系統。每個系統可能是個幾個子系統或是零件組成。依據這個邏輯就可將想開發的產品，逐步拆解到最底層一個個可以拿來規劃工作任務的品項。
 

2. 從專案階段分解

在有嚴謹開發流程的公司，通常會將開放流程分切成好幾個階段。每個階段都有其定義跟該完成交付的成果及文件。像我司就把產品開發分成五個階段：產品功能設定與商業評估、設計與驗證、量產測試、發表行銷與結案。

團隊可以用階段的角度來拆解專案的 WBS，在每個階段分支列表出該階段需要交付的成果。
 

3. 從部門組成分解

比較大的專案通常也會是跨部門專案。常見的是各部門指派人來支援而形成臨時專案團隊。每個組員負責跟自己所屬部門功能有關聯的專案工作。所以專案的 WBS 就可以根據部門功能性去拆解，列出各部門需要完成的交付物。這樣列表有個好處，可讓團隊依據他們的專業經驗去檢視 WBS 是否有漏缺。
 

以上是我常用的 WBS 拆解策略。依據專案的屬性，也可以混搭使用。只要拆解出來的東西有辦法讓團隊跟利害關係人看懂取得共識，讓排程規畫可以順利往下推進，就沒什麼問題了。

原文轉貼自：Kieren Chen（原文連結）