关于团队的一些思考，玩WOW时候的思考

在我工作过的团队中，有2个人的微型团队（程序员+美工），也有30人以上的团队。对于微型团队，完全依靠个人努力，两个人配合默契，分工明确就OK了。
但对于30-100人这样规模的团队，又怎么样呢？通常的结构会是这样：

需求小组1： 小组长，需求人员1，需求人员2，需求人员3，需求人员4.....。
开发小组1： 小组长，开发人员1，开发人员2，开发人员3，开发人员4.....。
开发小组2： 小组长，开发人员1，开发人员2，开发人员3，开发人员4.....。
开发小组3： 小组长，开发人员1，开发人员2，开发人员3，开发人员4.....。
...........
开发小组n： 小组长，开发人员1，开发人员2，开发人员3，开发人员4.....。
测试小组：   测试组长： 测试人员1，测试人员2，测试人员n....。
小组n：......
起码我经历过的团队大约就是这个样子的。但是这个配置真的是最合理的么（或者，还有没有更适合的方案呢）？

除了编程以外，我还是一个网游爱好者，曾经玩了两年的wow，wow是一个讲究团队的游戏，一个团固定40人。共由8个职业的玩家组成（战，法，牧，德..等等）。这样一个团队通常是怎么组建的呢？

首先根据要战斗的场景来决定各个职业的比例，是raid，还是战场？是需要DPS高输出，还是多组牧师死磨硬耗？
这就相当于我们组建团队的时候考虑的，需求人员有多少？设计人员有多少？开发人员有多少？测试人员有多少？质量人员有多少？

在确定了各个职业的比例以后，就会开始进行分组，首先，所有的同职业，会建立一个频道。比如战士会有战士频道，法师会有法师频道。以便他们能够独立沟通，并且各职业都会有一个队长，队长将负责对本职业的人员进行要求和培训，同时也会处理一些内部冲突，比如战利品分配以及倒休，替补等事情。

然后就是进行分组，每组通常会由一个能抗的（战），2，3个能打的（法师，术士，猎人，盗贼），然后1到2个治疗的（牧师，小德，洒满，骑士）。组成的一个5人小组。然后多余的一些不需要其他人支援的职业会放在一起（猎人，贼）。

这样形成的团队整体结构如下（一般大概情况）：
小队1 ： 战士，术士，骑士，萨满，牧师。
小队2 ： 战士，法师，小德，术士，牧师。
小队3 ： 战士，法师，猎人，小德，萨满。
.....
小队8 ： 猎人，猎人，猎人，贼，贼。

从来没有见过这么分组的：小队：战士，战士，战士，战士，战士。（这种菜刀队在极端情况下炫一下也不是没有可能）。

那么这么分组到底会有什么好处呢？
我感觉，首先，团队领导在指挥上更加方便，在战斗中，指挥者可以这个发出指令："所有法师退后，所有战士向前，其余人散开"。也可以这么发出指令“4，5队去东南方向防守，6，7队去北边防守，其余人集中进攻”。这样，同组的人会互相监督和提示自己是不是做错了什么，或者有什么没做。而职业队长也会监督自己的职业的队员的行为是否正确。

 

第二，增强小队战斗力，当一个小队单独作战的时候，他们内部的依赖性会变得很大，不同职业的搭配显然要比同一职业的配合要完善。

 

第三，突出责任，因为小队中的队员依赖变大，所以迫使小队成员每个人必须进步以应付他面对的问题，我们谁都不原意听到对自己这样的评价：“我们队的牧师不行”，“我们队的法师太差了，根本让我没办法完成任务”。所以，这样对小队内成员的成长会起一个推动的作用。

 

第四，BUFF影响，在游戏中有这样一个设定，就是某职业的角色会对其他团队成员有帮助，这就像你组内有一个构架师或DBA，当你有遇到有构架方面的问题（或数据库方面），你就可以直接问他，而不用找最忙碌的总构架师一样。如果这个组内构架师能够解决问题，则可以增加工作效率，如果不能，构架师可以请示其职业队长，这样的沟通要比所有人一呼而上的情况好的多。而且这样也有助于技术，业务的传播。

 

