一個正常的專案，專案經理人對專案成員的能力與負荷的了解，理應瞭如指掌才對，最起碼也該知道成員所具備的能力是否足以承擔此一任務。在國外，PM會透過各種可能的管道，對成員進行多方面的了解，成了專業的能力以外，手頭上的工作負荷、工作的態度及以前的一些工作記錄等等，都會想辦法了解的越多越好，因為這些都足以左右專案的成敗。
遺憾的是國內的PM從來就不認為有此需要，經營者也沒有這樣的意識，結果一個蘿蔔一個坑的思維，總以為有一堆的人在一起做一件事，就是Team work了，殊不知這之間的差異，直有天壤之別。不重視這些客觀因素的結果，專案只有推遲，別無他途。
當WBS展開後，PM必須實施能力盤點，了解每個成員的能力與可用工時。沒有這些數據，任務分配將無法客觀對待，只是一種很膚淺的齊頭式分派工作。加上中國人在接受任務時，從來就不會據理以爭，總抱持著凡事盡力而為就是了，一旦碰到問題時，也只是兩手一攤，事不關己，如此專案管理，如何讓人放心。
個人與日本人接觸時間很長，也與美國人共事過，在日本，當工作分配超過個人的工時負荷量時，成員會拿著數據去跟主管討論，工時不夠了；美國人是在分配工作時，會斤斤計較任務量的多寡，但一旦決定後，就不再吵了；相對的咱們中國人是事前不吵，事後吵鬧不斷，結果推、拖、拉反成了常態，實在不是正常的專案管理模式。
那要如何分配任務呢？可以作一簡單的矩陣表來處理。矩陣表的縱軸為工作項目(Task)，橫軸為專案成員名單(Members)，交叉相關的格子可以以一斜線劃開，將格子分成兩個部分。格子的上方填入預備投入的工時，下方記載成員在這個工作的定位。定位一般分成四類，其分別為：1代表這個工作的主擔當者，換句話說就是這個部分的Sub負責人；2代表支援，也就是共同負責或是備份的資源；3代表沒有參與此一工作，但必須被知會這個工作的一切訊息。這代表與此一工作有一些上下游或是任務上的關聯；沒有任何符號的代表沒有相關。以下就簡單做個表格說明：
Resources & Responsibility
Members
Task
A
B C
D E
F G Total
報表定義 1/1
1/2 2/2
/3 /3
4
程式設計
15/1
3/2 2/2
/3
/3 20
------------------------------------------------------------------------------------------------------
依照上面這個表來說明，有兩個工作，一為報表定義，另一為程式設計。報表定義由成員A主擔當，成員B與D為副擔當，F與G必須被告知，總共需要的工時為4天。程式設計部分主要由A君負責，B與C為副擔當，F與G必須被照會，總共需要20天的工時。如此全部分配完任務後，每位成員的負荷量是否適當，則可以再作一全面性的檢驗。務必把每個人的工時分配的恰得其份。
要把R&R做好，前提條件是有客觀的工時評估數據，與每個成員的能力與負荷的掌握。特別是後者，如果能力掌握度不夠，不只會耽擱個人的業務，也會影響到其他相關的作業，必須審慎為之。很多PM會困惑如何去掌握成員的能力，這除了與成員面談外，向成員的直接主管請教，常是最有效的方法。因為主管對部屬的能力與負荷最了解不過了，再說分配資源給專案，主管也必須負擔某些責任的，所以功能主管將是專案主管的最佳內部顧問。
下期我們將來談談甘特圖。
沒有留言:
張貼留言