gipi的學習筆記-經營管理、數據思考、終身學習

在專案控管時我相信大家都會展WBS(Work Breakdown Structure)，WBS在專案管理裡已經是根本中的根本，WBS展的好不好，某種程度已經先決定了你專案做的對不對，有沒有遺漏或多做？也就是所謂的範疇(Scope)是否有誤，而透過對每個工作項的時間預估與資源分配，也能讓你能一睹專案的全貌，更加清楚你完成了多少工作，還剩下多少工作。

在日常管理中，我們也會要求同仁將手邊的工作做拆解，當你將你的工作拆的愈細，你對自己工作的把握度就愈高，你對你該做的事情就愈清楚，以下是一個我曾經看過的專案規劃案例：


我相信很多人可能都看過這樣的專案內容，他將開發一個系統所需的主要階段大致上都列了上去，貌似沒有什麼問題，但看了這份規劃後我們不禁想要問以下問題：
1.需求收集可以跟撰寫規格書同時進行嗎？
2.我們有多少支規格、多少支程式要寫要測試？
3.誰負責哪支規格、哪支程式的撰寫？
4.每一份規格、每一支程式所需的時間分別是多少？
5.規格與規格間是否有先後順序？
6.規格是否有全部開完才能進行程式撰寫？
7.測試一定要等全部的程式開發完才能做嗎？
8.測試完如果發現bug，沒有任何緩衝時間嗎？
9.如果規格發生問題，我要找gipi,Jimmy,91,Dotjum哪一位？同樣的問題在程式設計、測試上都會有。
10.你怎麼讓我知道規格撰寫的進度？同樣的問題在需求收集、程式設計、測試等都會有。
11.每個人身上負載量有多少？
……

這樣的一份專案規劃讓人看了徒增疑問，你不能說它不是專案規劃，但它只是一個高階的專案規劃，比較像是專案階段，而不像專案規劃，我們應該讓一份專案規劃能盡量明確，讓自己跟專案成員都能透過這份規劃一目了然目前專案的狀況，所以一般我們會要求在做專案規劃時要留意以下這幾項：
1.要標示清楚前後相依，讓大家知道在做B之前A要先被完成，這部份透過前置工作可以做到
2.能細部分解就要細部分解，一個15天的工作，應盡量拆解到每個項目都在1天或以下(個人習慣)，也就是一個15天的工作項，是由15個以上的子工作項加總而成，好處是展的愈細時，你可以回過頭來問自己：完成這15項是不是就完成這個大項工作了？如果是那就代表你想的挺清楚了，如果不是，那代表你還要再思考

到這邊，我們可能已經將專案規劃展成下面這個樣子，將需求收集的程序定義清楚，將規格分成SA/SD，並將要撰寫的規格項次與該規格的負責人員指派上去，有些工作有前後相依性的也要設定前置任務(Predecessors)。


3.展細之後，把該工作的實際負責人填進去，切記要留意資源的使用狀況，不要有些人一天分配到16小時，而另一人才2小時，這部份我們可以透過資源使用狀況來檢視資源是否過度被使用，你可以使用Project內建的資源撫平工具或者進行手動撫平，習慣上我是用手動撫平，而這個我故意弄出來的資源過載我只要調整一下資源使用就可以排除：


如下圖，其實只是將界定需求來源以及界定訪談主題這兩項的資源使用率調整成50%，其實這項工作各自只要花gipi 50%的時間：


4.要預估所有的工作內容，而不要僅規劃開發的工作，行政類的工作也要預估進去
5,一定要給專案留點buffer

當你將例行工作的會議與重工的工作也加入你的排程中，就比較能真實反應你的真實資源使用狀況，很多時候我們會看到我們幫成員安排了8小時的工作，但卻花了他4個小時的時間開會，然後他還沒有地方可以報工，因此這4個小時對他來說是沒有產值的，因為專案上是沒有記錄的，而他本來8個小時的工作還是要完成，這就造成加班的產生，所以當你將這些非開發類的工作也排定進去後，你就要再次做資源的撫平，那你的專案預估就會更加精準了。


有了這樣的專案規劃，你就能比較精確的知道每一項工作完成後你的專案完成率是多少，例如當我們完成了模組A的SA/SD規格後，整體進度達成了15%，再輔以SPI/CPI，你就能大致掌控你的專案狀況了。


從上面這個案例，我們大致上可以看到展WBS可以讓我們對於專案的工作更加的清晰，時程的預估可以讓我們對我們的交期更有底，資源使用狀況可以讓我們更清楚我們手上有多少本錢以及資源是否做最有效率的運用，專案管理工具可以幫到我們很多，但根本的觀念我們還是要清楚，才不會讓專案老是失控，以上簡單案例跟大家分享。

PS.以上的專案僅供參考，我最後並沒有完全撫平。

游舒帆 (gipi) 探索原力Co-founder，曾任TutorABC協理與鼎新電腦總監，並曾獲選兩屆微軟最有價值專家 ( MVP )，離開職場後創辦探索原力，致力於協助青少年培養面對未來的能力。認為教育與組織育才其實息息相關，都是在為未來儲備能量，2018年起成立為期一年的專題課程《職涯躍升的關鍵24堂課》，為培養台灣未來的領袖而努力。