第五，小队活动将更加方便，更灵活，沟通成本更低，5个人的沟通，要比40人的沟通方便的多。5个人的活动也比40人的活动好组织。

 

第六，小组竞争得以实现，因为每个小组都是完整的，可以胜任完整的任务，所以他们更容易形成竞争的情况。

 

第七，可以更方便的进行一些其它方法，工具，思想，战术的实践，因为小组是完整的，更加独立，可以自己遵循自己的工作方式。并加以验证。

 

第八，小组更容易培养潜移默化的工作文化，因为小组是完整的，小组间成员依赖性更大，所以更容易互相监督，互相支持，从而是工作气氛更容易协调。

 

第九，小组的目标更明确，因为小组是完整的，任务更加明确。

 

第十，这样的小组更不好混，喜欢混团的人都知道，40人的团可以混，5人的团对绝对不能混，因为队里面你可能是唯一的职业，如果你犯什么错误，是很容易被发现的。

 

总的来说，小组越独立，就越容易管理，越容易形成自我管理型团队。而团队中的人员越多，小组内成员越重复的时候，每个人的责任感都会下降，每个人的贡献率都会下降。这就根1个人单独看到有人受伤，肯定会去救援，而在到处是人的环境下，大家各顾各的，往往却不会去救援伤者的道理是一样的。因为大家都在想，这么多人了，别人为什么不去？为什么非要我去？所以大家都装看不见。

 

就像BROOKS博士在人月神化中组建的外科手术队一样，我们也需要一个更优秀，更完整，灵活的小队来完成任务。手术师队伍中只有主治医生才拿刀，而屠夫团队中所有人都拿刀。

 

在我所设想的团队中，将有一名主程序员（首席程序员），主程序员可能会兼一个组内构架师的角色并负责大部分设计工作。然后是他的1到2个副手，程序员，他们负责实现主程序员设计的接口和功能。然后是2名测试人员（要保证测试人员和开发人员一样多，这在TDD的情况下十分重要），一名业务专家（他可以更深的理解业务，分析需求，甚至可能会临时充当DBA），一名质量管理员（说实话，我希望是2，3名）。这样我们就有了一个7人小组。结构如下：

 

主程序员角色   --------  组内架构师，设计，制定接口，编写核心部分。
程序员1角色     --------  接口实现（XP）
程序员2角色     --------  功能实现（XP）
业务专家角色  ---------  需求，组内DBA
测试工程师1角色  ------  测试用例
测试工程师2角色  ------  人工测试
质量人员角色   ---------  代码走查，核对实现与设计是否有偏差，文档管理，协助。确保质量目标，执行质量策略，组织培训。（1个质量人员可能比较勉强，专门指定质量人员的意义在于，走查代码的人，就不再适合写代码）。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

对于程序员角色，不仅需要熟悉JAVA API，而且还要足够理解XP和设计模式。这个对于开发人员的要求还是比较高的

 

大约就是这样子，还可以进一步细化。这样的小对更合适AOP，SOA这样的程序开发思想。能够独立设计并完成Service。

注意，小组中的都是角色，当一个开发人员在写测试用例和运行测试用例测试的时候，他就是一个测试人员角色，当他实现接口的时候，他就是一个开发者角色。

未完待续。。。。。。

 

我有的时候总是在想，为什么几个学校里面没毕业的学生、不务正业的工人、还有素质那啥的城管、插科打诨的程序员组成的团队效率如此之高。
而那些貌似强大的公司、5位数身价的高管、无数硕士研究生，本科等高学历高素质的人材组成的团队，缺是如此混乱不堪。
原因不外乎以下几点：

1。我们（wow世界里，不是在公司）有明确的、不可动摇的目标。
那就是杀掉BOSS，获得胜利，荣誉，还有战利品。没有人不想胜利。

