敏捷開發團隊管理系列之七：大型研發管理團隊的切分（二）

 

問題

大體問題：若人數在30人左右開發一個產品，裏邊的子系統數量比較多，每一個子系統都有各自的發佈計劃，而又要協調。

若是做爲一個團隊管理，人數會太多；分解爲多個項目，協調又麻煩，如何處理？

分析與方案

這個問題很難有廣泛適應的方法來處理，我結合以前本身作過的項目來講說。

因爲大型團隊很難見到太成功複製的，因此不要嘗試簡單對號入座，請理解背後的管理理念。

 

1. 不要作太大型的單一團隊

這個壞處好理解，很少說了。

實際上，即便在10人左右的團隊，若組長仍然本身要作技術工做的，均可能造成無人管理的團隊。

因爲缺乏溝通、互助，外加人員工做量分配很難均衡，經常由於個體的進度和質量耽誤總體的進度和質量。

2. 不要行政性地分解團隊

這個很容易讓小組造成本身的「利益」，好比若是大組想臨時抽調一些人出來，小組長會不一樣意。往後工做會愈來愈難以開展。

比較好的作法是技術和小組管理上讓小組長負責起來，但大組長仍然要保留對小組關於的權利，且要習慣性地讓某些程序員臨時調動一下工做。

你們必定看得出來，1和2很難操做，很難把握「度」，但咱們當年的確作到過。

 

實際上當年咱們最容易互相「臨時調動」的，竟然是小組長，就是臨時讓小組長幫別的組作點事情。

一方面，因爲這些人都是高手，別的組通常都特別歡迎；另外一方面，各小組長對本身的工做內容通常都有點「厭倦」了，他們對別的小組的工做興趣大於普通的組員。

這些常常能幫助其餘組的人在整個團隊中的地位很高，即便發給他們很高的薪水，別人也不會嫉妒（由於他們也從幫助中受益了）。

這算是一種很強的激勵和績效管理方法，也會吸引別的小組長加入。

3. 核心會議

大組長+小組長要常常協調開會，咱們當年是25～32我的的組，每週一次會議。

最開始只有4我的參加，後來擴展到8我的，包括了2個非小組長但也是研發骨幹的。

其實這種會議常常是「擴大會議」，取決於最近在幹什麼。

4. 開放辦公室

千萬不要由於小組分好了，還有核心會議能夠溝通，就可讓你們分開坐了！

雖然咱們歷來沒有嘗試過把大團隊從坐在一塊兒改成分開坐，看看會發生什麼（由於不敢，呵呵），但咱們嘗試過讓大團隊坐在一個開放空間（即便有隔斷，也要寬鬆點，不要搞院牆），還嘗試過把分開的團隊改成坐在一塊兒。後二者的效果都很好。

一個意外的收穫是，坐在一塊兒的團隊關係會很好維護，在提供或尋求幫助的時候，人們更願意與一些每天在一塊兒工做、吃飯的人交流，而不肯意僅僅由於技術或業務的須要與陌生人合做。

 

不過，不管如何，大型團隊的管理都很困難，雖然有些方法至關有效（好比上面介紹的方法，我都親眼見證其效果），但作起來又很難。

別人的經驗距離本身的實踐老是頗有距離，這個距離中間還阻擋着不少障礙。在真正嘗試前，這些困難經常顯得不可跨越。

不過正是由於如此，管理纔是一個值得探討的話題，成功的管理者也才變成受人尊敬和推崇的人。

因此，不要被如今看到的難題嚇倒。

若是您有任何補充問題，請在下面評論中補充，我會從新編輯或增長要點。謝謝參與。