敏捷开发团队管理系列之七：大型研发管理团队的切分（二）

 

问题

大体问题：若人数在30人左右开发一个产品，里边的子系统数量比较多，每一个子系统都有各自的发布计划，而又要协调。

若是做为一个团队管理，人数会太多；分解为多个项目，协调又麻烦，如何处理？

分析与方案

这个问题很难有广泛适应的方法来处理，我结合以前本身作过的项目来讲说。

因为大型团队很难见到太成功复制的，因此不要尝试简单对号入座，请理解背后的管理理念。

 

1. 不要作太大型的单一团队

这个坏处好理解，很少说了。

实际上，即便在10人左右的团队，若组长仍然本身要作技术工做的，均可能造成无人管理的团队。

因为缺乏沟通、互助，外加人员工做量分配很难均衡，经常由于个体的进度和质量耽误总体的进度和质量。

2. 不要行政性地分解团队

这个很容易让小组造成本身的“利益”，好比若是大组想临时抽调一些人出来，小组长会不一样意。往后工做会愈来愈难以开展。

比较好的作法是技术和小组管理上让小组长负责起来，但大组长仍然要保留对小组关于的权利，且要习惯性地让某些程序员临时调动一下工做。

你们必定看得出来，1和2很难操做，很难把握“度”，但咱们当年的确作到过。

 

实际上当年咱们最容易互相“临时调动”的，竟然是小组长，就是临时让小组长帮别的组作点事情。

一方面，因为这些人都是高手，别的组通常都特别欢迎；另外一方面，各小组长对本身的工做内容通常都有点“厌倦”了，他们对别的小组的工做兴趣大于普通的组员。

这些常常能帮助其余组的人在整个团队中的地位很高，即便发给他们很高的薪水，别人也不会嫉妒（由于他们也从帮助中受益了）。

这算是一种很强的激励和绩效管理方法，也会吸引别的小组长加入。

3. 核心会议

大组长+小组长要常常协调开会，咱们当年是25～32我的的组，每周一次会议。

最开始只有4我的参加，后来扩展到8我的，包括了2个非小组长但也是研发骨干的。

其实这种会议常常是“扩大会议”，取决于最近在干什么。

4. 开放办公室

千万不要由于小组分好了，还有核心会议能够沟通，就可让你们分开坐了！

虽然咱们历来没有尝试过把大团队从坐在一块儿改成分开坐，看看会发生什么（由于不敢，呵呵），但咱们尝试过让大团队坐在一个开放空间（即便有隔断，也要宽松点，不要搞院墙），还尝试过把分开的团队改成坐在一块儿。后二者的效果都很好。

一个意外的收获是，坐在一块儿的团队关系会很好维护，在提供或寻求帮助的时候，人们更愿意与一些每天在一块儿工做、吃饭的人交流，而不肯意仅仅由于技术或业务的须要与陌生人合做。

 

不过，不管如何，大型团队的管理都很困难，虽然有些方法至关有效（好比上面介绍的方法，我都亲眼见证其效果），但作起来又很难。

别人的经验距离本身的实践老是颇有距离，这个距离中间还阻挡着不少障碍。在真正尝试前，这些困难经常显得不可跨越。

不过正是由于如此，管理才是一个值得探讨的话题，成功的管理者也才变成受人尊敬和推崇的人。

因此，不要被如今看到的难题吓倒。

若是您有任何补充问题，请在下面评论中补充，我会从新编辑或增长要点。谢谢参与。