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