2012年11月5日

二維管理可以很簡單

我想大部份的公司都是如上圖的二維管理方式:
*、Function Team
  基本上就是組織上的部門,每個部門有專門負責的功能工作。除非組織有變動改組,不然組織部門是常態性的存在,一般工程師都稱呼部門的主管為老闆。
*、Project Team
  依任務需求而成立的,不是常態性的,而且具有時效性,一旦project結束就解散。Project Team的成員是依任務需求從Function Team徵調組成的,在project期間工程師是要對Project Leader負責的。



這樣的二維管理方式,分工上其實也是滿明確的:
*、Function Team
 A、培養加深專業能力
   專業領域的能力是必備的,Function Team Leader需要讓負責的領域都有專業的負責人在處理,最好是達到專家的等級。
   原有的領域已經掌握之後,可以再擴張學習其他的相關領域。

 B、人力支援Project Team
   Project Team的需求是動態的,常常多個project同時在跑,也可能project在不同的階段會需要不同能力的人,Function Team Leader需要很了解所有project的需求,協調分配部門人力來滿足所有的project

*、Project Team
 A、明確的人力需求
   既然Project Team的人員組成來自於Function Team,Project Leader在提人力需求時,有義務清楚告知Function Team需要人力的數量、能力和時間。不過Project Leader常常因為不是該領域的專家,並無法評估出要完成任務需要的精確人力的數量、能力和時間,評估的工作一般還是需要由Function Team來負責。
   
   Project Leader需要針對所有Function Team的工作評估做最佳化處理,也就是排出消除了人力、時間和資源之前的相依性和衝突性問題的project schedule,這樣才能跟Function Team提出精準的人力需求。

 B、如期完成project
   這是考驗Project Leader和PM的執行力了,一旦schedule delay,人力就無法如期釋放出來,也將打亂Function Team的人力分配,進而也影響其他有人力需求的project。

分工是明確的,不過二維管理的問題也往往出現在分工的執行上面:
*、考績誰打?
  一般大家對Function Team Leader也就是部門主管打考績不會有什麼意見,不過常常被忽略的是Project Leader也應該對Project Team的成員打考績。其實這是基本的權責問題,如果Project Leader沒有影響工程師考績的權力,他要如何叫得動工程師做project的事情?工程師是不是可能只做老闆交代的事,而不甩Project Leader?
  至於Function Team和Project Team的考績比例問題,可以簡單的依時間比例或重要性做加權處理。

*、Project Team要不到人或適合的人
  這是project最常遇到,也是最大的衝突問題--人力衝突。
  Function Team無法滿足Project Team人力需要的原因很多,常見的幾個是:
  A、人力真的不足
    可能人員流失或project的需求太大,一下子無法滿足project的需求。
  B、人力被其他project卡住
    因為其他project delay,人力被卡住。
  C、人力的能力還不到位
    可能是新人或可能是新的技術領域,人的能力還不足以勝任。
  
  如果是人力真的不足,不管是找人或是從其他team借調,都可能會有能力不足的問題。
  
  如果是能力不足的問題,往往只能邊做邊學,只是project要注意把學習的時間加入project schedule,讓工程師有學習的空間和時間,才不會最後做出不一樣的東西,也才不會導致schedule誤差太大。

  如果是人力的衝突,那往往需要有衝突的project team出來比大小了,看誰的priority高,誰就能優先使用。

  分析project的狀況,常常也可以了解人力的需求程度,例如前十大bug數最多的功能或是前十大需求功能的人力等,Function Team Leader可以依據這些資訊了解哪些功能需要較多的人力,並且提早做好規劃或衝突時的應變處理方式。

*、Project的排擠效應
  所謂的排擠效應就是有一個最高priority的project佔用了太多太久的人力資源,導致其他project一直要不到人,造成其他project delay、pending、或啟動不了的情況。
  
  最高priority的project往往真的有其重要性和急迫性,只是當該project執行不當,造成delay時,影響程度也最大,所付出的成本不只是project本身delay的成本,還有其他project因此受波及的成本。

  一旦公司出現project排擠效應,影響層面往往會快速擴大,因為最高priority的project delay會更受重視,最常用的做法往往是投入愈多的人,而吸引更多人力資源的結果,常常是沒有加快該project,反而讓其他的project更難執行。

*、Project delay是誰的責任?
  這不是單純只有哪一邊的責任,而是共同的責任,只不過Project Team Leader責任要大一點而已。

  Project delay是人力無法釋放最重要的原因,從上面project排擠效應知道影響的當然包含Project Team和Function Team。而且Project Team成員組成來自Function Team,人力的協調需要Function Team的介入,所以Function Team Leader有責任要和Project Leader一起解決delay的問題。

  既然是二維管理,本來說交錯在一起了,榮辱與共,沒有哪一方可以指責哪一方的問題。

*、誰權力比較大?
  除了像上面比責任,也常出現的問題是比權力。
  工程師常常最怕的是同時有好多人可以對他下指令,每個都是老闆,每個老闆都有事交代他要做,當做得來就還好,做不來時往往就是看哪個老闆的拳頭大了。有些工程師會同時參與多個project,光會叫他做事的Project Leader就好幾個,再加上組織上的Function Team Leader,那真是會多頭馬車,無所適從。
  
  權力應該事先協調好,老闆們要自己先達成共識,工程師什麼時間點應該聽誰的,不應該為了自己方便而刻意存在模糊地帶,明確的界定權力才是方便做事的正當方法。


只要有權有責,權責分明,不管你是Function Team Leader、Project Leader或工程師,交錯的二維管理也可以清楚明白,有所適從了。

沒有留言:

張貼留言