2。我们有足够的动力。
BOSS掉落的战利品足够让我们馋涎欲滴(虽然大都看上去遥不可及)，胜利的荣誉会让我们振奋，想象一下你就是第一个杀掉强大的龙团队中的成员，你们的传说会在整个世界回响。

3。我们有足够的竞争压力
各个工会之间的进度竞赛会让激起很多人的斗志。

4。我们足够团结
我们在分配战利品上的原则十分明确（DPK制度），透明，没有人可以耍花样。

5。我们合作的时间长
1个磨合了两年的团队的战斗力是不容小视的。

6。我们有足够困难，但是能实现的目标。并且有足够的精力来进行各种尝试
虽然BOSS们看起来像神一样强大，但是我们总是会在1000.....00次时候，把他击倒。

借用wow里常说的两句话，“不怕神一样的对手，就怕猪一样的队友”，“我最强大的装备，就是我身边的39个兄弟”。

 

继续未完待续.....................

 

 这里的各位同僚们，你们的队伍是什么样子的么？

 

 

 

 

 

 

 

评论

17 楼 iamzealotwang 2008-09-26  

我觉得lz说的这种团队太理想化了。

“4，5队去东南方向防守，6，7队去北边防守，其余人集中进攻”

这种分头作战的团队，首先要确定4，5团队南方要守得住。如果南方受不住的情况下会出现何种后果？
整体团队是否能承受得了这种后果么？游戏下副本一次不成 可以第二天组团重新下 项目如果失败了一次 我想后果就很可怕吧。

“当你有遇到有构架方面的问题（或数据库方面），你就可以直接问他，而不用找最忙碌的总构架师一样。如果这个组内构架师能够解决问题，则可以增加工作效率，如果不能，构架师可以请示其职业队长，这样的沟通要比所有人一呼而上的情况好的多。”

我承认人的能力是有 能力强与能力弱之分的。 那之所以能成为架构师或者DBA 他一定有他过人之处的。如果行业里面的总经理 我们认为做到那个职位是有水分的（就是可能是拍马屁能力强一些 等等）那么我觉得 架构师 DBA 这种职位一定是能者当之的。 谁能力强谁来做。 您说您现在是PM，我不知道是不是项目经理的意思 如果是 那我想您一定也有比别人出色的能力 才做到那个职位的吧。 我想说的意思是 这样的人才不多，不是不想培养 而是培养不出这么多。谁都希望世界上多几个爱因斯坦 但是，不是每个人都能在有生之年当上爱因斯坦的 不是么？（他们不是不想，那么多科学家 我想他们每个人都想拿诺贝尔奖 不过诺贝尔奖是一个标准 标准往往就是无情的 不是每个人可以达到的）

软件开发要的是成果以及安全性 而这种分开治之，各档一面的方法 首先不安全 其次人员能力不够

而和在一大群里面 首先是安全的，有很强的抗外界因素能力。 其次要求人员能力比较低。

16 楼 hotjava 2008-09-17  

我现在刚开始做PM。
感觉到异常的艰辛。有很多事情真的和想象中的不一样啊。

15 楼 starse7en77 2008-09-13  

不好意思 ， 或许游戏的时候分配的人不会有我们的XX很菜 。
但不太相信 ， 30人的团队中 ， 没有新手 。
小队1 ： 战士，术士，骑士，萨满，牧师。
小队2 ： 战士，法师，小德，术士，牧师。
小队3 ： 战士，法师，猎人，小德，萨满。

这种做法是在均衡的情况下 。 但实事上的团队呢 ？
需求小组1： 小组长，需求人员1，需求人员2，需求人员3，需求人员4.....。
开发小组1： 小组长，开发人员1，开发人员2，开发人员3，开发人员4.....。
开发小组2： 小组长，开发人员1，开发人员2，开发人员3，开发人员4.....。
开发小组3： 小组长，开发人员1，开发人员2，开发人员3，开发人员4.....。
...........
开发小组n： 小组长，开发人员1，开发人员2，开发人员3，开发人员4.....。
测试小组：   测试组长： 测试人员1，测试人员2，测试人员n....。

