*、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或工程師,交錯的二維管理也可以清楚明白,有所適從了。
沒有留言:
張貼留言