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

這是敏捷Team Dev管理系列的第八篇（團隊管理欄目目錄）。

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

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

問題大致問題：若人數在30人左右開發一個產品，裡邊的子系統數量比較多，每個子系統都有各自的發布計劃，而又要協調。如果作為一個團隊管理，人數會太多；分解為多重專案，協調又麻煩，如何處理？分析與方案這個問題很難有普遍適應的方法來處理，我結合之前自己做過的項目來說說。 由於大型團隊很難見到太成功複製的，所以不要嘗試簡單對號入座，請理解背後的管理理念。1. 不要做太大型的單一團隊這個壞處好理解，不多說了。實際上，即使在10人左右的團隊，若組長仍然自己要做技術工作的，都可能形成無人管理的團隊。由於缺少溝通、互助，外加人員工作量分配很難均衡，常常因為個體的進度和品質耽誤整體的進度和品質。2. 不要行政性地分解團隊這個很容易讓小組形成自己的“利益”，比如如果大組想臨時抽調一些人出來，小組長會不同意。日後工作會越來越難以開展。比較好的做法是技術和小組管理上讓小組長負責起來，但大組長仍然要保留對小組關於的權利，且要習慣性地讓某些程式員臨時調動一下工作。大家一定看得出來，1和2很難操作，很難把握“度”，但我們當年的確做到過。實際上當年我們最容易互相“臨時調動”的，居然是小組長，就是臨時讓小組長幫別的組做點事情。一方面，由於這些人都是高手，別的組一般都特別歡迎；另一方面，各小組長對自己的工作內容一般都有點“厭倦”了，他們對別的小組的工作興趣大於普通的組員。這些經常能協助其他組的人在整個團隊中的地位很高，即使發給他們很高的薪水，別人也不會嫉妒（因為他們也從協助中受益了）。這算是一種很強的激勵和績效管理方法，也會吸引別的小組長加入。3. 核心會議大組長+小組長要經常協調開會，我們當年是25～32個人的組，每周一次會議。最開始只有4個人蔘加，後來擴充到8個人，包括了2個非小組長但也是研發骨乾的。其實這種會議經常是“擴大會議”，取決於最近在幹什麼。4. 開放辦公室千萬不要因為小組分好了，還有核心會議可以溝通，就可以讓大家分開坐了！雖然我們從來沒有嘗試過把大團隊從坐在一起改為分開坐，看看會發生什麼（因為不敢，呵呵），但我們嘗試過讓大團隊坐在一個開放空間（即使有隔斷，也要寬鬆點，不要搞院牆），還嘗試過把分開的團隊改為坐在一起。後兩者的效果都很好。一個意外的收穫是，坐在一起的團隊關係會很好維護，在提供或尋求協助的時候，人們更願意與一些天天在一起工作、吃飯的人交流，而不願意僅僅因為技術或業務的需要與陌生人合作。 不過，無論如何，大型團隊的管理都很困難，雖然有些方法相當有效（比如上面介紹的方法，我都親眼見證其效果），但做起來又很難。 別人的經驗距離自己的實踐總是很有距離，這個距離中間還阻擋著很多障礙。在真正嘗試前，這些困難常常顯得不可跨越。 不過正是因為如此，管理才是一個值得探討的話題，成功的管理者也才變成受人尊敬和推崇的人。 所以，不要被現在看到的難題嚇倒。
如果您有任何補充問題，請在下面評論中補充，我會重新編輯或增加要點。謝謝參與。

本人正在參加CSDN部落格之星評選，如果讀完並喜歡這篇文章，歡迎投票：http://vote.blog.csdn.net/item/blogstar/cheny_com