敏捷开发团队管理系列之七：大型研发管理团队的切分（二）
这是敏捷开发团队管理系列的第八篇（团队管理栏目目录）。还是敏捷开发一千零一问的第二十八篇（在这里提问，之一，之二，之三，问题总目录）。还是敏捷开发松结对编程系列的第十三篇（松结对编程栏目目录），与之前系列第六篇139团队、第九篇微软TechED上的讲座有密切关系。问题大致问题：若人数在30人左右开发一个产品，里边的子系统数量比较多，每个子系统都有各自的发布计划，而又要协调。如果作为一个团队管理，人
·
这是敏捷开发团队管理系列的第八篇（团队管理栏目目录）。
还是敏捷开发一千零一问的第二十八篇（在这里提问，之一，之二，之三，问题总目录）。
还是敏捷开发松结对编程系列的第十三篇（松结对编程栏目目录），与之前系列第六篇139团队、第九篇微软TechED上的讲座有密切关系。
问题
大致问题：若人数在30人左右开发一个产品，里边的子系统数量比较多，每个子系统都有各自的发布计划，而又要协调。
如果作为一个团队管理，人数会太多；分解为多个项目，协调又麻烦，如何处理？
分析与方案
这个问题很难有普遍适应的方法来处理，我结合之前自己做过的项目来说说。
由于大型团队很难见到太成功复制的，所以不要尝试简单对号入座，请理解背后的管理理念。
1. 不要做太大型的单一团队
这个坏处好理解，不多说了。
实际上，即使在10人左右的团队，若组长仍然自己要做技术工作的，都可能形成无人管理的团队。
由于缺少沟通、互助，外加人员工作量分配很难均衡，常常因为个体的进度和质量耽误整体的进度和质量。
2. 不要行政性地分解团队
这个很容易让小组形成自己的“利益”，比如如果大组想临时抽调一些人出来，小组长会不同意。日后工作会越来越难以开展。
比较好的做法是技术和小组管理上让小组长负责起来，但大组长仍然要保留对小组关于的权利，且要习惯性地让某些程序员临时调动一下工作。
大家一定看得出来，1和2很难操作，很难把握“度”，但我们当年的确做到过。
实际上当年我们最容易互相“临时调动”的，居然是小组长，就是临时让小组长帮别的组做点事情。
一方面，由于这些人都是高手，别的组一般都特别欢迎；另一方面，各小组长对自己的工作内容一般都有点“厌倦”了，他们对别的小组的工作兴趣大于普通的组员。
这些经常能帮助其他组的人在整个团队中的地位很高，即使发给他们很高的薪水，别人也不会嫉妒（因为他们也从帮助中受益了）。
这算是一种很强的激励和绩效管理方法，也会吸引别的小组长加入。
3. 核心会议
大组长+小组长要经常协调开会，我们当年是25～32个人的组，每周一次会议。
最开始只有4个人参加，后来扩展到8个人，包括了2个非小组长但也是研发骨干的。
其实这种会议经常是“扩大会议”，取决于最近在干什么。
4. 开放办公室
千万不要因为小组分好了，还有核心会议可以沟通，就可以让大家分开坐了！
虽然我们从来没有尝试过把大团队从坐在一起改为分开坐，看看会发生什么（因为不敢，呵呵），但我们尝试过让大团队坐在一个开放空间（即使有隔断，也要宽松点，不要搞院墙），还尝试过把分开的团队改为坐在一起。后两者的效果都很好。
一个意外的收获是，坐在一起的团队关系会很好维护，在提供或寻求帮助的时候，人们更愿意与一些天天在一起工作、吃饭的人交流，而不愿意仅仅因为技术或业务的需要与陌生人合作。
不过，无论如何，大型团队的管理都很困难，虽然有些方法相当有效（比如上面介绍的方法，我都亲眼见证其效果），但做起来又很难。
别人的经验距离自己的实践总是很有距离，这个距离中间还阻挡着很多障碍。在真正尝试前，这些困难常常显得不可跨越。
不过正是因为如此，管理才是一个值得探讨的话题，成功的管理者也才变成受人尊敬和推崇的人。
所以，不要被现在看到的难题吓倒。
如果您有任何补充问题，请在下面评论中补充，我会重新编辑或增加要点。谢谢参与。
CSDN联合极客时间，共同打造面向开发者的精品内容学习社区，助力成长！
更多推荐
5
0- 0
已为社区贡献48条内容
所有评论(0)