如果沒有WBS，我們怎麼管專案進度?

這是最近遇到，關於專案的腦筋急轉彎。當開發團隊不願公布詳細的工作項目與時程規劃，身為PM的你要如何確保專案進度呢?難道只能當專案接近尾聲的時候，才知道專案能不能如期完成嗎?

為什麼要列WBS

這就回到列WBS的目的，在瀑布式開發中，專案的一開始，開發人員依照需求內容，展開WBS，並列出各項工作的工作天數與整個專案預計完成的時程。在列出工作項目與工時的同時，也會思考工作的細節，以及有沒有需要先解決的問題。
當交出定版的WBS，PM就依照WBS所列的時程，定期檢視工作項目的完成狀況，藉以判斷專案的狀態。這種做法對於PM跟客戶而言，看似是非常有安全感的做法，能知道完成工項的百分比，似乎就能確保專案如期完成對吧?

WBS真的完美嗎?

隨著專案的推進，有時初期評估可能想的過於美好，或者對於領域知識或開發技術不夠了解，到了開發過程的中期或後期，才發現漏估了工作項目、某些項目花費的時間超乎預期，或者有突發事件或臨時加入的工作，以至於專案有無法如期完成的風險。為了如期完成專案，團隊會選擇加班趕工，在趕工狀態下，產出的品質可能被犧牲，人員因長時間工作而專注力下降，即使產品如期交付，品質往往會大打折扣，留下技術債 ，導致後續要花費更多的時間處理系統問題或重構，若再接到新的需求，變更也相當困難。
展開WBS讓開發人員先思考要做的工作項目，或許是件好事；但緊緊守住WBS跟一開始預估的時程，以「約定」做為專案如期完成的唯一保命符，對軟體開發專案真的是一件好事嗎?

將工作項目標上大小或點數

讓我們回到一開始提到的腦筋急轉彎。假設開發團隊不願提供WBS與各工作項目的時程，你仍可問一個問題:我們有多少工作項目要完成?
開發團隊可能會跟你說:很難講，要給你工作項目的數量可以，但事情有大有小，我也說不準。於是你請開發團隊將工作項目標上大小，再重新計算一下。於是開發團隊可能會回答你:

預計有10項小工作、20項中等工作、2項超大工作要完成

從這樣的回答，可以再繼續追問:一項中等工作大概是幾倍的小工作呢?

嗯...小工作大概就半天到一天可以做完，中等工作大概2~3天吧。超大工作我現在還不知道，感覺很難要研究一下

於是你讓開發團隊研究了兩天有關於超大工作的項目，他們重新給出了一個回答。

超大工作目前可以分為10個中等工作，先這樣吧，不知道後面還有什麼問題

於是你將小工作設為1點，中工作設為2點，超大工作設為25點。此時你大概知道整個專案大概有100個工作點，如果依照開發人員的回答，每一個小工作(1點)、一個人大概1天完成的話，現在團隊有3個開發人員，整個專案大概會一個月後會完成。不過，還是有一些說不準的地方。

觀察工作事項的增減

接著，你每周問每個開發人員兩個問題、做一件事:

1. 這周完成了幾件大中小事?
2. 有沒有發現新的要解決或處理的事?以及事件的大小
3. 請開發人員向你展示本周的開發成果

於是你發現，即使每個開發人員開發速度有些差異，幾周下來，似乎可以求出團隊的開發速度，即使沒有WBS跟預先列好的時程，你也能掌握專案進度。明天，讓我們用圖解釋，如何顯示與計算團隊完成的速度。

參考資料
1.[專案管理]如何展開WBS、排定時程與規劃資源？
https://dotblogs.com.tw/jimmyyu/2012/05/05/how-to-creating-wbs-scheduling-planning
2.敏捷系列 | 我該如何選擇瀑布式開發或敏捷式開發？--WBS用途
https://medium.com/alexchanglife/waterfall-agile-cf3567cf90b1