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

這是靈活開發團隊管理系列的第八篇（​​團隊管理欄目目錄​​）。

還是靈活開發一千零一問的第二十八篇（​​在這裡提問​​​，​​之一​​​，​​之二​​​，​​之三​​​，​​問題總目錄​​）。

還是靈活開發松結對程式設計系列的第十三篇（​​松結對程式設計欄目目錄​​​），與之前系列​​第六篇139團隊​​​、​​第九篇​​微軟TechED上的講座有密切關系。

問題

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

如果作為一個團隊管理，人數會太多；分解為多個項目，協調又麻煩，如何處理？

分析與方案

這個問題很難有普遍适應的方法來處理，我結合之前自己做過的項目來說說。

由于大型團隊很難見到太成功複制的，是以不要嘗試簡單對号入座，請了解背後的管理理念。

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

這個壞處好了解，不多說了。

實際上，即使在10人左右的團隊，若組長仍然自己要做技術工作的，都可能形成無人管理的團隊。

由于缺少溝通、互助，外加人員工作量配置設定很難均衡，常常因為個體的進度和品質耽誤整體的進度和品質。

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

這個很容易讓小組形成自己的“利益”，比如如果大組想臨時抽調一些人出來，小組長會不同意。日後工作會越來越難以開展。

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

大家一定看得出來，1和2很難操作，很難把握“度”，但我們當年的确做到過。

實際上當年我們最容易互相“臨時調動”的，居然是小組長，就是臨時讓小組長幫别的組做點事情。

一方面，由于這些人都是高手，别的組一般都特别歡迎；另一方面，各小組長對自己的工作内容一般都有點“厭倦”了，他們對别的小組的工作興趣大于普通的組員。

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

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

3. 核心會議

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

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

其實這種會議經常是“擴大會議”，取決于最近在幹什麼。

4. 開放辦公室

千萬不要因為小組分好了，還有核心會議可以溝通，就可以讓大家分開坐了！

雖然我們從來沒有嘗試過把大團隊從坐在一起改為分開坐，看看會發生什麼（因為不敢，呵呵），但我們嘗試過讓大團隊坐在一個開放空間（即使有隔斷，也要寬松點，不要搞院牆），還嘗試過把分開的團隊改為坐在一起。後兩者的效果都很好。

一個意外的收獲是，坐在一起的團隊關系會很好維護，在提供或尋求幫助的時候，人們更願意與一些天天在一起工作、吃飯的人交流，而不願意僅僅因為技術或業務的需要與陌生人合作。

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

别人的經驗距離自己的實踐總是很有距離，這個距離中間還阻擋着很多障礙。在真正嘗試前，這些困難常常顯得不可跨越。

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

是以，不要被現在看到的難題吓倒。

如果您有任何補充問題，請在下面評論中補充，我會重新編輯或增加要點。謝謝參與。

​