等级制度是把所有人或团体分成等级的制度,在这种制度下各个等级拥有不平等的权利,上层等级权利大,下层等级权利小。有一种说法是,等级制度萌芽在原始社会的末期,私有制产生之前,首先表现为社会分层,同时开始产生阶段。
既然等级制度有其产生的原因,那开发团队中是否需要等级制度呢?
当静下来细细思索的时候,会发现有很多看似平常的东西,其实都值得我们推敲一番。
我国古代兵制,五人为伍,五伍为行,因此行伍即指军队。同样的道理,军队中有着更为明确的等级划分。目的就是为了简化管理。
不出意外的话,这种结构清晰、分工明确的管理体系是最优的。但经过无数次的实践表明,我们在软件开发的过程中,延误我们工期的不是计划中的事情、而是那些突发事件或者不明确的东西。
这种情况下,开发人员遇到了困难首先需要向组长报告,组长向经理报告。这时候处于最上层的项目经理就不得不熟悉具体的技术细节了。
当然,如果组长什么事情都往上报告那还要组长做什么。所以一般来说组长都会根据自己的判断来作出处理。这么一判断就出问题了。怎样才能保证我们的这位组长判断正确,就算这一次判断正确了下一次一定正确吗?如果存在两个组长、三个组长都是自己判断,那么在这个小组遇到的问题也就不能及时传递到整个团队。
以前我所处的团队就是以这种等级制度来管理的。如果说上面遇到的问题并不大的话,那么下面这个问题就是管理者不得不重视的了。
组长都是由经验丰富的程序员担当,如果经验丰富的程序员当上了组长,肯定会因为管理上的职责影响自己的工作效率。在我们现在的团队中,新的程序员占了大多数(这是很多公司的现状),凡是影响老程序员的效率的事情都是不可接受、不可原谅的,其实也就是管理成本过高。如果还用这种等级制度来管理的话会影响到团队的开发效率。
后来又尝试了扁平化的管理,这样可以将处于组长地位的程序员从管理细节上解放出来。看似效率提升了,但由于新的程序员没有人带,所以他们的成长特别缓慢,甚至还会走不少弯路。
以前我们尝试过严格的等级制度管理方式,发现管理成本超出了我们的预算;接着又采用了扁平化的管理,由于新人比较多又没有人进行严格的监督和辅导导致代码质量很低,结果也不理想。这样看来开发团队中用等级制还是不用确实是个问题?
如果完全抛弃等级制度,又会出现诸如监督和培训不足的问题。
最后采用了结对编程的方式,但这种结对不是对等的结对编程,更多时候是一个老程序员带着一个新的程序员来做。如果这时候有一个经验特别丰富的人来整体把握团队的进度情况会更好。
看起来,似乎就现状来说,我们不需要等级的制度,需要的是领导者的角色。不过就上面分析来看,等级制度带来的稳定性确是不存在了。
团队中的每个人在职位上是对等的关系,这时候表面上不存在高等级和低等级的区分,但人员流动造成的影响并不像想象中那么大。这是因为在这种扁平化管理中每个人的经验是完全分享的,就算人员流动,但知识并不会随着人员流动而流动。如果能做到这一点,那么等级制度可以丢掉了。
按照现在的团队规模(不超过20人)来看,等级制度是不合适的,不知道对于几百人、几千人的大开发团队是否需要等级制度,这就不得而知了。
既然等级制度有其产生的原因,那开发团队中是否需要等级制度呢?
等级制度的优劣
对于我们来说,社会上的等级制度对大家的影响是最大的。企业是社会的组成部分,组成企业的人同样也是社会的元素,自然而然地,社会上的一些意识、处世方式就不可避免地带到了具体工作中来。从小到大我们就习惯有着一层一层的老师和干部管着,到了公司大多数人还是被一层一层的经理和组长管着,这就是处处体现在我们生活中的等级。有时候甚至已经到了我们的潜意识之中。当静下来细细思索的时候,会发现有很多看似平常的东西,其实都值得我们推敲一番。
存在即合理
稳定的结构
首先,等级制度可以带来稳定的结构。当然,完全的稳定是痴人说梦。不同等级之间是一种制约与平衡的关系。等级的划分让结构不再混乱无序。就像软件设计中的分层一样,进行了等级的划分后,我们能将变动限制在某一个层面,不至于让一次变动影响到整个结构。简便的管理
在我小时候,家乡那边每逢端午节都会自己家里面包粽子,是江南的一个风俗。母亲是特别勤劳的一位家庭主妇,记得那些时候她都会煮上满满的几大锅。但是粽子多了很不好拿,我母亲的做法就是每五个粽子系成一串,每四串系成一提。这样可以很方面地将粽子一堆一堆地摆放起来,送给街坊邻居的时候也很容易弄清楚数量。我国古代兵制,五人为伍,五伍为行,因此行伍即指军队。同样的道理,军队中有着更为明确的等级划分。目的就是为了简化管理。
明确的分工
不同的等级有着不同的权利,做不同的事情。社会分工的必然。可能是地位上的等级分工,也可能是经验上的等级分工。这样的明确分工能有效地发挥每一个阶层的最大价值。没有十全十美的东西
应变能力缺乏
稳定的结构带来的副作用就是缺乏应变能力,处理计划之中的事情用这种层层下放的形式非常合适,一旦出现意料之外的是就会暴露出等级制度下的沟通不畅,或者能做决定的人无权,有权的人却不知道实际的情况。高额的管理成本
等级制度的管理是一种金字塔结构的,通常我们会将这种管理结构和扁平化管理相对比。金字塔式的结构会带来更高的管理成本。开发团队中的等级
很多公司的开发团队都是分为:项目经理、开发经理、开发组长、开发人员这么几层。这是一种典型的等级制度。不出意外的话,这种结构清晰、分工明确的管理体系是最优的。但经过无数次的实践表明,我们在软件开发的过程中,延误我们工期的不是计划中的事情、而是那些突发事件或者不明确的东西。
这种情况下,开发人员遇到了困难首先需要向组长报告,组长向经理报告。这时候处于最上层的项目经理就不得不熟悉具体的技术细节了。
当然,如果组长什么事情都往上报告那还要组长做什么。所以一般来说组长都会根据自己的判断来作出处理。这么一判断就出问题了。怎样才能保证我们的这位组长判断正确,就算这一次判断正确了下一次一定正确吗?如果存在两个组长、三个组长都是自己判断,那么在这个小组遇到的问题也就不能及时传递到整个团队。
以前我所处的团队就是以这种等级制度来管理的。如果说上面遇到的问题并不大的话,那么下面这个问题就是管理者不得不重视的了。
组长都是由经验丰富的程序员担当,如果经验丰富的程序员当上了组长,肯定会因为管理上的职责影响自己的工作效率。在我们现在的团队中,新的程序员占了大多数(这是很多公司的现状),凡是影响老程序员的效率的事情都是不可接受、不可原谅的,其实也就是管理成本过高。如果还用这种等级制度来管理的话会影响到团队的开发效率。
后来又尝试了扁平化的管理,这样可以将处于组长地位的程序员从管理细节上解放出来。看似效率提升了,但由于新的程序员没有人带,所以他们的成长特别缓慢,甚至还会走不少弯路。
以前我们尝试过严格的等级制度管理方式,发现管理成本超出了我们的预算;接着又采用了扁平化的管理,由于新人比较多又没有人进行严格的监督和辅导导致代码质量很低,结果也不理想。这样看来开发团队中用等级制还是不用确实是个问题?
我们需要等级吗?
由于团队规模不大,采用等级制度的话会付出高额的管理成本,这点我们很难接受。同时由于软件行业的变化性,等级制度在这种环境下弱点是非常明显的。如果完全抛弃等级制度,又会出现诸如监督和培训不足的问题。
最后采用了结对编程的方式,但这种结对不是对等的结对编程,更多时候是一个老程序员带着一个新的程序员来做。如果这时候有一个经验特别丰富的人来整体把握团队的进度情况会更好。
看起来,似乎就现状来说,我们不需要等级的制度,需要的是领导者的角色。不过就上面分析来看,等级制度带来的稳定性确是不存在了。
团队中的每个人在职位上是对等的关系,这时候表面上不存在高等级和低等级的区分,但人员流动造成的影响并不像想象中那么大。这是因为在这种扁平化管理中每个人的经验是完全分享的,就算人员流动,但知识并不会随着人员流动而流动。如果能做到这一点,那么等级制度可以丢掉了。
按照现在的团队规模(不超过20人)来看,等级制度是不合适的,不知道对于几百人、几千人的大开发团队是否需要等级制度,这就不得而知了。
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1269516