[項目管理]如何展開WBS、排定時程與規劃資源?
04-28
在項目控管時我相信大家都會展WBS(WorkBreakdown 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.以上的項目僅供參考,我最後並沒有完全撫平。推薦閱讀:
※各種評價報告內容
※PM06|乾貨:PMP基礎知識培訓課件PPT(上)
※測試不是對抗而是一劑預防針 - 我們一起學項目管理 (三十七)
※【項目管理應用】如何通過項目管理方式在碎片化移動互聯網時代做到真正有效的系統學習!
※專題 | 項目管理知識、方法論、工具NO.9:你應該知道的項目管理的五個過程組和九大知識領域
TAG:項目管理 |