原文出处:http://blog.csdn.net/useway/article/details/9945893?reload
作者:钟声 微博:@钟声程序员
今天,一以前的HR美女同事,让我给她设计的研发团队体系结构一个建议。我看了结构图以后,告诉她:这是一个非常郁闷的研发团队,大家会纷纷跳槽!
如下图:
她大惑不解:我这个团队结构有啥不妥呢?明明是各就各位,井井有条啊!
好,我在这里给大家解释一下我得出的结论。作者:钟声 微博:@钟声程序员
一、好的团队结构要做到几个分离:1、职级和职位分离,2、管理级(M)和技术级(P)分离
1、职级和职位分离
就是说,职级的高低和职位无关,比如,某总监职级是P3级,但是,他手下的一个架构师是P4,这是可以的。
这样的好处在于,职级成为一个客观评价人员能力的标准,而和他所做的具体职位无关,不是高职位也可以拿到高工资,人们就没必要因为一个职位或者一个Title而互相竞争从而产生内耗,让大家把注意力都集中到自己的技术和管理能力上来。
2、管理级(M)和技术级(P)分离
这个分离是将业务能力更有效的进行平等分级,避免技术强人主导公司一切事物的有效方式。M级和P级同级别的人物其话语权在公司中是平等的,这样,两边在同一个问题上就形成了相互支撑和相互制约的关系。
如果没有M和P的分离,就会造成,要么公司领导都不懂技术,要么就是公司领导都是技术强人而都不懂管理的局面。
M和P的上升通道都有效,并在职级上其【业务能力】都得到公司的认可。
二、职级划分的目的不是为了发工资多少,而是给员工一个晋升通道和希望
很多HR都误会的认为,职级是为了定工资,其实不是,你订立的职级其实是给每个人一个晋升的通道和希望。
M和P的上升同道都有效,并在职级上其【业务能力】都得到公司的认可,这对于每个职级序列中的人来说,都是一个晋升的通道和希望,职级较低的员工会知道自己在自己的序列中的努力方向更重要。
每个人都知道自己下一个目标,以及下一个台阶在哪里。
三、职级和职位分离的目的是可上可下
作为一个公司,由于职位会和其具体工作内容绑定,职位的调整往往比较困难,往往是只可上,难可下,一旦职位降低,就意味着该人员被弃用。
而职级和工作内容无关,仅仅和其业务能力相关,在职位不变的情况下,可上可下。
如果,职级只可上,不可下,那么就会造成【混日子,混年头】的情况,人们会认为【只要年头混得久,职级自然会慢慢增长】。当然,如果职级不能下只能上,那么对于Teamleader和HR来说是最好管理的,只需要看看该员工的入职年限即可评定职级了。
然而,这就违背了职级和职位分离的设计初衷。
四、M级和P级都可以管人
还有一种错误想法,认为,P序列的人不能管人,比如“架构师”只能管技术,带团队只能由M的人来管,技术再牛也不能带团队。
试问:如果技术大牛不管团队,技术方向和架构方向怎么确认?由不懂技术的M的来定夺??
当然,这必然成为了一个灾难。
一个好的研发团队,靠的不仅仅是管理能力,还需要Teamleader的技术能力和其自身的技术魅力。
如果一个不懂技术的人管理技术团队,恐怕,这个团队的人都会纷纷离职了吧。
综上所述,再看看上面的那张图。
看似每个人都各就各位,井井有条,其实呢?
1、上升通道是封闭的,看不出后面的发展路径...
2、管理级的人物,都是天兵天将,都是空降人物,而且,都是不懂技术的...
3、架构师竟然是可以单独走一个序列,我表示非常诧异!
暂时写这么多,欢迎拍砖。
对了,应大家要求,我把正确的体系结构的原理图贴出来,供大家参考...
这种结构,每个职位定义职位说明书,和任职素质模型,即可。
主要实现了,职级与职位的分离,而不是混为一谈,每个专业有自己独立的上升通道,职级又和工资挂钩,职级是业务能力的评价结果,人们的工作重心就放到业务的能力的提高上面,而不再关注具体职位了。
欢迎大家继续讨论,也可以关注我的微博。