阿里的职级体系确实已经落后了

本文来自微信公众号：MacTalk（ID：MacTalkPro），作者：池建强，头图来自：视觉中国

前两天，聊阿里职级体系调整的事，发现好几条想法类似的留言：阿里的职级体系很先进，组内对标的时候值得参考。

这种想法本身没问题，上进心十足。但建议不要参考，尤其是组织管理问题上，过于轻率和死板的参考，容易掉入陷阱，轻则水土不服，重则团队崩散。

为什么这么说？

首先强调一点，公司的死法很多，业务过度分散、团队内讧、急功近利、产品落后时代……但其中还有一种是死于追求“先进”。

很多人，尤其互联网领域的创业者，见证无数商业奇迹之后，相信大厂的一切都是最先进的，喜欢照搬大厂的组织管理、人才培养方法论，比如阿里的组织体系，华为的 IPD，字节的 OKR，结果学了一身大厂病。

我完全理解为什么这么想。人之常情，吃过猪肉的人最有发言权，大厂聪明人云集，解的都是几万十几万人的组织问题，他们想出来的职级划分体系、绩效考核标准，一个解决发展路径，另一个解决员工激励，肯定是事先试错、调整、验证过的，因此肯定是最先进的。

但组织管理的策略，不是衡量发展阶段的工具，只是解决发展问题的手段。不能用“先进”，而要看是否“有效”。任何管理手段都是有成本的，如果过早的在公司管理中，引入复杂的管理体系，这对于中小公司而言，无异于邯郸学步，自讨苦吃。

很简单的例子，我办个猪肉厂，日均要保障几千斤猪肉的生产，生产流水线、出厂检验标准就格外重要，一个解决生产速度，另一个解决品质稳定性。但如果我只是一个每天卖几十斤猪肉的摊贩，参考大厂搞一套先进流水线就很离谱了。

产品经理圈，有条梳理需求的思考方法：“用什么方法，解决谁的，什么问题”，这三点里，“谁的问题”是更重要的。只要找到了这个问题，再想用什么方法解决它，不同的产品经理有不同的实践方法。但如果你拿到一个伪需求，一个非高频非刚需的需求，你使了很多蛮力，做出一个更好的解决方案，但最终你却可能是一无所获。

企业也是一样，感知潮流、向往先进都没问题，识别出自己现阶段的关键问题，量体裁衣，才是走出经营困境的正确解法。

阿里人才体系的改革就是一个很好的例证，什么阶段干什么事，什么山头唱什么歌，没有什么一蹴而就的标准答案，切忌不加思辨的参考。

这点也可以推广到个人的职业发展、人生发展上，绝大多数困境没有银弹，阶段不同，问题不同，解法不同。所以，可以听他们说话，但不要照搬他们的话。独立思考，先想清楚自己要解决的第一优先级问题到底是什么。

至于怎么思考？

丰田有一套方法论叫做精益思想，五个 Why，就是对任何一个现象、任何一个问题、任何一个需求和任何一个想法，想看清背后的真实动机，你得不断问为什么，至少问 5 次。

我就拿这次阿里职级改革为例。至于为啥拿阿里举例，主要是他们人多，对外输出的人也多，业界普遍比较认同。这次改革一共 4 点：

取消 P 序列，改为 14-28 级，对应原 P4-P8，每三个职级对应一个 P 级；

原 P8 以上员工走组织任命的形式，不再有职级的晋升和降级，而根据业务规模和团队规模来决定薪资和奖金；

14-28 级员工工资和奖金不会只与职级挂钩，未来将实现职级和奖金的逐步分离；

绩效分数将只保留三个层级：3.75、3.5、3.25，取消 3.5+ 和 3.5-，绩效表现优秀者可能在一年内实现多个层级跃升。

第一问：为什么阿里动职级体系？

先了解清楚职级体系是为了解决什么问题。一方面，是要结合公司的实际情况，界定各个岗位对应的具体职能，《领导梯队》书里，从员工到 CEO，划分了六个领导力发展阶段，我觉得可以涵盖绝大部分企业，很精准很有代表性：

一线员工，管理自己；一线经理，管理他人；部门总监，管理经理人员；事业部副总经理，管理职能部门；事业部总经理，管理 BU 事业部；集团高管，管理 BG 业务群组；首席执行官 CEO，管理全集团。

另一方面，有了明确阶段划分后，创造机制，让要晋升到目标岗位的人具备应有的能力，以避免无法胜任。

这直接改变了我们对晋升的理解——先具备能力，再提升职级。比如华为的管理架构理念：以岗定级、以级定薪、人岗匹配、易岗易薪。

要知道，传统企业这是不存在的，我在流水线上贴标签贴得又快又好，就直接被提拔成小组长了，哪有先考核后提拔一说，压根不存在我必须具备了小组长的监工能力才准许晋升。

但不在其位很难谋其政，割裂必然存在。能训练的是做事能力，越往后越为关键的领导技能、时间管理，必须等上了位才能慢慢体会。常听见很多大小厂管理者感慨：“亲力亲为是管理的第一大忌”“真做了管理才发现，想做好的关键就是要愿意在别人身上花时间”。

第二问：掌握了有关职级的必要背景信息，为什么阿里要把原 P4-P8 改为 14-28 级？