因为当中有新人 ， 有对业务不熟悉 ， 有想跳槽的 ， 所以不得不这样分 。
打个比方只有5个测试的情况下 ， 一个新手 ， 一个业务不熟 ， 一个想走 。
如果分到5个组 ， 可想而知 ， 在整合的时候 ， 其他小组难免不熬夜加班 ！

14 楼 pipilu 2008-09-12  

<div class='quote_title'> 楼主写道</div>
<div class='quote_div'>我有的时候总是在想，为什么几个学校里面没毕业的学生、不务正业的工人、还有素质那啥的城管、插科打诨的程序员组成的团队效率如此之高。<br/>而那些貌似强大的公司、5位数身价的高管、无数硕士研究生，本科等高学历高素质的人材组成的团队，缺是如此混乱不堪。</div>
<p> </p>
<p>　何出此言？有例子么？</p>

13 楼 liano 2008-09-12  

如果规模很大的话，可以分成小队，就像项目中可以有子项目。
每个子项目中要有需求分析员，开发，测试人员。这三个角色最好能在一起工作，提高交流的效率。
如果20个人的团队都是dev的话，第一，找人问需求费劲， 第二， 20个人就容易形成部落，部落之间沟通比较少，这样就没必要把20个人放到一个团队中去。
一个团队应该是沟通效率最高的。

12 楼 hotjava 2008-09-11  

不过其实我也遇到过纯职业队的RAID。
比如我的LR号常年处于8队，全LR有时候连治疗都没有。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

LR....的确理论上RAID时是不需要治疗的。

11 楼 deanchun 2008-09-11  

呵呵  LZ对wow理解的很透彻啊！

10 楼 suliuyes 2008-09-10  

楼主思考的不错。

不过其实我也遇到过纯职业队的RAID。
比如我的LR号常年处于8队，全LR有时候连治疗都没有。

其实也要看情况了。

不过我只知道一点。
软件开发的话，总有种给人打工的感觉，而WOW是自己给自己干活的感觉。心态不一样了。效率也就不一样了。 如果遇到明智的公司和老板，能做到让下属有归属感，其实很多问题就不是问题了。这样的IT公司，太少太少。

9 楼 xqstation 2008-06-04  

hotjava 写道

to movingboy
---------------
说的没错,的确是如果硬拉到一起比,不太适合.但是可以得到一些启发.

但是, 人的心态也是管理的一部分,游戏团队未必好带,游戏中的人,隔着网络,本性都可以毫无遮拦的显现出来.也可以伪装自己.

两组人马面对的问题及复杂度,怎么说呢,你觉得一个OA系统业务比几个大型副本要复杂么?而且,游戏中的热人,有没毕业的学生,还有啥都不懂的小mm,还有没工作的小混混.
这样的人组合起来, 依然可以管理的井井有条.

为什么很多公司的组织,却那么混乱呢?我觉得这里面一定有值得研究的地方.

如你那只兔子爪子上的萝卜。
有萝卜吃，有蓝色萝卜，紫色萝卜，甚至有金黄色的超级大萝卜。。。
SO。。。很好。都有目标，都要那个金黄色的超级大萝卜。即使没有也能有个紫色的萝卜。。

公司组织中给不出金黄色的超级大萝卜。甚至连紫色萝卜都给不出。。
相当与工会仓库中的G，修装备用用而已。。想拽？自己组野队去。

8 楼 hotjava 2008-05-30  

to movingboy
---------------
说的没错,的确是如果硬拉到一起比,不太适合.但是可以得到一些启发.

但是, 人的心态也是管理的一部分,游戏团队未必好带,游戏中的人,隔着网络,本性都可以毫无遮拦的显现出来.也可以伪装自己.

