你好,我是华仔。
上一讲我分享了两条晋升逻辑和一套通用的晋升步骤。现在你已经知道,要先把当前级别要求的能力提升到精通程度,然后尝试做下一级别的事情。
不过在这个过程中,你还会遇到另一个麻烦,那就是不确定下一级别的能力要求到底是怎样的,所以你也不知道究竟要准备到什么程度。
举个最常见的例子,不同级别有不同的Title(头衔),比如“工程师”“高级工程师”和“专家工程师”等。但是,这样的 Title 对我们理解不同级别的能力要求,是完全没有什么用处的。“高级工程师”到底“高级”在哪,可能每个人的理解都不一样。
为了指导员工晋升,公司一般都会对各个级别的能力要求给出描述。但是因为细分的领域实在太多了,所以公司只能进行非常抽象的描述。
比如,P7的要求是“具备系统思考的能力,能够全面掌握某个技术领域”,而P8的要求是“具备前瞻判断的能力,能够规划技术领域的发展方向”。
从实际的效果来看,这样的描述基本没什么效果,绝大部分人看完还是一头雾水。在实际工作中,团队成员经常跟我反馈这样的困惑:
可以说,晋升疑惑千千万,能力要求占一半。这一讲我要介绍的就是把抽象要求具体化的方法。
因为公司的抽象描述很难指导实际工作,所以有些领域会独立定制自己的职级能力解读,一般是由P8或P9级别的员工以工作组的方式讨论得出来的。
比如“Java业务开发”这个领域,P6和P7级别的能力解读长什么样呢?你可以参考下面的表格。
(注:这张表格仅供参考。它不是完整的解读,不代表所有公司的实际要求。你也不需要看懂里面的所有内容,只要了解这个形式就可以了。)
我们可以看到,这份标准跟公司的描述相比,已经具体很多了。如果按照这个思路,完整地把各个级别要求的能力一一列出来,不但可以作为晋升的标准,也可以作为学习的参考。
其实这种做法对员工是有利的,因为标准越明确,就越容易“照本宣科”地去做。但是从公司的角度来看,这种做法存在成本太高(有几十上百个专业领域要制定详细标准,每年都要更新)、限制创新(大家都只管对照公司标准来做事,其它一概不管)等问题,所以很少有公司会这么做。
为了彻底解决要求不明确的问题,让你更好地理解不同职级的能力差异,我根据自己的思考和担任晋升评委的经验,提炼出了一套兼容性很强又容易理解的能力模型:面向复杂度的多维度能力模型(Complexity-Oriented & Multi-Dimension Capability Model),简称COMD能力模型。
COMD的CO是指Complexity-Oriented,意思是“面向复杂度”(灵感来源于“面向对象”);MD是指Multi-dimension,意思是“多维度”,也就是技术、业务和管理3个维度。
COMD的核心指导思想是,通过事情的复杂度来判断能力的高低,级别越高,所做的事情复杂度也越高。
当然,如果只是单纯地用复杂度来判断能力高低,那么它本质上和其他方法也没什么不同,看不懂的地方还是看不懂,不同的人理解还是不同。
所以,为了清晰地描述不同能力层级的差异,COMD能力模型还进一步地明确了复杂度,具体包括规模复杂度、时间复杂度、环境复杂度和创新复杂度4种类型。
规模复杂度是指和规模大小有关的复杂度。
规模越大,复杂度越高。原因在于规模越大,节点越多,节点间的关系越复杂,而且节点间的关系复杂度是指数增长的。就像下面的图片所展示的:当节点数只有3个时,节点间的关系也只有3个;而节点数达到6个时,节点间的关系就变成了15个,复杂度提升了5倍。
按照这个原理,我们可以对一些常见工作维度的规模复杂度进行比较,具体如下表所示。
当然,以上对比的前提是,除了规模之外,其他条件都差不多。(对比其他几个复杂度时也是这样)。就像表格中200行代码和2000行代码对比,前提是代码复杂度是差不多的。因为200行核心代码的复杂度,显然比2000行拷贝粘贴的代码要高。
时间复杂度是指和时间跨度有关的复杂度。
时间跨度越长,复杂度越高。原因在于万事万物都处于不断发展变化当中,时间跨度越长,变化的因素和可能方向越多,越难判断准确。
三大维度的时间复杂度的对比举例如下表所示。
环境复杂度是指和环境不确定性有关的复杂度。
我们很多的判断、决策和行为都依赖于对环境的认知和反应。总的来说,环境不确定性越高,复杂度越高。
环境的不确定性具体分为环境的稳定性、环境的透明性和环境的可预见性3个方面:
环境的稳定性、透明性和可预见性越低,它的不确定性就越高,复杂度也越高。
下面这个表格从宏观的角度分析了技术、管理和业务三个维度所面临的环境不确定性。
从表格中可以看出,对于互联网行业的业务来说,环境稳定性、透明性和可预见性都比较低,所以它的环境复杂度是最高的。这也是在互联网大厂,大部分P9/P10都需要把很多时间和精力投入到业务上的主要原因。
创新复杂度是指和创新程度有关的复杂度。
常见的创新包括理论的创新、思想(或者说方法)的创新和技巧的创新。理论创新的复杂度要高于思想创新,而思想创新的复杂度又高于技巧创新。
以高可用技术领域为例:
我们可以看到,创新复杂度越高,影响的范围往往也越大。理论创新会奠定整个行业的基础,而思想创新可能开辟一个新的技术领域。
另外,创新并不意味着一定要全球首创,只要相比团队当前现状来说有改进就行了;创新也不局限于技术领域,管理和业务一样可以创新。所以,下面这些事情都可以算是创新:
各领域的部分典型创新案例如下表所示,你可以参考对照。
除了刚才说的这4种通用的复杂度之外,在每个领域内部,也会有一些工作的复杂度本身就要比另一些工作高。
比方说在软件开发领域,我们一般认为各项工作的复杂度排序是这样的:
$$从0到1创造系统 > 架构重构 > 项目方案设计 > 编码实现$$
不过这些认知是领域经验总结形成的共识,并不能通用。所以在使用COMD模型的时候,你还是需要结合领域经验综合判断。
我想,你现在应该知道为什么公司写的那些抽象描述让人看不懂了。跟COMD能力模型的具体拆解比起来,它们只是脱离实际的文字游戏罢了。我就拿这一讲开头提出的“系统思考”和“前瞻判断”来说好了。
比如在某些大厂,“系统思考”的确是写在P7级别的能力描述里,但它不是P7级别才有的能力特征。实际上,P6以上的级别都要求“系统思考”,区别只是思考的范围不同,也就是规模复杂度不同而已。
以B2C电商业务开发为例,在某些大厂,不同级别“系统思考”的范围如下图所示:
同样地,在某些大厂,“前瞻判断”虽然写在了P8的能力描述里,但其实P6以上都有前瞻性的要求,区别只是在于前瞻范围、时间跨度和面临的环境不同而已。这些因素就分别对应了规模复杂度、时间复杂度和环境复杂度。
同样以B2C电商业务开发为例,某些大厂P6~P9级别的前瞻性要求如下表所示:
所以说,如果你还在绞尽脑汁地钻研“为什么P7才提出系统思考”以及“P8要求的前瞻判断有什么深意”这样的问题,那就掉到文字陷阱的坑里去了,白白浪费脑细胞。至于怎么从坑里走出来呢?这就需要灵活应用COMD能力模型了。
当你想要了解某个级别的能力要求的时候,不要再对着那些抽象和模糊的词语,不着边际地猜测和想象了。你应该静下心,坐下来填一个“能力矩阵”的表格,把每一项的要求都完整且具体地列出来。比如下面这个“能力矩阵”表格就摘录了P6级别的部分要求,可以作为参考。
如果表格里有些内容你填不出来,说明你对这个级别的理解还不到位。不过没有关系,我会在课程的第二部分,也就是职级详解中给出每个级别通用的衡量标准。
在这个基础上,你可以请教你的主管、HR和同事等人,来完善和细化表格内容。当你详细地填完了这个表格,你也就对这个级别了解得很清楚了。接下来,你就可以对照表格,针对性地提升自己的能力。
现在,我们回顾一下这一讲的主要内容。
这就是今天的全部内容,最后留一道课后思考题给你吧。记得有一次,团队成员跟我探讨职级的时候,问了我一个问题:“为什么说P6是独当一面,难道P7、P8和P9没有独当一面的要求吗?”学了COMD能力模型之后,你会怎么回答这个问题呢?
欢迎你把答案写到留言区,和我一起讨论。相信经过深度思考的回答,也会让你对知识的理解更加深刻。
评论