因为阿里随着业务发展，每个 P 级的人太多了。钉钉副总裁胡瑜玲说，“过去阿里有多少员工都数不清，有层层的环路、层层的外包，内核里面又有非常多种用工模式。这些环路都是在近一两年内才逐步理清的。”

我就粗略估计一下，阿里十万人，P5 校招生一万人，P6、P7 各三四万人，P8 一万人，P9 一千人，P10 五百人。比如 4 万 P6，分布在不同业务不同业态不同团队中，虽然是同一个职级，横向没有对比性，纵向没有足够坑位，从薪资管理、绩效考核，到晋升都很难办。

腾讯，2019 年其实也做过一次类似的职级改革，从 1.1 - 6.3 级改成了 4-17 级，主要原因就是 2.3 和 3.3 扎堆，晋升难。调整后，9 级以下不到一年就可以晋升，9 级到 10 级需要一年左右。

2022 年，腾讯取消职级晋升与薪酬增加的绑定，改成了综合“业绩贡献、能力提升和薪酬竞争力”等因素，评估是否调整薪酬。

虽然之前也有 P6-，P6，P6+ 之类的区分，但这次，其实相当于彻底把它们清晰化了，给了员工更明确的指导体系。从 P6 到 P7，就是需要跨越三个层级，谁都绕不开。

第三问：阿里业务也多，1+6+N 调整后，各自经营，避免大锅饭，拆大为小。按说公司已经比之前小很多了，为什么还要继续调整职级体系呢？

我觉得核心还是提高效率。

前天的文章我聊到了，之前阿里为了晋升，开了太多的会，太多重要的人把自己宝贵的时间，都浪费在了这些事情上。一个 P6 想要晋升 P7，不仅自己要准备几个月的晋升答辩，直属领导要评分，还要由 P8 组成的晋升委员会评分。

开会也是成本。阿里员工在搞晋升的时候，拼多多的员工在努力搞业务。这个效率上的差距，理解了么？搞晋升评比，那说白了，里面全是人情世故。如果一个公司花大量精力在这事上，那不就代表着臃肿？

所以，切细职级，取消动辄一两个月的晋升季，改为以季度绩效的方式来评估员工是否能晋升到下一个职级。这些动作，都是为组织提效。

第四问：那为什么原 P8 以上员工走任命，而且根据业务规模和团队规模来决定薪资和奖金？

一个原因是 1+6+N 调整，在独立的业务公司里，原 P8 以上，大都是管理 BU 事业部的总经理，这些人都是业务的一把手二把手。

但集团拆分后，没法晋升，没法降级。能拿多少钱，就看摊子有多大，你能做多大。

另外，职场升级的方向是：执行者——管理者——组织者——决策者，越往上走，关键能力比如前瞻能力，越难提前培养，所以越高职级，反而要脱离原本的晋升体系，转而变为任命。

第五问：最后一点为什么绩效变成 3 档？

在绩效考核方面，3 档还是 5 档影响不大，因为无论如何分级，实际考核的时候最关键的就是第一级和最后一级，一个用来晋升和发奖金，一个用来末位淘汰，中间级都是安慰奖。

谷歌前首席人才官写过一本书《重新定义团队》，讲了一段很传奇的故事。2013 年之前，谷歌的绩效考核分 41 级，从 1.0，1.1，1.2 到 5.0，平均分在 3.3 到 3.4 之间。如果某人连续几个季度的平均分达到 3.7 及以上，就能升职。

但这群人足够严谨，想找出最佳搭配，于是，2013 年谷歌在绩效考核体系上的尝试堪称行为艺术，考核间隔时间试验过年度、季度、月度和实时；考核分数体系用 3 分，也用过 50 分的，在分级上，从没有分级，最多拆分过 800 个分级，那会每个人在每个季度都能升职。

一年后得出结论，考核的评级分类数量是最不重要的问题，不要设定多于 15 种评级选择，至于选择 3 个，还是 6 个，随便。

阿里这次改成 3 个层级，主要是顺势而为，希望通过减少考核复杂度，进一步提高组织效率。

总的来说，这四点改革，主要就是两方面：底层员工，调整晋升速度；高层员工，减少职级应得。

还有一点这里没有提到，不过行动上也有表现，进一步缩短绩效考核时间。

遇到问题，先尝试问五个 Why（也不一定非要问五次），更容易接近独立思考。通过不断地问为什么，找到背后的动机，再去思考解决方案。这是正确的流程。切忌盲目参考追求先进。

参考阅读：

阿里的职级改革，到底意味着什么？

聊聊阿里改组换帅的事

本文来自微信公众号：MacTalk（ID：MacTalkPro），作者：池建强

相关推荐

阿里的职级体系确实已经落后了
阿里的职级改革，到底意味着什么？
阿里取消P序列职级显示 王帅：阿里从不靠职级管理
腾讯变革职级体系 每年各级干部能下比例不低于5%
再也没有阿里高P了？淘宝天猫重大人力体系改革曝光
美团升级职级体系：更提倡业绩导向，表现突出多加薪
36氪独家 | 阿里内部隐藏“P”序列职级，“高 P”光环或成过去式
36氪独家 | 美团五年来首次职级大调整，推扁平化，不升职也能加薪
焦点分析丨京东生鲜为什么落后了？
36氪独家 | 原百度云副总经理张志琦加入钉钉，担任副总裁职级 P10

网址: 阿里的职级体系确实已经落后了 http://www.xishuta.com/newsview83842.html