两组人马面对的问题及复杂度,怎么说呢,你觉得一个OA系统业务比几个大型副本要复杂么?而且,游戏中的热人,有没毕业的学生,还有啥都不懂的小mm,还有没工作的小混混.
这样的人组合起来, 依然可以管理的井井有条.

为什么很多公司的组织,却那么混乱呢?我觉得这里面一定有值得研究的地方.

7 楼 movingboy 2008-05-30  

引用

我有的时候总是在想，为什么几个学校里面没毕业的学生、不务正业的工人、还有素质那啥的城管、插科打诨的程序员组成的团队效率如此之高。
而那些貌似强大的公司、5位数身价的高管、无数硕士研究生，本科等高学历高素质的人材组成的团队，缺是如此混乱不堪。

你说的这两个团队，前者是打游戏，后者是开发软件吧？
用来打个比方可以，但一定要把两者拉来对比，就失去了对比的基础了：
1.两组人马的心态不同
2.两组人马面对的问题及其复杂度不同
3.两组人马用于解决问题的技术不同
4.其它可能的未列举的不同处

6 楼 movingboy 2008-05-30  

楼主在说scrum？

5 楼 hotjava 2008-05-30  

当然,我只是空想,很可能不现实的. 希望大家多批评.
实践出真知,哪位志同道合的大哥有条件实践一下看看.
还有,感谢上面两位兄弟回贴评论.多谢...

4 楼 hotjava 2008-05-30  

to  luyitadeng
耗时如此之长的团队组建，
------
没有耗时多少啊?难道大家都是做外包的,干点活就走么?其实游戏中的团队更难组建,
因为大家可能都忙,说不上线,就不上线,你又不给人家发工资,你能限制人家旷工么?

关于人员跳槽...游戏里面比真实工作频繁多了,很多人都是今天在这个工会,明天在那个工会,反正都是网络上的虚拟东西,谁限制的了谁?谁怕谁?

我们的做法是走一个培养一个, MT走了,没关系可以在培养,我们有替补MT,
而很多公司都没有替补CTO吧,为什么不多弄几个组内构架师呢,也懂点架构.等到关键时刻,从替补到主力,只是一个称为的区别.

3 楼 hotjava 2008-05-30  

to 7thbyte
1.真实的项目中，不存在阵亡跑尸体复活。。很多时候是一锤子买卖。。
2.有时候人员比例选择不是那么随心的。。受种种限制。。招人难。。
3.战利品分配貌似潜规则只会比游戏更多。。
--------------------
的确,有很多时候都是一锤子买卖,但是项目本质不会变,而且,一个公司一般都是做一个行业的软件,比如一个公司专门做OA,或者专门做电信软件,这个和跑尸的道理是一样的,都是有继承性的.如果是做产品,更不用说了.

招人的确难,但是,这个和游戏的道理是一样的,大家都是锻炼起来的.你一开始不是从1级开始玩的啊.不要想上来就有一帮天神一样的队友,而是想办法培养一帮合作的队友.
招人难,我找工作还难呢.

战利品分配,这个其实就是利益平衡,游戏中可以很透明,但实际工作中大家的薪水却是保密的,但是,真的是密不透风的么?不一定,其实管理者在利益分配上耍不均衡的话,很快就会显现出来.

DPK制度我觉得是比较完美的制度,什么都按贡献分配, 不和你的学历,和人力mm吹水有关系.没有人会不平衡.

2 楼 luyitadeng 2008-05-30  

很欣赏你的思考方式，不过好的团队在不断的淘汰与更新中成长的。耗时如此之长的团队组建，现实的实用性并不高啊。我也喜欢WOW。也进行过思考。

1 楼 7thbyte 2008-05-30  

1.真实的项目中，不存在阵亡跑尸体复活。。很多时候是一锤子买卖。。
2.有时候人员比例选择不是那么随心的。。受种种限制。。招人难。。
3.战利品分配貌似潜规则只会比游戏更多。。