让程序员们很郁闷的团队结构——论研发团队的结构

今天，一以前的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、架构师竟然是可以单独走一个序列，我表示非常诧异！
 
暂时写这么多，欢迎拍砖。
 

我的微博： http://weibo.com/useway

可以@我：@钟声程序员

 

钟声，《Java程序员，上班那点事儿》作者

2013-8-13

 

谢谢大家！！