mirror of
https://github.com/cheetahlou/CategoryResourceRepost.git
synced 2025-10-21 01:13:45 +08:00
mod
This commit is contained in:
167
极客时间专栏/大厂晋升指南/晋升体系/01 | 职级体系:你意识到级别鸿沟了吗?.md
Normal file
167
极客时间专栏/大厂晋升指南/晋升体系/01 | 职级体系:你意识到级别鸿沟了吗?.md
Normal file
@@ -0,0 +1,167 @@
|
||||
<audio id="audio" title="01 | 职级体系:你意识到级别鸿沟了吗?" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/ab/2e/ab8de6cf51a36abbd3a34aec289c7d2e.mp3"></audio>
|
||||
|
||||
你好,我是华仔。
|
||||
|
||||
今天我们开始课程的第一讲,我想和你聊聊**职级体系**这个事儿。
|
||||
|
||||
如果我们把职场晋升的过程比作在游戏中打排位赛来提升段位的话,那么职级体系就是游戏的**段位规则**。它定义了整体的段位等级分布(比如从倔强青铜到荣耀王者),每个段位的要求(比如钻石段位以后要学会怎么重新匹配一局游戏),还有晋级的规则(比如每个段位几颗星可以晋升下一个段位)。
|
||||
|
||||
如果你所在的公司已经有明确的职级体系,那么深刻理解职级体系的特点,有利于你设定合理的晋升目标和规划。这样你就能避免因为急于求成而心浮气躁,或者因为埋头苦干而错失晋级的机会。
|
||||
|
||||
如果你想跳槽到心仪的公司,那么全面了解对方的职级体系,有利于你合理地进行自我评估,在面试的时候拿到更好的定级结果和薪资报酬。
|
||||
|
||||
不同性质的公司和机构,采用的职级体系差异很大,最常见的有以下两种。
|
||||
|
||||
第一种是**职称体系**。
|
||||
|
||||
“职称”的正式名称是“专业技术职务任职资格”。常见的教师、医生、会计和律师等职业基本上用的都是这套体系。
|
||||
|
||||
它的优势在于**标准统一**,全国通行,可以无缝切换。比如一个医生在A医院是副主任医师,换到B医院的话,职称是可以平移的。职称这套体系在公务员、事业单位、国企等机构是通行的标准,但是在互联网行业很少应用。
|
||||
|
||||
第二种是**自立体系**。
|
||||
|
||||
互联网公司用的往往是这种方式,也就是说,公司自己制定完整的职级体系,内部评估员工的级别,并根据职级体系设计相关的薪酬福利等激励机制。
|
||||
|
||||
自立体系的优势在于,公司可以根据自己的实际情况**灵活操作**,并不断演进;而它的劣势是,由于行业缺乏统一的标准,一个公司在吸纳其他公司的人才时,**不太容易直接对标**。
|
||||
|
||||
对于软件行业来说,国内大部分互联网和软件公司基本都是民企,基本上都是采取自立体系的方式来制定自己的职级体系。同时,由于领头羊腾讯和阿里的强大影响力,行业内部逐步形成了对标腾讯和阿里职级的做法,于是阿里和腾讯的职级也就成了“硬通货”。
|
||||
|
||||
虽然自立体系可以灵活多样,但是从本质上说,基本上都是按照以下方式设计的:
|
||||
|
||||
1. 职级体系划分为**专业线**和**管理线**,专业线指员工在某个专业领域晋升,管理线指员工在管理岗位晋升。软件行业的研发、测试、运维、产品经理、运营、UI/UE、HR等都属于专业线晋升。
|
||||
1. 专业线按照其设计特点又可以划分为两类,那就是**跨越式职级**和**阶梯式职级**,涵盖了从毕业生到业界精英的各个级别。
|
||||
1. 管理线一般不会再分领域,而且你在专业线达到一定级别后,才能转管理线发展(例如某公司规定专业线要达到阿里P9级别才可以选择转管理线发展)。这样做的目的在于**鼓励员工积累足够的专业技能**,而不要变成只会发号施令开会写报告的纯管理者。
|
||||
1. 以前也有公司尝试专业线和管理线**双通道**发展的模式。但是这种模式被实践证明存在很多问题,比如投入大、不好评估员工能力、外行管内行等,所以现在已经很少用到了。
|
||||
|
||||
这门课程的内容聚焦于专业线的晋升指导和技巧。虽然我是技术出身,课程中的案例大多也是技术案例,但其中70%的内容其实是具有普适性的,同样适用于产品经理、运营和策划等岗位。
|
||||
|
||||
接下来,我会为你详细介绍专业线的两类职级体系的特点。
|
||||
|
||||
## 跨越式职级
|
||||
|
||||
我们先来看跨越式职级。简单来说,在这个体系下两个级别之间的差异很大,就像有一条**“级别鸿沟”**,你需要用很大的力气才能跨越这条鸿沟。
|
||||
|
||||
目前国内知名公司当中,采用跨越式职级的有阿里、百度、滴滴和头条等。其中阿里的职级体系比较典型,也是我最熟悉的,所以接下来我就以阿里的职级体系为例,来具体说明跨越式职级的特点。
|
||||
|
||||
下面这个表格总结了阿里职级体系的级别设置和基本定义(关于各个级别详细的定义和要求,我在后续课程中会详细介绍)。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/8c/8d/8c4d083304cfe1ffded18fb672ce288d.jpg" alt="" title="网传阿里职级体系表">
|
||||
|
||||
以技术人员为例,本科应届生初定级是P5;随着能力和经验的积累逐步升级,大部分人可以升到P7;能够升到P8的人已经是很厉害的了,而能够升到P9的,虽然不至于凤毛麟角,但也算得上是百里挑一,我工作十多年也就是P9而已;至于P10和P10以上的级别,往往可遇不可求,能升到这个位置的都是业界响当当的人物了。
|
||||
|
||||
表格中P6和P7标了黄色,也是说明绝大部分工程师是处于这两个级别。
|
||||
|
||||
那么,这种职级体系有什么特征呢?
|
||||
|
||||
第一个特征是,**相邻两个级别的差异比较大**。
|
||||
|
||||
##### 因此,晋级的时候不是简单地要求能力“有提升”就可以了,而是要求有**“本质的提升”**。
|
||||
|
||||
举个简单的例子,你带3个人或者4个人,团队管理能力是没有本质的区别的;但是如果让你带30个人,团队管理的能力和带3个人的时候肯定差别很大,这就是本质的提升。
|
||||
|
||||
这样的要求会导致一种常见的现象,让很多人难以理解,甚至心有不甘。那就是,一个员工在当前这个级别做得很好,绩效不错,主管和同事也都认可,但是在晋级的时候却多次通不过。
|
||||
|
||||
大部分人在分析原因的时候,会认为是“自己紧张,所以没发挥好”,或者“评委对我不熟,所以没有发现我的能力”。如果遇到这种情况,你是不是也这样想?
|
||||
|
||||
然而,真实原因很可能并非如此。根据我多年的经验,确实有小部分人是由于紧张等原因没能通过晋级,但绝大部分人其实是因为**没有意识到这个级别鸿沟的存在**。
|
||||
|
||||
他们没有意识到,自己的能力虽然在当前这个级别做得很好,但确实没有产生质变,没能达到下一个级别的要求。而如果主管也没有认清问题的本质原因,从而有针对性地指导的话,就会导致看起来很优秀的技术人员多次晋级受阻。
|
||||
|
||||
跨越式职级的第二个特征就是,因为级别的差异比较大,所以**晋升的机会比较少**。
|
||||
|
||||
通常情况下,公司会要求申请晋升的员工在当前级别至少工作2年以上。实际上,除了P5升P6之外,在当前级别工作2年就能够晋升下一级别的人已经非常厉害了,大部分技术人员可能需要3年。
|
||||
|
||||
这样算下来,如果你刚毕业是P5,2年升P6,3年升P7,3年升P8,那么升到P8基本上也要9年了。这还是一切顺利的情况,要是有一两次晋级不通过,时间就更长了。
|
||||
|
||||
晋级机会少带来的一个问题就是,**晋级成功对很多人来说就意味着成长停止**。
|
||||
|
||||
这一点在P7阶段特别明显。大家都知道升P8比较难、机会比较少,所以很多同学升到P7后可能就不会去想太多了。因为他们知道,反正只要在P7的岗位把绩效做好,回报一样很丰厚,做起来还得心应手,压力也没那么大。
|
||||
|
||||
跨越式职级的第三个特征,就是**同级别的回报差异是比较大的**。
|
||||
|
||||
比如,你工作2年,评级为P6;而你的同事工作5年,评级可能也是P6。虽然级别一样,但在面试官或者主管看来,这两个P6的能力差异其实还是比较大的,因此在回报上差异也会比较明显。比方说,你们的工资可能相差50%以上。
|
||||
|
||||
有的公司为了区别同级别不同能力的人员,在招聘的时候还会有一个档位区分,比如分为“ABC”或者“初级/正常/优秀”等细分档位。这样做的主要目的在于帮助HR确定合理的**工资区间**。
|
||||
|
||||
因此,如果你面试的时候发现对方公司采取跨越式职级体系,除了确认级别外,你最好还确认一下是否有ABC这种区分,因为不同档位的薪酬是有差异的。
|
||||
|
||||
但是,这种区分一般只在招聘的时候用,不会在内部评级的时候用。如果内部也采用这种方式,整个职级体系就变成了接下来要讲的“阶梯式职级”了。
|
||||
|
||||
## 阶梯式职级
|
||||
|
||||
阶梯式职级,简单来说,就是两个级别之间的差异不大,就像**台阶**一样稳步提升。
|
||||
|
||||
目前国内采取阶梯式职级的公司主要有腾讯、华为和(2020年调整前的)美团等,其中,腾讯的职级体系是典型的阶梯式职级。虽然腾讯在2019年对职级体系进行了调整,不再按照之前“2.1/2.2/2.3”这种方式进行命名,而是改为“6/7/8级工程师”,但这并没有改变它阶梯式职级的本质。
|
||||
|
||||
下面这张表整理、对比了腾讯的新旧职级体系([来源](https://www.infoq.cn/article/z77*1qu3MtVNP5O2kvRW)):
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/e8/3f/e86dac506996ab899d9104553649843f.jpg" alt="" title="网传腾讯职级体系新旧对照表">
|
||||
|
||||
由于业内对腾讯的旧职级体系比较熟悉,而且腾讯新旧职级体系本质上没有改变,都是阶梯式职级,因此我们还是以旧的职级体系为例来说明。
|
||||
|
||||
本科应届生定级一般是1.2,研究生是1.3;毕业1~2年社招是2.1~2.2;毕业3年及以上社招是2.2~2.3;从T3开始就不能简单地按照工作年限推断了,因为T3以上的评级主要看能力和水平。
|
||||
|
||||
阶梯式职级具体是怎么设置的呢?主要通过两个指标:**职级**和**职等**。
|
||||
|
||||
还是以腾讯为例,职级就是“工程师”“高级工程师”这种明显的级别划分,这一点和跨越式职级基本类似;职等就是每个职级内部细分的不同等级,例如同样都是“工程师”,还会划分为“2.1/2.2/2.3”3个等级(有的公司用ABC来表示,例如2A/2B/2C)。
|
||||
|
||||
阶梯式职级的级别差异没有跨越式职级没那么大,并没有明显的鸿沟。因此,阶梯式职级的特征,也和跨越式职级正好相反。
|
||||
|
||||
第一个特征是,**相邻级别差异小。**
|
||||
|
||||
由于阶梯式职级的级别之间的差异没有跨越式职级那么大,基本上按部就班逐级逐等晋升即可,过程相对平稳。通常情况下同一级别内,如果绩效和表现还可以的话,逐等晋升问题都不大;如果表现很优秀,跨等晋升也是可以的,例如可以申请从2.1直接晋级到2.3。
|
||||
|
||||
第二个特征是**,晋升机会更多。**
|
||||
|
||||
因为职级划分得比较细,所以同级别内的等级差异不明显。如果像跨越式阶梯那样2~3年才能晋升一次,那从2.1晋升到2.3要5~6年时间,这明显是不合理的。阶梯式职级基本上每年都可以申请晋升,我当年在松鼠厂的时候,公司每半年都有晋升评级,升到当前等级1年后就可以再次申请晋级。
|
||||
|
||||
第三个特征是,**同级别的回报差异不大**。
|
||||
|
||||
因为级别划分已经比较细了,所以回报的范围区间就会比较小。
|
||||
|
||||
看到这里,你肯定有疑问了:**看起来阶梯式职级比跨越式职级要好很多啊,为何不统一采用阶梯式职级呢?**
|
||||
|
||||
原因在于,虽然阶梯式职级有前面说的各种优点,但它也有一个**核心缺陷**,那就是,**很难客观地定义和评估两个等级之间的差异!**
|
||||
|
||||
我之前所在的松鼠厂,级别和腾讯类似,采用的是2A/2B/2C这种等级。但是如果你仔细研究2A和2B、2B和2C的定义描述,就会发现里面都是一些模凌两可的话。
|
||||
|
||||
比如关于某项能力的描述,2A是“掌握”,2B是“熟练掌握”,2C是“精通”。但实际上在晋级评审的时候,评委对于“掌握”“熟练掌握”和“精通”的区分很难客观。
|
||||
|
||||
因此,可能会出现一种比较奇特的现象:某个技术人员的某个专业技能,在晋升2A的时候问了一遍,在晋升2B的时候又问了一遍,在晋升2C的时候还会再问一遍,而这个人给出的答案可能都一样。
|
||||
|
||||
以Java服务端开发为例,对于JVM的垃圾回收算法和调优,基本上是属于必问的。绝大部分开发人员都会把相关参数、垃圾回收器原理都准备好,因此晋升2A的时候基本上都已经算熟练掌握甚至精通了。所以就算升到2C,他掌握的其实还是这些技能,和2A时并没有明显的差异。
|
||||
|
||||
为了弥补阶梯式职级的这个缺陷,公司可以采取详细定义每个等级的技能要求。还是以Java服务端开发为例,可以在2A阶段只要求“JVM垃圾回收”技能,2C才开始要求“多线程开发”。
|
||||
|
||||
但在实际工作中,这种详细定义的指导意义并不大。因为同级别不同等级的技术人员所做的事情,范围基本都是一致的。实际的开发项目是**按需求来划分任务**的,主管几乎不可能让一个2A的Java工程师不做多线程开发,而将所有的多线程开发任务都分配给2C的工程师。
|
||||
|
||||
阶梯式职级另外一个缺陷和跨越式职级类似,**就是当出现跨级晋升的时候,其实还是有“级别鸿沟”的**。这个鸿沟远远大于同级别不同等级的差距,但由于阶梯式职级的设计,很多人以为他们面临的仍然只是一次普通的晋升。
|
||||
|
||||
以腾讯为例,从2.3到3.1其实是一次大的跨越,而不是一次简单的晋升,它的难度和要求跟从2.2到2.3是完全不同的。
|
||||
|
||||
我当年在松鼠厂时就遇到过很多类似的案例,一些比较优秀的技术人员从2A一路顺利晋升到2C,但从2C晋升到3A却屡屡碰壁。关键是,这些技术人员的绩效和表现还非常优秀,屡次晋升失败对于他们工作积极性和个人自信心的打击还是比较大的。
|
||||
|
||||
所以结合过往我自己晋级、评审和管理的经验来看,我反而推荐跨越式职级这种体系。
|
||||
|
||||
因为确实只有能力发生了质的飞跃后,大家才能比较准确地判断;而同级别内的能力成长,更多的是技能熟练程度的提升,没有那么明显。跨越式职级很早就把这个问题暴露出来,你更容易发现并做出调整;阶梯式职级却把问题隐藏得更深,你反而没那么容易意识到。
|
||||
|
||||
## 小结
|
||||
|
||||
这一讲重点介绍了国内互联网公司中流行的两类职级体系的特点,目的在于帮助你透过表面信息看到职级体系的本质,从而解答你关于晋升的很多疑惑。掌握晋升的游戏规则之后,你才能做出更好的职业规划。
|
||||
|
||||
现在,我们回顾一下重点:
|
||||
|
||||
1. 互联网公司倾向于采用自立体系而不是职称体系。由于阿里和腾讯强大的影响力,国内的互联网公司一般都会对标它们的职级体系。
|
||||
1. 跨越式职级的典型代表是阿里,它的特征是:级别差异大、晋升机会少、同级别回报差异比较大。
|
||||
1. 阶梯式职级的典型代表是腾讯,它的特征是:级别差异小、晋升机会多、同级别回报差异比较小。
|
||||
1. 不管是跨越式职级还是阶梯式职级,都存在一个问题,那就是“级别鸿沟”,它是很多人晋升过程中的拦路虎。当你的晋升遇到瓶颈时,不妨想想自己有没有“本质的提升”,是不是充分地向大家证明了这种提升。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/e2/23/e203df6e278d11bff70c972668a42823.jpg" alt="">
|
||||
|
||||
## 思考题
|
||||
|
||||
这就是今天的全部内容,留一道课后思考题给你吧:你所在的公司目前采取的职级体系是哪种?你在晋升过程中遇到的最大困难或者挑战是什么?
|
||||
|
||||
欢迎你把答案写到留言区,和我一起讨论。相信经过深度思考的回答,也会让你对知识的理解更加深刻。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/5f/34/5f8a0be282e99d171cc2554432bb4534.jpeg" alt="">
|
151
极客时间专栏/大厂晋升指南/晋升体系/02|晋升流程:你需要通过多少“关卡”才能晋升?.md
Normal file
151
极客时间专栏/大厂晋升指南/晋升体系/02|晋升流程:你需要通过多少“关卡”才能晋升?.md
Normal file
@@ -0,0 +1,151 @@
|
||||
<audio id="audio" title="02|晋升流程:你需要通过多少“关卡”才能晋升?" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/19/6d/1950aeef8fcb761e1da0475962723f6d.mp3"></audio>
|
||||
|
||||
你好,我是华仔。
|
||||
|
||||
上一讲我给你介绍了两种常见的职级体系,帮助你从宏观上了解晋升的游戏**总规则**。但是只掌握总规则还不够,你还需要详细地了解,在一次晋升流程中到底需要经过哪些关卡,因为这些关卡直接决定了哪些人能晋升,哪些人不能晋升。
|
||||
|
||||
一次完整的晋升流程,一般可以分为6个阶段:
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/a7/8c/a7289a49bff314b50d3a6ab7ab400d8c.jpg" alt="">
|
||||
|
||||
1. 提名阶段:主管决定要不要提名你去参加晋升。
|
||||
1. 预审阶段:部门对提名的名单进行预审,如果你跟其他竞争者PK失败,就失去了晋升机会。
|
||||
1. 评审阶段:评委团对你进行评审,考察你的能力有没有满足要求。
|
||||
1. 复审阶段:部门对评审结果进行复审,确认你的晋升结果。
|
||||
1. 审批阶段:复审的结果上报高层审批,审批通过之后,你的晋升结果就最终确定了。
|
||||
1. 沟通阶段:主管或HR跟你沟通晋升结果。
|
||||
|
||||
在这6个阶段中,你直接参与的是“提名阶段”“评审阶段”和“沟通阶段”。其中“评审阶段”是最关键的,它在很大程度上决定了晋升是否能通过,但是在“提名阶段”“预审阶段”和“复审阶段”,你也可能会被刷掉。
|
||||
|
||||
如果公司要完整并且严格地执行这6个阶段,需要投入很大的人力成本,所以很多公司可能会删减或者简化某些阶段。具体的做法各有不同,今天这一讲我就不展开了。
|
||||
|
||||
接下来,我会为你详细地介绍每个阶段常见的操作方式。
|
||||
|
||||
## 提名阶段
|
||||
|
||||
整个晋升流程的起点就是提名阶段,相当于九九八十一难的第一关。
|
||||
|
||||
### 硬性条件
|
||||
|
||||
如果你想申请晋升,至少要满足以下4个条件:
|
||||
|
||||
1. **绩效条件**:你的绩效不能差,至少要达到“正常”水平。你要是绩效垫底,恐怕就不能参加晋升了。
|
||||
1. **年限条件**:你在当前级别的工作年限,必须满足晋升的硬性规定。不同职级体系要求不同,阶梯式职级一般要满1年,跨越式一般要满2年。
|
||||
1. **红线条件**:有的公司有内部处罚的政策,要是违反这些政策,你就会被取消当年甚至几年之内的晋升资格。你也需要满足这一类涉及红线的条件。
|
||||
1. **附加条件**:有的公司为了鼓励员工重视某些事情,可能会将它跟晋升挂钩,最典型的就是专利。比如,公司规定,晋升到某个级别必须要有专利,没有专利就一票否决。所以你也需要满足这类条件。
|
||||
|
||||
不过,并不是只要满足这四个条件,你就一定能够申请晋升。因为它们只是硬性条件,至于你的能力有没有达到下一级别的要求,没法硬性规定,只能由人来判断。
|
||||
|
||||
在提名阶段,做这个判断的人就是你的直接主管,而判断结果可能会出现五种不同的情况,我都总结到了下面这张图里:
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/5c/b8/5c672b61a4yy4cd52693b02562fe39b8.jpg" alt="">
|
||||
|
||||
如果你和主管都认可,那你直接准备后续的晋升流程就行了;都不认可,那你就继续努力。这两种情况是最容易处理的。
|
||||
|
||||
如果自己不认可,但是主管认可,他会过来鼓励你,如果鼓励完你又有信心了,那么不妨去试一试。可要是鼓励完,你还是不敢申请,我建议这次就不要勉强自己了。毕竟后面写材料和答辩的过程都是你本人亲自参与,如果你自己都不相信自己的话,是很难做好的。
|
||||
|
||||
### 最难处理的情况
|
||||
|
||||
最难处理的情况是什么呢?那就是**你认为自己能力够了,但主管不认可**。
|
||||
|
||||
这个时候要怎么办呢?我建议你主动找主管开诚布公地谈一次,听一听他对你的真实评价。要是他真的有充分的理由判断你的能力不足,你就要请他给出**明确的指导意见**,以及后续**有针对性的工作安排**。
|
||||
|
||||
举个例子,主管如果只是简单地说“你要提升Java编程能力”,这是不够的。你可以要求他明确地告诉你,提升哪方面的Java编程能力,是虚拟机原理和调优,数据结构和算法,还是多线程?除此之外,他还应该说明未来一段时间给你安排什么样的工作,才能让你提升这些能力。比如要提升虚拟机原理和调优能力,可以给你安排线上问题处理和线上性能优化这样的工作。
|
||||
|
||||
### 不明确的情况
|
||||
|
||||
还有一种情况,也值得专门提一下,那就是**主管不太好明确判断**的时候。
|
||||
|
||||
主管之所以会纠结,是因为一方面他担心自己会不会太严格,导致你错失了晋升机会,结果别的团队跟你水平差不多的员工都晋升了;另一方面,他也会担心自己会不会太宽松,结果你在后续的晋级过程中表现不太好,影响团队声誉(我确实遇到过某个团队提名了4~5个候选人,最后却一个都没通过的情况)。
|
||||
|
||||
所以这时候,你要主动跟他提出晋升想法,表达积极进取的意愿和规划。要是当年团队内部的提名较少,就有机会优先补位;如果当年团队提名人数已经超额了,那么下一次晋升他也会优先考虑你。
|
||||
|
||||
## 预审阶段
|
||||
|
||||
提名之后就是预审。预审阶段主要是针对提名晋升的名单,进行部门内的一次**横向拉通对比**。
|
||||
|
||||
这样做的目的主要有两个,第一个是**防止主管放水,提名太多**。
|
||||
|
||||
在提名阶段,你的主管可能因为管理压力,没有直接拒绝你的晋升请求。在预审阶段公司就可以识别这种情况,因为负责预审的人会进行横向比较。如果两个团队规模和绩效都差不多,其中一个团队的提名人数大大超出另外一个,对应的主管必须给出强有力的原因,否则就很容易被其他主管质疑是否在放水。
|
||||
|
||||
第二个目的则是**防止主管之间的能力评价标准相差太远**。
|
||||
|
||||
刚才我也提到过,能力评价本身其实是比较主观的,每个人的标准可能不一样。也许A主管的标准比较严格,B主管的标准比较宽松,这样A团队的员工就比较吃亏了。通过横向拉通对比,公司基本上就能统一各个团队的能力评价标准,尽量做到公平公正。
|
||||
|
||||
因此,如果你想要提名晋升,主管也同意了,但是一段时间后他又说你现在的能力还达不到晋升要求,那么基本就可以确定,你是在“预审阶段”被刷掉了。
|
||||
|
||||
预审通常有两种方式,书面预审和会议预审。
|
||||
|
||||
书面预审一般用于P7以下级别的晋升,由管理者自己通过提名材料来审核。他会查看材料中关于你的能力和项目的描述,再结合自己平时对你的了解来评估。所以,提名材料写得好不好就很关键了,后续课程中我也会讲到提名材料的写法。
|
||||
|
||||
会议预审用于P7及以上级别的晋升,由管理者组织会议,让其他主管一起来审核。主管需要介绍自己提名的员工,然后接受其他人的“挑战”。因此,各个主管对你的了解程度就很关键。这就意味着你在平时的工作中,不要以为对方不是你的主管就可以不理他,甚至直接“怼”他,毕竟有人的地方就有江湖。
|
||||
|
||||
## 评审阶段
|
||||
|
||||
整个晋升流程中**最核心的阶段**是评审阶段。你需要向**评委团**展现自己的能力,并且经受他们的考察。这个阶段的标准流程可以分为5个环节:
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/88/04/888dd36yyd7af71bb4b5b59346d80804.jpg" alt="">
|
||||
|
||||
整个评审阶段和多人面试基本类似,你需要先准备答辩PPT(材料准备),然后面对评委团(3个以上评委)先进行自述,展现自己的亮点(晋升自述)。
|
||||
|
||||
你讲完后,会有多个评委来通过问答的方式来对你进行考察,验证和判断你是否达到了晋升要求(晋升答辩)。答辩完成后,评委会指出你的优缺点,并提出后续改进建议(能力评价,有的公司可能没有这个环节)。对你来说,到这里这次答辩就结束了。
|
||||
|
||||
最终,评委团基于答辩情况以及评委们的判断,做出你是否晋升通过的判断,但这个环节的结果还不是最终晋升结果(结果确定)。评委团可以通过两种方式来给出评审结果:集体讨论和独立投票。
|
||||
|
||||
**集体讨论**是指,几位评委现场讨论你的这次答辩有没有通过。这种方式有利于评委之间互相验证,但可能出现**“熟人”**问题。有“熟人”帮你说好话和有“熟人”给你说坏话,结果会差别很大,总的来说,“熟人”问题可能会影响结果的公平性。
|
||||
|
||||
**独立投票**是指,几位评委各自单独给出是否通过的意见,最后系统根据“多数票原则”判定你的晋升有没有通过。
|
||||
|
||||
这种方式可以避免“熟人”问题,但是却可能出现**“隔行如隔山”**问题。如果有专家的业务领域跟你差别太大,可能很难准确评估你的能力。比如你是做金融业务的,现在让一个做社交应用的专家来评估,结果就可能出现比较大的偏差。
|
||||
|
||||
所以,**评委团的不确定性**是你遇到的第一个和运气相关的因素。你无法选择晋升评委,只能尽力提升自己的能力,争取将评委团的不确定性的影响降到最低。
|
||||
|
||||
## 复审阶段
|
||||
|
||||
评审阶段的结果出来之后,公司还会做一次部门级的拉通分析,这就是复审。
|
||||
|
||||
复审阶段主要是通过**总体的数据**来判断晋升情况,这个数据一般是**晋升通过率**。各个公司会根据实际情况给出一个指导性的参考值,只要不偏离太远,都是可以的。
|
||||
|
||||
但是如果偏离太远,公司就会再次对晋升结果进行调整。因此,复审阶段有两个因素可能影响你的晋升结果。
|
||||
|
||||
第一个因素是,公司给出的通过率参考指标可能存在**“大小年”**的现象。比如2018年的通过率比较高,2019年可能就会调低一些。如果你正好在2019年参与晋升,也许就会受到影响。
|
||||
|
||||
**公司通过率指标的不确定性**是你可能遇到的第二个和运气相关的因素。
|
||||
|
||||
复审阶段第二个影响你晋升结果的因素是,如果你的水平处在中间位置的话,可能因为部门通过率调控而被刷下来。
|
||||
|
||||
比如3个评委当中只有2个认为你可以通过晋升,这个时候,就算公司整体的晋升通过率是正常的,但如果你所在的部门晋升通过率太高(显著高于其他部门),也有可能导致你被刷下来。
|
||||
|
||||
**部门通过率调控的不确定性**就是晋升者可能遇到的第三个和运气相关的因素。
|
||||
|
||||
复审阶段的这两个运气因素,你同样不能控制,只能尽力提升自己的能力,争取避免成为被调控的对象。而如果晋升不通过,也不要过于悲观。因为这一方面说明,自己的能力确实还不是毫无争议的;另一方面,只要你持续地提升自己的能力,多参加几次晋升,总有一次运气会好的。
|
||||
|
||||
## 审批阶段
|
||||
|
||||
复审之后,公司层面会对各个部门上报的晋升结果做最终的确认,然后确定薪资涨幅和股权激励之类的方案。这部分的操作已经不是一般员工能够介入的范围了,你就不用关心了,只要知道有这么一个阶段就可以了。
|
||||
|
||||
## 沟通阶段
|
||||
|
||||
晋升流程的最后一步就是沟通阶段,主管(有时候会拉上HR一起)会把最终的晋升结果反馈给你。你要是顺利通过了,这次沟通肯定是比较愉快和顺畅的;但你要是不幸没有通过,主管的沟通压力就又上来了。
|
||||
|
||||
好在走到这一步,大部分申请者对于自己能否通过,心里还是有数的,所以整体来说,沟通不算太难。
|
||||
|
||||
不过,无论你的晋升通过还是不通过,你的主管都需要明确地给出指导意见,并安排相应的工作来帮助你成长。如果他忘了,记得提醒他。
|
||||
|
||||
## 小结
|
||||
|
||||
这一讲,我为你介绍了在一次完整的晋升流程中,你要经历哪些阶段的哪些考验。一次成功的晋升就像西天取经一样,要经过重重关卡的磨练。
|
||||
|
||||
现在,我们回顾一下这一讲的重点:
|
||||
|
||||
1. 晋升流程分为个6阶段,你直接参与的是“提名”“评审” 和“沟通”这3个阶段。其中“评审阶段”是最关键的,很大程度上决定了你能不能晋升。不过在“提名”“预审”“评审”和“复审”这4个阶段中,你都有可能被刷下来。
|
||||
1. 晋升路上还有一些跟运气有关的因素,主要有三个,分别是评委团的不确定性,公司通过率指标的不确定性,还有部门通过率调控的不确定性。
|
||||
1. 不要以为对方不是你的主管你就可以不理他,甚至直接怼他,有人的地方就有江湖。平时给其他部门的合作伙伴留个好印象,晋升的时候也许有意想不到的帮助。
|
||||
|
||||
## 思考题
|
||||
|
||||
这就是今天的全部内容,留一道课后思考题给你吧:你有晋升失败的经历吗?你觉得是在哪个阶段被刷了,可能的原因是什么?
|
||||
|
||||
欢迎你把答案写到留言区,和我一起讨论。相信经过深度思考的回答,也会让你对知识的理解更加深刻。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/fc/d9/fc220993f691a81cd5902926f663fed9.jpeg" alt="">
|
163
极客时间专栏/大厂晋升指南/晋升体系/03 | 晋升原则:什么样的人更容易晋升?.md
Normal file
163
极客时间专栏/大厂晋升指南/晋升体系/03 | 晋升原则:什么样的人更容易晋升?.md
Normal file
@@ -0,0 +1,163 @@
|
||||
<audio id="audio" title="03 | 晋升原则:什么样的人更容易晋升?" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/58/eb/58459b57a3672eb1100e0aa6a5a6b9eb.mp3"></audio>
|
||||
|
||||
你好,我是华仔。
|
||||
|
||||
当你了解了晋升的游戏规则和通关流程之后,自然就会产生一个疑问:我应该怎么做才能更快地晋升?
|
||||
|
||||
其实这门课后续的所有内容,都是在回答这个问题。但毕竟晋升涉及的因素太多了,不同的行业、公司和团队,你本人的经历、性格和爱好,可能都会影响晋升策略的选择。
|
||||
|
||||
虽然大部分的情况下,你可以直接套用我在这门课中传授的方法,但总是会有一些特殊情况,你需要靠自己来做出判断和选择。
|
||||
|
||||
所以,我给你总结了三条晋升的核心原则,告诉你什么样的人更容易晋升成功。当你在准备晋升的过程中,遇到困惑、挫折等各种问题的时候,就可以根据你的实际情况来逐一对比这三条原则,找到自己做得不够好的地方,然后有针对性地进行提升。
|
||||
|
||||
## 主动原则:主动做事
|
||||
|
||||
工作要积极主动,这句话你一定听过吧,但你对它的理解真的准确吗?很多人,尤其是刚进入职场的同学,可能会以为“服从命令听指挥”“领导指哪打哪”就是积极主动,结果反而容易养成两个不好的习惯。
|
||||
|
||||
第一个不好的习惯是,认为主管肯定会帮你搞定晋升。
|
||||
|
||||
你可能非常信任主管,认为自己只要把主管安排的任务做好,晋升就是水到渠成的事情。所以你就算觉得现在分配的任务对自己的成长帮助不大,也不会主动跟主管沟通,而是认为“他这么安排肯定是有道理的”“也许过一段时间他就会给我安排新的任务”。这其实是不对的。
|
||||
|
||||
首先,并不是每个主管都会关注组员的成长。主管的做事风格可能有很多种。
|
||||
|
||||
- 有的主管特别关注业务目标是否达成,所以会花很多时间跟产品经理和项目经理沟通交流;
|
||||
- 有的主管特别关注团队形象,要求所有对外承诺的事情都一定不能延期、一定不能出问题,所以会特别重视进度、质量和风险等情况的跟进和监控;
|
||||
- 有的主管特别关注自己的职位爬升,所以团队成员对他来说,只是一种可利用的资源……
|
||||
|
||||
所以,如果你遇到的恰好是不关注组员成长的主管,就不要等着他给你分配任务了。不然你就只能长时间地留在当前的级别,做他手底下的“工具人”。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/86/2d/86d64b07e6c2d7b854162463a784302d.jpg" alt="">
|
||||
|
||||
其次,就算主管关注组员的成长,他的判断也有可能跟你的判断不一致。
|
||||
|
||||
比如主管认为你还需要在当前岗位继续锻炼,而你却觉得自己应该尝试新的挑战了。这时候如果你不去找他沟通,他还会继续给你安排熟悉的重复任务。这样你肯定很没意思,工作状态不会太好,工作积极性也不会太高。
|
||||
|
||||
所以,如果你觉得自己的岗位没有太多挑战和能力提升空间的时候,就不要等着主管给你分配任务了。不然你身上的潜力就激发不出来,没法以最快的速度晋升。
|
||||
|
||||
第二个不好的习惯是,**被动接收信息**。
|
||||
|
||||
你可能认为把自己的本职工作做好就够了,其他事情自然有对应岗位的人去负责,因此你很少去主动了解很多工作相关的信息。比如下面这些信息,对于技术人员来说,它们不属于自己岗位职责的范畴,但是在晋升的时候,它们却是评判技术人员综合能力的重要考察内容:
|
||||
|
||||
- 业务功能上线后业务效果如何?
|
||||
- 业务效果不好的可能原因是什么?
|
||||
- 整体的业务机房的部署结构是什么样的?
|
||||
|
||||
这些信息,有的需要找产品运营要数据,有的需要跟业务负责人探讨,还有的需要和另外的团队交流,都需要你主动去找机会才有可能获取的。
|
||||
|
||||
主动规划工作任务,主动跟别人了解更多信息,合起来就是我说的**主动做事**。**主动做事的人,比等着别人安排的人更容易晋升**,这就是我总结的第一条原则,**主动原则**。
|
||||
|
||||
掌握主动原则之后,我们就知道要具体要怎么做了。
|
||||
|
||||
第一,我们要主动找主管沟通工作。
|
||||
|
||||
不管主管是什么风格,你都应该**定期或者不定期**地找他沟通关于工作任务的想法和意愿。一方面是听听他对自己的看法,获取指导建议;另一方面,你也可以借此机会了解更多关于团队、业务和部门的信息,有机会的情况下尽量主动承担有挑战性的工作。
|
||||
|
||||
不要以为主管会自己把知道的所有信息都一一跟组员分享。很多隐藏信息、非正式信息和小道信息,如果你不主动找他聊天,他不一定跟你讲的。
|
||||
|
||||
第二,我们要主动找别人沟通,了解更多信息。
|
||||
|
||||
很多人害怕主动找别人要东西,可能有性格方面的原因,但更主要的原因还是动力不足。如果你能够意识到主动沟通带来的价值,很多时候就敢放开手脚干了。这就像一个笑话说的,一个人问:“打一巴掌给100块,你干不干?”结果另一个人回答说:“我能让你打到破产。”
|
||||
|
||||
怎么获得动力呢?有个方法特别有效,就是从晋升答辩的角度来看。每当你想退缩的时候,就可以问问自己:“如果评委问到这个问题,自己能回答上来吗?”
|
||||
|
||||
事实上,晋升答辩的时候评委很可能会对这些问题感兴趣,比如“这个业务上线后效果怎么样?”“没有达到预期,主要原因是什么?”“机房的部署结构是什么样的?”“新加坡机房跟美国机房怎么同步?”……想到这一层,你就会逼着自己去沟通了。
|
||||
|
||||
## 成长原则:不断挖掘成长点
|
||||
|
||||
掌握了主动原则之后,你是不是已经壮志满怀,准备好大包大揽地干活儿了呢?先等一下,这里可能还有两个思维陷阱等着你。
|
||||
|
||||
第一个陷阱是,**以为事情做得多,自然就能晋升。**
|
||||
|
||||
这个陷阱很有迷惑性。不过你仔细想想,一匹马拉磨拉了10年,另一匹马则是征战10年,这两匹马的经验能一样吗?虽然拉磨的马走的距离可能更长,但如果征战的马见过的场面一定更复杂、更多样。
|
||||
|
||||
其实人也是这样。只做自己会做的事情,不断地重复,你只会变成熟练工,而不会成为技术专家。所以,不要把1年的工作经验重复10年,而要真正积累10年的工作经验。
|
||||
|
||||
第二个思维陷阱更有迷惑性,那就是**以为事情做得好,自然就能晋升。**
|
||||
|
||||
很多人都有一种朴素的想法:“我把老板安排的任务做完,保证效率和质量,拿到好的绩效,晋升肯定没问题。”结果,他们虽然拿到了好的绩效,但晋升却屡屡碰壁。
|
||||
|
||||
为什么会出现这种情况呢?因为不同级别的能力要求是有本质的区别的,而不仅仅是熟练度的区别。能够把事情做好,只能说明你已经熟练掌握当前级别所要求的能力,但并不一定意味着你的能力就自动达到下一职级的要求了。
|
||||
|
||||
现在,你可能觉得更乱了,怎么多做事、把事情做好反倒不对了呢?其实,多做事、把事情做好,当然是有用的。但它们的作用,主要体现在帮你拿到更好的绩效,更多的奖金和一定程度的工资提升。至于晋升,不光要看功劳和苦劳,更要看成长。
|
||||
|
||||
所以,**一边做事一边挖掘成长点、提升自己能力的人,比光顾着做事的人更容易晋升**,这就是我总结的第二条原则,**成长原则**。
|
||||
|
||||
现在我们再来看看,基于成长原则,我们做事时正确的做法是什么。
|
||||
|
||||
如果现在的工作,你已经可以得心应手地轻松完成了,就应该尝试更高难度、更高复杂度的事情了,而不是一味地刷熟练度,沉迷在自我感觉良好的状态里。
|
||||
|
||||
比如你一直做业务开发,已经成为了组里的骨干,不但效率高,而且质量又好。那么你就可以试着完成方案设计、架构设计、架构重构和系统优化等工作。
|
||||
|
||||
另外,不管事情做好了还是没做好,你都应该多做复盘总结,找到可以提升优化的点。
|
||||
|
||||
对于踩了坑、犯了错的事情,你肯定知道要复盘,毕竟教训的印象是非常深刻的;但是做得顺利的事情,你可能做完就完事了,不会主动去挖掘可以成长的点,这样无形中就失去了很多成长的机会,即使把事情做好了,能力提升也不大。
|
||||
|
||||
## 价值原则:学习为公司产出价值的技能
|
||||
|
||||
掌握了成长原则之后,你是不是又像“打了鸡血”一样,准备好好学习,提升几项技能了呢?别着急,我先给你讲一个真实的故事。
|
||||
|
||||
有一次,一个老同学问我:“华仔,你是怎么学习编译原理的?”
|
||||
|
||||
我觉得有点奇怪,因为他是做Android App业务开发的,怎么会想到要学编译原理呢?于是,我们有了下面这段对话。
|
||||
|
||||
我问:“你怎么想到学编译原理了?”
|
||||
|
||||
他说:“编译原理是所有编程语言的基础,这个算基础的技术能力吧,我觉得肯定要学。”
|
||||
|
||||
我又问:“你们什么时候会用到编译原理呢?”
|
||||
|
||||
他想了一会,说:“好像没有用到的时候。不过我觉得,多学点技术总没坏事,说不定哪天就用上了。”
|
||||
|
||||
我接着问:“那你学了多久了,效果怎么样?”
|
||||
|
||||
他叹了口气,说:“学了半年了,但是感觉没学懂,所以来问问你,看看你有什么经验。”
|
||||
|
||||
我说:“我也不懂,而且我建议你别学了。编译原理虽然是基础技术,但它跟你现在的工作基本没有什么关系,学习编译原理并不能让你把开发做得更好,或者给你的业务带来新的有用的功能。”
|
||||
|
||||
我想你一定能看出来,这位老同学很有上进心,也非常努力。但是很遗憾,编译原理这个技能对他目前的工作其实没什么帮助。换句话说,如果**从晋升角度考虑**,他学习的技能无法为当前的公司创造价值,这六个月的时间其实白白浪费掉了。
|
||||
|
||||
为什么我会这么说呢?其实你站在公司的角度来看,就很好理解了。
|
||||
|
||||
公司设计职级体系的初衷,是为了衡量不同员工的能力级别,然后根据级别来制定相应的薪酬、福利、管理等制度,同时鼓励员工尽量提升自己的能力,为公司产出更大的价值。
|
||||
|
||||
这里面有两个关键点,**能力级别**和**公司价值**,但是大部分人都只关注了能力级别,而忽略了公司价值这个点。
|
||||
|
||||
这也是晋升和面试最大的区别之一。面试的时候,面试官主要考察你的能力级别,因为这时候没有办法准确评估你能为公司带来的价值;但是在晋升的时候,不论你把能力吹得多么天花乱坠,如果不能体现在对公司价值的实际产出上,那一切都是废话。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/2e/26/2e777d307d0dc283db0ec30995d43926.jpg" alt="">
|
||||
|
||||
所以,也许你为了晋升,花了很多的时间和精力来提升一些“很重要”“很基础”的能力,但实际上它们可能对你的晋升根本起不到什么作用。学习编译原理,研究Linux内核源码,天天刷LeetCode题目,关注人工智能发展前沿……这些都是技术人员提升能力的时候经常踩的坑。
|
||||
|
||||
当然,我绝对不是说这些技能一定没有用,任何人都不应该学;而是说如果你想晋升,在投入时间和精力学一项技能之前,不妨先思考一下,你学了这个,能为公司带来什么。
|
||||
|
||||
**让能力为公司产出价值的人,比空有一身能力的人更容易晋升**。这就是我总结的第三条原则,**价值原则**。
|
||||
|
||||
所以,能为公司产出价值的能力,才是值得优先学的能力。现在我们以“人工智能”为例,用价值原则来判断一下,如果你的时间很宝贵,还值不值得学。
|
||||
|
||||
- 如果你是P5/P6级别,做Android App业务功能开发,那么用不着学人工智能,因为你现在主要工作还是把开发任务做好。
|
||||
- 如果你是P7/P8级别,是带一个团队做Android开发的Team Leader,或者是负责App架构设计的技术专家,可能就有必要学人工智能了,因为你需要规划和思考团队与业务下一步的技术演进方向跟实施步骤。
|
||||
- 如果你是P9级别,那么不管是什么技术方向,肯定都要了解人工智能,因为这是一个新的技术领域和方向,而新的技术往往会带来业务上质的突破。
|
||||
|
||||
价值原则除了告诉我们某项技能值不值得学以外,还能告诉我们要学到什么程度。还是以“人工智能”为例,不同的人来学,学习的方法和深度也是不一样的,一定要避免陷入“学习等于看源码”这个误区。
|
||||
|
||||
- 如果你是做算法的,人工智能应用场景、算法原理、框架源码都需要去学习;
|
||||
- 如果你是做App开发的,学习的重点可能就是人工智能的原理和应用场景了;
|
||||
- 如果你是P9级别,学习的重点可能是人工智能的基本原理、行业的发展现状、成功和失败的案例,还有相关的产业链信息。
|
||||
|
||||
## 小结
|
||||
|
||||
现在我们做个总结,这一讲我为你介绍了三条晋升的核心原则:
|
||||
|
||||
1. 第一条原则是主动原则,主动做事的人,比等着别人安排的人更容易晋升。所以你应该定期或者不定期地主动找主管沟通,交流关于工作任务的想法和意愿,寻求机会;同时,你也要主动找同事沟通,了解更多工作相关信息。
|
||||
1. 第二条原则是成长原则,一边做事一边挖掘成长点、提升自己能力的人,比光顾着做事的人更容易晋升。所以如果你已经能得心应手地完成现在的任务,就应该主动跳出舒适区,尝试更高难度和更高复杂度的事情;同时,不管事情做好了还是没做好,你都应该多做复盘总结,找到可以提升优化的点。
|
||||
1. 第三条原则是价值原则,让能力为公司产出价值的人,比空有一身能力的人更容易晋升。所以,如果你的时间很宝贵,就应该优先学能为公司产出价值的技能。
|
||||
|
||||
当你理解了这些原则,并且在实际做事过程中有意识地去应用这些原则之后,既能够为公司创造更大的价值,拿到好的绩效;又能够快速地提升自己的能力,满足晋升的要求。下次晋升的不是你,还能是谁呢?
|
||||
|
||||
## 思考题
|
||||
|
||||
这就是今天的全部内容,留一道课后思考题给你吧:你觉得自己日常工作中违背了这一讲提到的哪些原则,具体是如何表现的?
|
||||
|
||||
欢迎你把答案写到留言区,和我一起讨论。相信经过深度思考的回答,也会让你对知识的理解更加深刻。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/a9/25/a92acc60caee2f9716d436147203e325.jpeg" alt="">
|
129
极客时间专栏/大厂晋升指南/晋升体系/04 | 晋升逻辑:别人怎么判断你有没有达到晋升要求?.md
Normal file
129
极客时间专栏/大厂晋升指南/晋升体系/04 | 晋升逻辑:别人怎么判断你有没有达到晋升要求?.md
Normal file
@@ -0,0 +1,129 @@
|
||||
<audio id="audio" title="04 | 晋升逻辑:别人怎么判断你有没有达到晋升要求?" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/1f/42/1fa0b01d776b9e3df407b8764ca6f642.mp3"></audio>
|
||||
|
||||
你好,我是华仔。
|
||||
|
||||
上一讲我介绍了晋升的三大原则,分析了什么样的人更容易晋升,帮你明确了努力的方向。但是努力提升之后,你的能力到底有没有达到晋升的要求呢?
|
||||
|
||||
也许你自己信心满满,但评审的人不一定认可你的能力。如果你的直接主管不认可,你连被提名的机会都没有;如果部门内的管理者不认可,你在预审的时候就会被刷掉;而如果评委团不认可,你在评审阶段还是会倒下。
|
||||
|
||||
那么,什么样的能力水平才经得起不同评审者和不同视角的考核,怎样才能几乎没有争议地顺利晋升呢?
|
||||
|
||||
针对这个问题,我将用连续3讲的篇幅为你给出完整的回答。今天的第4讲,先带你认清判断能力最本质的**底层逻辑**;第5讲,会教你掌握一套把能力要求具体化的**通用模型**;第6讲,会带你纵向地透视不同层级对能力的**核心要求**。
|
||||
|
||||
## 一些看似客观的常见做法
|
||||
|
||||
接下来,我们就从判断能力的一些常见做法开始讲起。
|
||||
|
||||
在[第2讲](https://time.geekbang.org/column/article/313540)介绍晋升流程的时候,我曾经说过,在评审阶段正式判断你的能力是否达到晋升要求的是**评委团**。
|
||||
|
||||
但是在这之前的提名和预审阶段,判断你能力的人,是你的主管,可能还有HR、经理和总监等。这些人并不会像评委那样通过将近一个小时的时间来仔细确认你有没有达到晋升要求,而是会结合你的晋升材料,凭主观感觉来判断。
|
||||
|
||||
实际上,**主管等人**通过主观感觉来判断你能力的时候,他们的心理压力也很大。因为没有统一的客观标准,就很容易出现**说服力不足**的问题。
|
||||
|
||||
对于没有掌握正确判断方法的人来说,为了避免在提名或预审阶段引起争议,他们可能会采取简单粗暴的逻辑,**完全以客观条件为标准**。常见的做法,有下面3种。
|
||||
|
||||
第1种是以**当前级别的年限**为标准。比如同样都是P6,你在这个级别待了2年了,而坐你隔壁的老王已经待了4年了,你的主管可能会优先提名老王去晋升。这也是很多人私底下吐槽的“优先保老员工”的现象。
|
||||
|
||||
第2种是以**工作年限**为标准。它跟第1种有点像,区别在于它看的是总的工作年限,而不只是在当前级别的工作时间。这也有一定的合理性,因为一些社招员工虽然来公司时间不长,但是他们之前就已经积累了很多工作经验,跟新人还是不一样的。
|
||||
|
||||
第3种是以**绩效**为标准。简单地说,就是把绩效跟能力直接挂钩,绩效好就可以去申请晋升。这样做最方便,因为绩效结果是明确的。
|
||||
|
||||
你可能对这些做法很熟悉,甚至觉得很有道理,但其实它们都只是**看似客观**而已。
|
||||
|
||||
因为年限和绩效这些条件虽然都是确定的、可以量化的,但是它们跟能力并没有直接的正相关关系。在晋升体系完备的大公司,我从来没见过评委最后靠这些条件,来判断申请者的能力有没有达到晋升要求;相反,评委们在最后总结的时候,会特别提醒主管以下两个要点:
|
||||
|
||||
<li>
|
||||
**无论什么年限都不是我们判断能力的标准**。花1年时间掌握某项技能然后重复9年,和10年时间不断在提升,两者的能力差距是巨大的。
|
||||
</li>
|
||||
<li>
|
||||
**绩效不能等同于能力。**绩效好有很多种可能的原因,能力强只是其中之一。更何况,公司已经在工资/奖金/股票方面对绩效进行了回报。至于晋升,它是对“能力提升”的一种认可,不能拿来作为绩效的回报。换句话说,**绩效关注的是业务结果,晋升关注的是能力提升。**某些人可能在当前级别做事得心应手,可以拿到很好的绩效,但是能力并没有本质的提升。
|
||||
</li>
|
||||
|
||||
## 第一条逻辑:提前做下一级别的事
|
||||
|
||||
既然如此,在“互联网大厂”,评委们怎么判断你有没有达到晋升的要求呢?其实很简单,他们会审查你做过的事情,看看是不是体现了**下一级别**需要的能力。
|
||||
|
||||
这就是我分享的第一条晋升逻辑:**在当前级别做下一级别事情的人,才有机会晋升**。
|
||||
|
||||
这条逻辑可能会颠覆你对晋升和工作任务安排的认知。因为按照大部分人的想法,什么级别就做什么事情,只要做好了当前级别的事情,就可以申请晋升,然后到下一级别再去做下一级别的事情。
|
||||
|
||||
然而实际情况是,你得提前做下一级别的事情,做好了才能申请晋升。这也就解释了为什么很多P6和P7做的事情差不多的现象。
|
||||
|
||||
所以,如果要判断自己是不是能够申请晋升了,一种简单有效的方式是,**看你做的事情是不是和下一级别的人类似。**想晋升的P6就对比P7,想晋升的P7就对比P8……以此类推。
|
||||
|
||||
举个例子,在很多大厂,如果你是P6级别的技术人员,想要申请P7,必须要“带过小项目或者小团队”(3~5人左右)才有机会。如果你一直只是完成别人安排的项目任务,就算做得很熟练,也很难获得提名;就算主管帮你提名了,答辩的时候也很难通过。
|
||||
|
||||
## 第二条逻辑:做好当前级别的事
|
||||
|
||||
学完第一条晋升逻辑,你可能会想到一条晋升的捷径:**晋升通过之后,立刻跟主管要求安排下一个级别的工作**。这样你就可以按照下一级别的要求来提升自己的能力,很快就能迎来下一次晋升。
|
||||
|
||||
想的是挺美的,但是很遗憾,现实中这样做是行不通的。原因在于,就算是同一个级别,不同的人能力也还是有差异的。主管不敢把下一个级别的事情直接交给刚晋升的人来做。
|
||||
|
||||
所以我们还需要补充第二条晋升逻辑:**只有把当前级别的事情做好了,才有机会晋升**。
|
||||
|
||||
你可能会有疑问:我都晋升这个级别了,肯定已经具备这个级别的能力了,把这个级别的事情做好,不是理所当然的吗?
|
||||
|
||||
其实,真实的晋升逻辑并不是这样理解的。晋升成功只是意味着你的能力达到了当前级别的**基础**水平,但还不一定有**熟练**和**精通**的程度。如果你还想要晋升到下一个级别,就必须先在当前级别达到精通。
|
||||
|
||||
- 如果是**跨越式**职级体系,同级的人其实会被分为几档,例如“P6-/P6/P6+”、“T2C/T2B/T2A”。(也有的公司会分为ABCD四档,但B和C的差异很难确定,所以我不推荐这种方式,这里也不多做介绍了。)
|
||||
- 如果是**阶梯式**职级体系,同级不同等的人本来就是按照“基础”“熟练”和“精通”来区分的,比如腾讯旧职级体系下的T2.1/T2.2/T2.3。
|
||||
|
||||
虽然这些档次不一定在管理系统中体现出来,但是在HR和主管的心里一般都会有这样一个级别的划分的。下图展示了这种划分的方式:
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/a8/e0/a89dacf914fcb5d2f1b68ea2e0ccfde0.jpg" alt="">
|
||||
|
||||
我们可以看到,只有到了精通的程度,你才有机会晋升下一级别。换句话说,只有到了精通的程度,主管才会把下一级别的任务安排给你。这就像游戏王者荣耀一样,在星耀段位内部,还分了星耀V到星耀I一共5个等级,只有星耀I的玩家才能去打王者段位的晋级赛。
|
||||
|
||||
这也是我把P6+和T2.3级别标注为“精通&提升”的原因。因为这个级别的人,既要做当前级别的事情(因为达到了精通的程度,做起来效率高),又要去做下一级别的事情(因为达到了精通的程度,要考虑晋升了)。
|
||||
|
||||
所以你刚完成晋升之后,不要立刻想着做下一个级别的事,急着晋升到下一级别;而应该先考虑怎么把当前级别的事情做好,把当前级别的能力提升到“精通”的程度。
|
||||
|
||||
## 基础、熟练和精通的区别
|
||||
|
||||
刚才我介绍的这两条晋升逻辑,都涉及一个关键的问题:**怎么区分基础、熟练和精通呢?**
|
||||
|
||||
这其实是一个世界难题,到目前为止,还没有明确客观的标准可以直接套用。不过呢,我根据自己的经验和理解,总结出了一套相对比较容易操作的标准。我来简单描述下这套标准,你可以看看是不是很好用。
|
||||
|
||||
**基础意味着“会做”**。如果你会做某个级别要求的事情,就说明已经具备了基础能力。当然,这里的“会”是指能够**独立自主**地完成,而不是别人想好之后告诉你,你再按照别人的话去做。
|
||||
|
||||
**熟练意味着“做好”**。跟基础不同,熟练是指能够把当前级别的事情做好。做好体现在做事熟练,掌握了做事的**最佳实践**,能够保证效率和质量,能够拿到好的结果。
|
||||
|
||||
**精通意味着“优化”**。精通是指能够**优化**当前级别的事情,比如采取不同的方式、思维和工具来做同样的事情,并取得突破。
|
||||
|
||||
如果要再区分一下“做好”和“优化”,我们可以这么理解:做好只是意味着掌握了别人总结的成熟经验,而优化意味着你自己创造了**新的经验**。
|
||||
|
||||
什么算“新的经验”呢?并不是说要“全球首创”,而是说在自己所处的环境中(团队、业务线、公司等)是新的。比如“微服务”架构,别的公司可能早就在用了,但如果把它引入到这家公司的人是你,这就算你的优化成果。
|
||||
|
||||
另外还要注意的是,我总结的这套标准,是用来判断在**某个级别**所要求的能力,而不是**单项技能**的水平。
|
||||
|
||||
比如,你从事开发工作,P5/P6的核心职责是项目开发,而项目开发会涉及到业务理解、项目计划、编程语言和 Bug 修复等一系列的单项技能。对于这些具体技能的水平,用技术广度或者技术深度来区分会更合适。
|
||||
|
||||
## 通用的晋升步骤
|
||||
|
||||
现在,我们掌握了两条关键的晋升逻辑,知道了主管和评委团是如何判断你有没有达到晋升要求的。再结合第3讲的晋升原则,我们就可以推导出适用于各个级别的**通用晋升步骤**了。具体来说,分为以下4步:
|
||||
|
||||
第1步,按照晋升原则的指导,在当前级别拿到好的结果,为公司创造价值,同时把当前级别要求的能力提升到精通程度(比如从P6-到P6+),这样你才有机会成为晋升备选人员。
|
||||
|
||||
第2步,到了精通程度之后,对照下一级别的要求来提升自己的各种能力(比如到了P6+之后,按照P7-的要求来提升自己),为可能的晋升机会做好准备。
|
||||
|
||||
第3步,主动寻找工作机会,尝试做下一个级别事情(比如提升了P7的能力之后,找P7级别做的事情来做,争取成为负责人,主导事情的推进和落地),继续拿到好的结果,向主管证明你具备下一级的能力。
|
||||
|
||||
第4步,拿到工作结果之后申请晋升,向评委介绍你做过的事情,展示相关的能力和结果,证明自己具备了下一级别要求的能力。
|
||||
|
||||
按照这个步骤来,你的晋升肯定就会容易很多。
|
||||
|
||||
## 小结
|
||||
|
||||
现在,我们回顾一下这一讲的主要内容。针对能力判断的问题,我剖析了晋升的底层逻辑,并在此基础上提炼了一个通用的行动步骤。你需要记住的重点有这4条:
|
||||
|
||||
1. 晋升的第一条逻辑是,在当前级别做下一级别事情的人,才有机会晋升。
|
||||
1. 晋升的第二条逻辑是,只有把当前级别的事情做好了,才有机会晋升。
|
||||
1. 基础、熟练和精通三种水平的区别是,基础意味着会做,标志是能够独立完成;熟练意味着做好,标志是掌握最佳实践;精通意味着优化,标志是创造新的经验。
|
||||
1. 通用的晋升步骤是,先把当前级别要求的能力提升到精通水平,接着按照下一级别的能力要求继续提升,然后主动寻找工作机会,尝试下一个级别的工作,最后拿着工作成果申请晋升。
|
||||
|
||||
## 思考题
|
||||
|
||||
这就是今天的全部内容,留一道课后思考题给你吧:对照两条晋升逻辑评估一下自己的现状,你觉得自己可以去尝试申请晋升了么?
|
||||
|
||||
欢迎你把答案写到留言区,和我一起讨论。相信经过深度思考的回答,也会让你对知识的理解更加深刻。<br>
|
||||
<img src="https://static001.geekbang.org/resource/image/04/c1/046c4ffc98ddff0bf5a9a4d26319eec1.jpeg" alt="">
|
181
极客时间专栏/大厂晋升指南/晋升体系/05 | COMD能力模型:怎么把抽象的能力要求具体化?.md
Normal file
181
极客时间专栏/大厂晋升指南/晋升体系/05 | COMD能力模型:怎么把抽象的能力要求具体化?.md
Normal file
@@ -0,0 +1,181 @@
|
||||
<audio id="audio" title="05 | COMD能力模型:怎么把抽象的能力要求具体化?" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/f1/41/f179b946d3e4fc9fcdef35a7ea0eeb41.mp3"></audio>
|
||||
|
||||
你好,我是华仔。
|
||||
|
||||
上一讲我分享了两条晋升逻辑和一套通用的晋升步骤。现在你已经知道,要先把当前级别要求的能力提升到精通程度,然后尝试做下一级别的事情。
|
||||
|
||||
不过在这个过程中,你还会遇到另一个麻烦,那就是不确定下一级别的能力要求到底是怎样的,所以你也不知道究竟要准备到什么程度。
|
||||
|
||||
举个最常见的例子,不同级别有不同的Title(头衔),比如“工程师”“高级工程师”和“专家工程师”等。但是,这样的 Title 对我们理解不同级别的能力要求,是完全没有什么用处的。“高级工程师”到底“高级”在哪,可能每个人的理解都不一样。
|
||||
|
||||
## 公司统一的能力描述:抽象
|
||||
|
||||
为了指导员工晋升,公司一般都会对各个级别的能力要求给出描述。但是因为细分的领域实在太多了,所以公司只能进行非常抽象的描述。
|
||||
|
||||
比如,P7的要求是“具备系统思考的能力,能够全面掌握某个技术领域”,而P8的要求是“具备前瞻判断的能力,能够规划技术领域的发展方向”。
|
||||
|
||||
从实际的效果来看,这样的描述**基本没什么效果**,绝大部分人看完还是一头雾水。在实际工作中,团队成员经常跟我反馈这样的困惑:
|
||||
|
||||
- 什么是**系统思考**能力?P7才要求系统思考,可是我P6的时候参与项目开发,就需要考虑需求的合理性、索引设计高性能、接口的兼容性和易用性、上线的灰度方案这么多事情,这些难道不是系统思考吗?
|
||||
- 什么是**前瞻判断**能力?P6要预测需求变化,P7要规划团队技术发展,这些也是前瞻判断呀,为什么P8要特别强调前瞻判断?
|
||||
|
||||
可以说,晋升疑惑千千万,能力要求占一半。这一讲我要介绍的就是把抽象要求具体化的方法。
|
||||
|
||||
## 领域定制的能力解读:比较具体
|
||||
|
||||
因为公司的抽象描述很难指导实际工作,所以有些领域会独立定制自己的职级能力解读,一般是由P8或P9级别的员工以工作组的方式讨论得出来的。
|
||||
|
||||
比如“Java业务开发”这个领域,P6和P7级别的能力解读长什么样呢?你可以参考下面的表格。
|
||||
|
||||
(注:这张表格仅供参考。它不是完整的解读,不代表所有公司的实际要求。你也不需要看懂里面的所有内容,只要了解这个形式就可以了。)
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/06/b7/0653e9a2yy8b3660d402fd70031190b7.jpg" alt="">
|
||||
|
||||
我们可以看到,这份标准跟公司的描述相比,已经具体很多了。如果按照这个思路,完整地把各个级别要求的能力一一列出来,不但可以作为晋升的标准,也可以作为学习的参考。
|
||||
|
||||
其实这种做法对员工是有利的,因为标准越明确,就越容易“照本宣科”地去做。但是从公司的角度来看,这种做法存在成本太高(有几十上百个专业领域要制定详细标准,每年都要更新)、限制创新(大家都只管对照公司标准来做事,其它一概不管)等问题,所以很少有公司会这么做。
|
||||
|
||||
## COMD能力模型:4种复杂度+3个维度
|
||||
|
||||
为了彻底解决要求不明确的问题,让你更好地理解不同职级的能力差异,我根据自己的思考和担任晋升评委的经验,提炼出了一套兼容性很强又容易理解的能力模型:**面向复杂度的多维度能力模型**(Complexity-Oriented & Multi-Dimension Capability Model),简称**COMD能力模型**。
|
||||
|
||||
COMD的CO是指Complexity-Oriented,意思是“面向复杂度”(灵感来源于“面向对象”);MD是指Multi-dimension,意思是“多维度”,也就是技术、业务和管理3个维度。
|
||||
|
||||
COMD的核心指导思想是,**通过事情的复杂度来判断能力的高低**,级别越高,所做的事情复杂度也越高。
|
||||
|
||||
当然,如果只是单纯地用复杂度来判断能力高低,那么它本质上和其他方法也没什么不同,看不懂的地方还是看不懂,不同的人理解还是不同。
|
||||
|
||||
所以,为了清晰地描述不同能力层级的差异,COMD能力模型还进一步地明确了复杂度,具体包括规模复杂度、时间复杂度、环境复杂度和创新复杂度4种类型。
|
||||
|
||||
### 1. 规模复杂度
|
||||
|
||||
规模复杂度是指和规模大小有关的复杂度。
|
||||
|
||||
规模越大,复杂度越高。原因在于规模越大,节点越多,节点间的关系越复杂,而且节点间的关系复杂度是指数增长的。就像下面的图片所展示的:当节点数只有3个时,节点间的关系也只有3个;而节点数达到6个时,节点间的关系就变成了15个,复杂度提升了5倍。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/ea/59/eayyd87a3cf233299b58bb632e68a959.jpg" alt="">
|
||||
|
||||
按照这个原理,我们可以对一些常见工作维度的规模复杂度进行比较,具体如下表所示。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/a3/0c/a3d429b12fb94f239f6fac84376cb10c.jpg" alt="">
|
||||
|
||||
当然,以上对比的前提是,除了规模之外,其他条件都差不多。(对比其他几个复杂度时也是这样)。就像表格中200行代码和2000行代码对比,前提是代码复杂度是差不多的。因为200行核心代码的复杂度,显然比2000行拷贝粘贴的代码要高。
|
||||
|
||||
### 2. 时间复杂度
|
||||
|
||||
时间复杂度是指和时间跨度有关的复杂度。
|
||||
|
||||
时间跨度越长,复杂度越高。原因在于万事万物都处于不断发展变化当中,时间跨度越长,变化的因素和可能方向越多,越难判断准确。
|
||||
|
||||
三大维度的时间复杂度的对比举例如下表所示。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/c7/95/c742fb1d759eccccf5d2489f7be5bf95.jpg" alt="">
|
||||
|
||||
### 3. 环境复杂度
|
||||
|
||||
环境复杂度是指和环境不确定性有关的复杂度。
|
||||
|
||||
我们很多的判断、决策和行为都依赖于对环境的认知和反应。总的来说,环境不确定性越高,复杂度越高。
|
||||
|
||||
环境的不确定性具体分为环境的稳定性、环境的透明性和环境的可预见性3个方面:
|
||||
|
||||
- 环境的稳定性,指环境变化的速度快慢。
|
||||
- 环境的透明性,指是否能够明确地获取环境相关的信息。
|
||||
- 环境的可预见性,指是否会发生完全无法预料的黑天鹅事件。
|
||||
|
||||
环境的稳定性、透明性和可预见性越低,它的不确定性就越高,复杂度也越高。
|
||||
|
||||
下面这个表格从宏观的角度分析了技术、管理和业务三个维度所面临的环境不确定性。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/b5/9e/b501ac73ffe078e0674d72f17d85b49e.jpg" alt="">
|
||||
|
||||
从表格中可以看出,对于互联网行业的业务来说,环境稳定性、透明性和可预见性都比较低,所以它的环境复杂度是最高的。这也是在互联网大厂,大部分P9/P10都需要把很多时间和精力投入到业务上的主要原因。
|
||||
|
||||
### 4. 创新复杂度
|
||||
|
||||
创新复杂度是指和创新程度有关的复杂度。
|
||||
|
||||
常见的创新包括理论的创新、思想(或者说方法)的创新和技巧的创新。理论创新的复杂度要高于思想创新,而思想创新的复杂度又高于技巧创新。
|
||||
|
||||
以高可用技术领域为例:
|
||||
|
||||
- FLP原理和CAP定理属于**理论创新**。它们奠定了分布式高可用设计的基础和边界,无论是缓存系统、存储系统、批处理系统、流式处理系统还是采用微服务架构的业务系统等,都不能跳出这两个理论的约束和限制。
|
||||
- 批处理和流处理属于**思想创新**。对于大数据技术来说,一开始Google提出的批处理思路开启了大数据时代,而后来Storm开启了流处理这个新的技术领域。
|
||||
- 实现Exactly Once特性属于**技巧创新**。开源框架Flink使用Chandy-Lamport 算法,实现了流处理Exactly Once的特性,能够实现消息精确投递,避免重复消息导致业务出错。
|
||||
|
||||
我们可以看到,创新复杂度越高,影响的范围往往也越大。理论创新会奠定整个行业的基础,而思想创新可能开辟一个新的技术领域。
|
||||
|
||||
另外,创新并不意味着一定要全球首创,只要相比团队当前现状来说有改进就行了;创新也不局限于技术领域,管理和业务一样可以创新。所以,下面这些事情都可以算是创新:
|
||||
|
||||
1. 开发Memcache
|
||||
1. 有了Memcache后开发Redis
|
||||
1. 引入设计模式优化代码
|
||||
1. 使用微服务来拆分系统
|
||||
1. 优化项目流程
|
||||
1. 提出一种新的业务模式
|
||||
|
||||
各领域的部分典型创新案例如下表所示,你可以参考对照。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/5c/68/5cae1a8ed6d5ba85179d313a583de368.jpg" alt="">
|
||||
|
||||
除了刚才说的这4种通用的复杂度之外,在每个领域内部,也会有一些工作的复杂度本身就要比另一些工作高。
|
||||
|
||||
比方说在软件开发领域,我们一般认为各项工作的复杂度排序是这样的:
|
||||
|
||||
$$从0到1创造系统 > 架构重构 > 项目方案设计 > 编码实现$$
|
||||
|
||||
不过这些认知是领域经验总结形成的共识,并不能通用。所以在使用COMD模型的时候,你还是需要结合领域经验综合判断。
|
||||
|
||||
## COMD与抽象描述的对比
|
||||
|
||||
我想,你现在应该知道为什么公司写的那些抽象描述让人看不懂了。跟COMD能力模型的具体拆解比起来,它们只是脱离实际的文字游戏罢了。我就拿这一讲开头提出的“系统思考”和“前瞻判断”来说好了。
|
||||
|
||||
### 系统思考
|
||||
|
||||
比如在某些大厂,“系统思考”的确是写在P7级别的能力描述里,但它不是P7级别才有的能力特征。实际上,P6以上的级别都要求“系统思考”,区别只是**思考的范围**不同,也就是**规模复杂度**不同而已。
|
||||
|
||||
以B2C电商业务开发为例,在某些大厂,不同级别“系统思考”的范围如下图所示:
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/25/76/256f46afaff6edb59ba7b1bf4ee47f76.jpg" alt="">
|
||||
|
||||
- 对于P6来说,系统思考的范围是某个**需求**,需要考虑需求的合理性、设计的可扩展性和上线后的稳定性等问题。
|
||||
- 对于P7来说,系统思考的范围是单个**系统**,需要考虑的是单个系统的架构设计、架构重构和技术选型等问题。
|
||||
- 对于P8来说,系统思考的范围是某个**领域**,需要考虑的是领域的发展趋势、架构演进、团队组织结构等问题。
|
||||
- 对于P9来说,系统思考的范围是多个关联的业务域组成的**业务线**,需要考虑业务发展趋势、架构演进、团队组织结构等问题。
|
||||
|
||||
### 前瞻判断
|
||||
|
||||
同样地,在某些大厂,“前瞻判断”虽然写在了P8的能力描述里,但其实P6以上都有前瞻性的要求,区别只是在于前瞻范围、时间跨度和面临的环境不同而已。这些因素就分别对应了规模复杂度、时间复杂度和环境复杂度。
|
||||
|
||||
同样以B2C电商业务开发为例,某些大厂P6~P9级别的前瞻性要求如下表所示:
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/79/a7/7901c8dc04db3d0edef3003eba2e06a7.jpg" alt="">
|
||||
|
||||
所以说,如果你还在绞尽脑汁地钻研“为什么P7才提出系统思考”以及“P8要求的前瞻判断有什么深意”这样的问题,那就掉到文字陷阱的坑里去了,白白浪费脑细胞。至于怎么从坑里走出来呢?这就需要灵活应用COMD能力模型了。
|
||||
|
||||
## 如何应用COMD
|
||||
|
||||
当你想要了解某个级别的能力要求的时候,不要再对着那些抽象和模糊的词语,不着边际地猜测和想象了。你应该静下心,坐下来填一个“能力矩阵”的表格,把每一项的要求都完整且具体地列出来。比如下面这个“能力矩阵”表格就摘录了P6级别的部分要求,可以作为参考。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/b1/72/b10dcec32eb291c464da50636c2c3572.jpg" alt="">
|
||||
|
||||
如果表格里有些内容你填不出来,说明你对这个级别的理解还不到位。不过没有关系,我会在课程的第二部分,也就是职级详解中给出每个级别通用的衡量标准。
|
||||
|
||||
在这个基础上,你可以请教你的主管、HR和同事等人,来完善和细化表格内容。当你详细地填完了这个表格,你也就对这个级别了解得很清楚了。接下来,你就可以对照表格,针对性地提升自己的能力。
|
||||
|
||||
## 小结
|
||||
|
||||
现在,我们回顾一下这一讲的主要内容。
|
||||
|
||||
1. 公司会对各个级别的能力要求给出一个抽象的描述,比如“系统思考”和“前瞻判断”等,但实际指导意义不大。
|
||||
1. 有些领域可能会独立定制相关技术方向的能力解读。虽然这种解读比公司的抽象描述稍微具体一些,但因为投入成本太大和限制创新等原因,很难大范围推广。
|
||||
1. 我总结的COMD能力模型,把能力分成技术、管理和业务三个维度,并通过规模、时间、环境和创新四个复杂度来判断能力的高低。
|
||||
1. 如果你想了解某个级别的能力要求,为晋升做准备,可以把这个级别的能力模型表格列出来,然后针对表格内容做针对性的提升。
|
||||
|
||||
## 思考题
|
||||
|
||||
这就是今天的全部内容,最后留一道课后思考题给你吧。记得有一次,团队成员跟我探讨职级的时候,问了我一个问题:“为什么说P6是独当一面,难道P7、P8和P9没有独当一面的要求吗?”学了COMD能力模型之后,你会怎么回答这个问题呢?
|
||||
|
||||
欢迎你把答案写到留言区,和我一起讨论。相信经过深度思考的回答,也会让你对知识的理解更加深刻。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/83/96/83211d404c6701c8791c59df4170bb96.jpeg" alt="">
|
119
极客时间专栏/大厂晋升指南/晋升体系/06 | 职级档次:你现在应该具备的核心能力是什么?.md
Normal file
119
极客时间专栏/大厂晋升指南/晋升体系/06 | 职级档次:你现在应该具备的核心能力是什么?.md
Normal file
@@ -0,0 +1,119 @@
|
||||
<audio id="audio" title="06 | 职级档次:你现在应该具备的核心能力是什么?" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/43/2d/43ea21e0b3b8374de85a4060d1da162d.mp3"></audio>
|
||||
|
||||
你好,我是华仔。
|
||||
|
||||
上一讲我介绍了COMD能力模型,让你能够具体拆解一个级别的能力要求,不再纠结于抽象的描述。但你可能还是不清楚每个级别到底要求什么。这些具体要求,我会在课程第二部分,也就是**职级详解**部分一一介绍。
|
||||
|
||||
不过在这之前,我想先通过三个类比带你纵向透视职级档次,对不同档次的核心能力建立一个形象的认知。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/4b/4e/4bccb93fyyc2e9efb3315148d481374e.jpg" alt="">
|
||||
|
||||
## P5/P6:专业工匠
|
||||
|
||||
P5/P6这一档相当于“专业工匠”,就像木匠、铁匠、粉刷匠一样,核心能力是**完成任务**。
|
||||
|
||||
这里的任务是指每个岗位需要完成的事情,比如开发岗位需要完成代码编写,测试岗位需要完成测试用例执行。
|
||||
|
||||
P5和P6的职责一样,比较简单,不需要太多解读。这两个级别的区别是,P5需要**在别人的指导下**完成工作,而P6可以**独立**完成工作。其实只要有意愿在技术领域发展,**基本上每个人都能达到P6的水平**。
|
||||
|
||||
P5/P6的核心职责如下表所示。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/c6/87/c66280b04f93cf3ccd6c82bf8a0bd487.jpg" alt="">
|
||||
|
||||
需要强调的是,这里列举的只是一个岗位的核心职责,并不代表这个岗位只做这些事情,比方说开发岗位的P7/P8也是要参与编码的。
|
||||
|
||||
另外,这里只列举了开发、测试和运维这些技术岗位的职责。产品、运营和市场等非技术岗位的同学,也可以根据你掌握的信息来整理你所在岗位的核心职责表格。
|
||||
|
||||
## P7/P8:乐团指挥
|
||||
|
||||
P7/P8这一档相当于“乐团指挥”,核心能力是**指挥团队**。
|
||||
|
||||
为什么我要这么类比呢?因为P7/P8的职责和乐团指挥的职责非常相似。乐团指挥的核心工作职责,具体可以分为三个阶段:
|
||||
|
||||
第一阶段是总谱研究,对总谱进行深入细致的研究分析,识别和标注演奏的重点、难点和风险点。
|
||||
|
||||
第二阶段是排练准备,明确演奏需要的人手和乐器,根据乐团情况制定排练计划。
|
||||
|
||||
第三阶段是正式排练,拆解具体排练步骤(比如个体练习、分声部练习和全体排练等),抓好每一个关键环节的落实,做好风险预防措施,推动整个乐团完成演奏。
|
||||
|
||||
P7/P8的任务和乐团指挥非常像,也可以分为三个阶段,跟乐团指挥的三个阶段正好一一对应。你只要把总谱换成团队的工作目标,把人手和乐器换成资源,把演奏排练换成工作目标落地就行了。
|
||||
|
||||
首先是**分析阶段**,对应乐团指挥的总谱研究;然后是**计划阶段**,对应排练准备;最后是**落地阶段**,对应正式排练。我把这个对应关系总结在了下面的表格里。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/1f/88/1fe4ea49e3ea5435c73406d4be2e3c88.jpg" alt="">
|
||||
|
||||
那么P7和P8的区别是什么呢?P7只需要指挥**单个**团队,而P8往往要指挥**多个**团队。
|
||||
|
||||
另外还需要补充一点,我这里说的“团队”,包括两种类型:
|
||||
|
||||
1. 狭义上的团队:组织结构上的行政级别团队,比如P7担任的3~10人团队的Team Leader,负责团队管理、团队规划、团队考核和团队建设等管理职责。
|
||||
1. 广义上的团队:为了完成某个目标而成立的虚拟团队(或者说临时团队),比如某个项目投入的人员组成了“项目团队”(由公司立项成立),某个专项任务投入的人员组成了“专项团队”(由管理者安排,比如“研发效能提升工作组”)。
|
||||
|
||||
P7/P8的核心职责如下表所示。<br>
|
||||
<img src="https://static001.geekbang.org/resource/image/f6/c2/f651082f46406950985568e639f082c2.jpg" alt="">
|
||||
|
||||
## P9/P10:电影导演
|
||||
|
||||
P9/P10这一档相当于“电影导演”,核心能力是**导演作品**。
|
||||
|
||||
为什么我会这么类比呢,因为P9/P10的工作跟电影导演很像,具体表现在三个方面:
|
||||
|
||||
**第一,他们的工作都具有一定的规模。**
|
||||
|
||||
比如说你只是拍一段60秒的vlog,还算不上电影导演;真正的电影导演拍出来的是几十分钟以上,剧本、服饰、化妆、道具、表演、运镜和剪辑都非常成熟的作品。同样地,P5~P8这几个级别的工作都会产出一些成果,但这些成果在规模上还不足以跟P9/P10这个级别相比。
|
||||
|
||||
**第二,他们都是总决策者。**
|
||||
|
||||
在一个剧组里,一般情况下导演就是老大,有绝对的话语权。同样地,虽然P6可以指导别人,P7/P8可以带团队,但工作仍然会在很大程度上受到制约,关键的目标制定、资源整合和关键决策的工作,还是得由P9/P10来完成。
|
||||
|
||||
具体一点说,P9/P10需要制定有挑战的业务目标;整合不同的团队,包括多个技术团队(比如Android、iOS、前端、Java后端、测试、运维等)和多个业务团队(比如腾讯的广告平台的某个业务,可能涉及QQ、微信和应用宝等多个业务团队);做出关键决策(例如要做什么、不做什么、先做什么和后做什么等)。
|
||||
|
||||
**第三,他们都是总负责人。**
|
||||
|
||||
一部电影作品会打上导演的烙印,甚至呈现出强烈的导演个人风格。电影拍得不好,观众第一个骂的就是导演;拍得好,赞美和荣誉也首先给到导演身上。
|
||||
|
||||
同样地,P9/P10的水平、眼界、价值观和做事风格,直接决定了一条业务线的质量,因为这些因素会体现在工作过程中的各种决策里面,决定了最终的呈现效果。
|
||||
|
||||
另外,导演往往有自己擅长的题材,比如文艺片、喜剧片;而P9/P10一般也都聚焦于某个业务或者专业领域,比如电商业务、出行业务、安全领域、算法领域,很少有跨领域样样精通的人才。
|
||||
|
||||
P9和P10的核心差异在于成果质量。我还是拿电影导演来类比,P9是**成熟**的导演,能拍出7分以上的作品(基本合格);P10是**成名**的导演,能拍出8分以上的作品(比较优质)。
|
||||
|
||||
虽然对于P9/P10的工作成果,并没有一个通用的打分机制,但是公司能通过一些硬指标来衡量,最典型的就是直接看业务结果。
|
||||
|
||||
如果你负责的业务结果实现了既定的业务目标,那么你就是成熟的导演,可以胜任P9;如果你负责的业务结果按照某个标准(用户量、收入和权威机构的测评等),进入了业界前列,有一定的名气和影响力,那么你就是成名的导演,可以胜任P10。
|
||||
|
||||
P9/P10的核心职责如下表所示。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/ee/c5/eeb6175e8cae4e11c290907be255d8c5.jpg" alt="">
|
||||
|
||||
## 这些类比有什么用
|
||||
|
||||
在这一讲中,我使用了“专业工匠”“乐团指挥”和“电影导演”三种形象来类比不同的职级档次,但是这仅仅是针对职责的相似度来说的。这种档次划分对应了行政级别的高低,但不代表艺术成就的高低。比如P9/P10的级别高于P8/P7,但并不意味着电影导演的艺术成就一定高于乐团指挥。
|
||||
|
||||
之所以要把职级档次跟你熟悉的职业角色建立联系,是希望通过形象思维的方式帮你快速建立对每个级别的具体认知。以后我们再说到某个级别的时候,你就能一下子抓住它的核心要求。
|
||||
|
||||
需要注意的是,这一讲的类比只是宏观层面的特征提炼。如果你想了解每个级别能力的细节要求,还是需要参考课程职级详解部分关于每个级别的详细解读。
|
||||
|
||||
因为阿里的级别是业界的“职级硬通货”,辨识度高,认可度高,所以我采用了阿里P5~P9的级别作为例子进行讲解。不管你在大公司还是小公司,不管你公司现在是否有完善的职级体系,如果你想了解自己能力水平在行业内所处的级别,我建议你都对标阿里的职级来估计。
|
||||
|
||||
目前网络上已经有一些关于不同公司职级怎么对应的文章;而且我也专门准备了一期加餐,根据我的面试经验,提炼了几个典型互联网大厂的职级对应关系。这些信息你都可以参考。
|
||||
|
||||
## 小结
|
||||
|
||||
现在,我们回顾一下这一讲的重点。P5~P10的6个等级,可以根据能力特征分成3个档次,分别对应三种职业角色。
|
||||
|
||||
1. P5/P6相当于专业工匠,核心能力是执行任务,P5和P6的差别在于能否独立完成任务。
|
||||
1. P7/P8相当于乐团指挥,核心能力是指挥团队,P7和P8的差别在于指挥的是单个团队还是多个团队。
|
||||
1. P9/P10相当于电影导演,核心能力是导演作品,P9和P10的差别在于导演出来的是成熟的作品还是成名的作品。
|
||||
|
||||
我把这个对应关系总结在了下面这个表格里,供你参考。<br>
|
||||
<img src="https://static001.geekbang.org/resource/image/54/37/54bd26eb8d1b7fa99f7f8095fe2e4337.jpg" alt="">
|
||||
|
||||
最后再补充一点,高级别的能力要求包含低级别的能力要求。比如P9的核心能力是“导演成熟作品”,但肯定也要具备P8要求的“指挥多个团队”的能力。
|
||||
|
||||
## 思考题
|
||||
|
||||
这就是今天的全部内容,留一道课后思考题给你吧。电影学院有专门的导演专业,学生可以不成为演员而直接学习如何成为导演。那么在职场晋升体系中,我们为什么不能直接学习P9/P10的技能,然后直接晋升P9/P10呢?
|
||||
|
||||
欢迎你把答案写到留言区,和我一起讨论。相信经过深度思考的回答,也会让你对知识的理解更加深刻。<br>
|
||||
<img src="https://static001.geekbang.org/resource/image/14/b8/14c0dd1336yyf86864d3452b90e9bdb8.jpeg" alt="">
|
Reference in New Issue
Block a user