＊、Function Team
基本上就是組織上的部門，每個部門有專門負責的功能工作。除非組織有變動改組，不然組織部門是常態性的存在，一般工程師都稱呼部門的主管為老闆。
＊、Project Team
依任務需求而成立的，不是常態性的，而且具有時效性，一旦project結束就解散。Project Ｔeam的成員是依任務需求從Function Team徵調組成的，在project期間工程師是要對Project Leader負責的。
這樣的二維管理方式，分工上其實也是滿明確的：
＊、Function Team
Ａ、培養加深專業能力
專業領域的能力是必備的，Function Team Leader需要讓負責的領域都有專業的負責人在處理，最好是達到專家的等級。
原有的領域已經掌握之後，可以再擴張學習其他的相關領域。
Ｂ、人力支援Project Team
Project Team的需求是動態的，常常多個project同時在跑，也可能project在不同的階段會需要不同能力的人，Function Team Leader需要很了解所有project的需求，協調分配部門人力來滿足所有的project
＊、Project Team
Ａ、明確的人力需求
既然Project Team的人員組成來自於Function Team，Project Leader在提人力需求時，有義務清楚告知Function Team需要人力的數量、能力和時間。不過Project Leader常常因為不是該領域的專家，並無法評估出要完成任務需要的精確人力的數量、能力和時間，評估的工作一般還是需要由Function Team來負責。
Project Leader需要針對所有Function Team的工作評估做最佳化處理，也就是排出消除了人力、時間和資源之前的相依性和衝突性問題的project schedule，這樣才能跟Function Team提出精準的人力需求。
Ｂ、如期完成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人力需要的原因很多，常見的幾個是：
Ａ、人力真的不足
可能人員流失或project的需求太大，一下子無法滿足project的需求。
Ｂ、人力被其他project卡住
因為其他project delay，人力被卡住。
Ｃ、人力的能力還不到位
可能是新人或可能是新的技術領域，人的能力還不足以勝任。
如果是人力真的不足，不管是找人或是從其他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或工程師，交錯的二維管理也可以清楚明白，有所適從了。
沒有留言:
張貼留言