前言

关于职级体系的详细了解，一直是我希望能够做的一件事情。在职场中，按照马斯洛对于需求的不同层次，和按照麦克利兰对于成就的不同定义，随着时间和经历的增加，每个人都对于自我实现有一定的诉求。而对于互联网企业的技术岗，因为企业业务不一，技术栈的重点也有所不同。所以在职级的理解上，也或多或少会有一些差异。最近，有完整的阅读前阿里P9李运华的专栏，受益良多，也结合我自身的思考, 对于职级的不同层级对应的要求，职级晋升的注意要点，如何保持一颗学习的心态等，这些问题。准备用此博客来做一个阐述和总结。

声明

本博客主要灵感来自于 阿里P9李运华 的 《大厂晋升指南》, 并结合前百度经理人 刘建国 的 《技术管理36讲》, 贝壳金服 CTO 史海峰 的 《技术锁话》 再结合个人理解和经历而来, 如感兴趣，请通过如下链接关注 jssh

大纲

为什么需要职级体系

在日常生活中，我们总能听到某某评上了高级职称，而某某职级是P6，某某职位是高级研发。对于 “职称” ， “职级” ， “职位” 在互联网行业的定位究竟是什么？他们之间的区别和联系又是什么？ 由于不同的专业有着不一样的规定和限定条件，例如卫生部负责医师的职称，教育局负责教师职称的评定，人力资源部负责软件考试的证书等，这里我们就以互联网公司的一般情况来展开分析。

一般来说，互联网公司大部分都是民企，对于职称的要求在企业对政府的招投标的时候会有要求，此时依照招标性质不同，一般是硬件资质，软件资质为主要的投标门槛。此时，例如对于项目经理资质，中级，高级的 “职称” 就是我们常说的人力资源部门针对软考通过的同学颁发的资格证书。

而对于日常的开发，迭代，管理等工作，主要会以公司内部的 “职级” 为主，也就是我们常说的 P(N), T(N)， M(N) 等等，这部分一般是公司依照自身需求来制定。也是公司内部对于人员培养，梯队建设，薪酬管理的综合考量。

在相同的 “职级” 可以对应多种 “职位” ，例如 高级前端工程师，高级数据工程师，高级自动化测试工程师 等等。

说到职级体系的作用，则涉及到对于职级体系本质上是为了 TD(Talent Development) 和 LD (Learning Development) 这2个核心目的而来, 即通过涵盖指标与行为的能力模型来为一个组织

  • 组建人才梯队
  • 提升人员技能
  • 规划上升通道
  • 留住核心人员
  • 构建组织人才库

常见的职级体系

首先我们先来看看阿里，腾讯的职级体系

阿里职级体系
jssh


腾讯职级体系
jssh

在互联网行业，对于职级体系，阿里，腾讯职级是被借鉴的最多的，很多时候也可以理解为 硬通货 。同时新晋的滴滴，字节等互联网公司的职级体系也是在此基础上有所变化，但是大致是一样的。 抽象来说，职级体系可以分为两类：

  • 阶梯式职级 （例如腾讯）
    • 优势
      • 职级体系区别较小
      • 晋升机会更多
    • 劣势
      • 不同级别之间差别不容易界定（核心）
      • 在跨越大职级时依旧比较困难
  • 跨越式职级 （例如阿里）
    • 优势
      • 级别差别容易界定
    • 劣势
      • 在跨越职级时比较困难

虽然职级体系各有利弊，但是因为在面对跨越职级时都是需要有本质的能力模型提升，所以在宏观上差别不大。 所以下面更多针对大的职级级别来进行具体分析。

在进行职级评定以及晋升的时候，依照公司不同会有一些差异，一般职级评定和晋升需要都需要经过一系列过程，包括 提名，筛选，答辩，评定，沟通确认 过程。对于中小型或者快速成长公司，更多是在更高职级，例如专家职级及以上的时候会走以上步骤，一般在前几个级别，更多是走提名，筛选，审批，沟通确认流程，而免去了答辩和评定过程。

职级体系下的能力模型

对于职级体系，很多时候，我们听到的就是需要精通，需要能够深入，需要持续有创新的思维，这其实基本上等于没有进行定义。不仅让员工觉得职级比较虚，更多是会失去努力的方向和目标。所以一个好的职级体系要起到的作用是 指导方针 的作用。
指导方针定义明确，利于理解，则能够很好的起到规范的作用，但是也不能够过于照本宣科，从而增加过于复杂的管理维护成本，最重要是容易引起固定思维与限制创新。

那什么样的职级定义才能够比较准确的表达出每个职级的根本不同呢？ 这里我非常的认同 李运华 基于 COMD (Complexity-Oriented & Multi-Dimension Capability Model) 能力模型而做的阐述和讲解。这个模型更贴近我们对于职级的直观理解与抽象。 所谓 COMD， 即面向复杂度，多维度进行拆解和考量。其中包括了以下维度的复杂度:

面向 技术 ，管理 和 业务 下的：

  • 规模复杂度
    对于规模复杂度，可以理解为负责内容的范围，是一个主要模块，一个产品，一个业务线，多个业务线，整个生态还是整个公司等等，从事的规模越大，复杂度则越高，思考和执行的方式也不经相同。

  • 时间复杂度
    时间复杂度，则是代表所负责内容所需要的时间规划，是一个迭代，一个季度，半年，一年，一年以上等等，要考虑的规划约长远，复杂度越高，所要拆解的内容和面对的挑战也就越大

  • 环境复杂度
    环境复杂度则代表了业务环境，公司环境的复杂程度，是组内合作，跨组合作，跨地域合作，跨公司合作，跨平台整合，跨业务整合等等，环境的影响因素会直接影响处理当前业务的能力

  • 创新复杂度
    创新复杂度代表了面对挑战时候的创新能力，组内修改优化，公司首次引入某项技术，公司落地一套平台，行业内首创一种概念等都是属于创新，一般是从0到1创造系统 > 架构重构 > 项目方案设计 > 编码实现

以 测试岗位 P6 - 资深自动化测试工程师 级别所要满足的能力矩阵:

矩阵 规模复杂度 时间复杂度 环境复杂度 创新复杂度
技术 能够熟练掌握端到端的工具和知识 专注短期技术实现与交付落地 能够熟练配置和使用团队内部工具，例如禅道，Jira，Git等 能够结合当前平台和所用工具，改善某些步骤的代码和流程，例如抽象组件，提出更有效的管理方式等等
管理 能够准确识别上下游依赖，完成优秀的测试场景设计，推进需求的落地，实现质量目标 能够较准确评估当前被分配任务的人天与拆分子任务 能够协调和反馈上下游的依赖，跨团队的协作 能够及时总结优劣，提出相应的优化措施，并推进执行
业务 能够掌握负责模块，产品中所有业务逻辑 能够提出优先级意见，并推进其落地 熟悉产品专业知识，熟悉产品与竞品比较的优劣，明白用户画像下的各个场景需求背景 通过对需求的分析，对竞品的理解，提出业务上的改进点，创新点


从上面的矩阵可以看到，在职级的能力模型行，要求上是立体的，可能某个点，例如技术的环境复杂度，就是熟练和灵活的运用公司现在的平台，框架，这点很多同学只要保持跟进，基本上都能够在较短的时间内掌握，但是例如在技术规模复杂度的提升与业务规模复杂度的提升，则需要丰富的经验与保持学习的态度，才能够完全掌握。
例如能够熟练掌握端到端的工具和知识，在 P6 包括但不限于：

  • 熟练掌握测试黑白盒，持续测试，性能测试等方法论
  • 熟练使用Jmeter，Selenium
  • 掌握 Java 基本知识掌握与常用类库，面向对象，面向接口，基础设计模式
  • Pytest 自动化测试框架搭建与使用
  • Linux 服务器常用命令
  • Shell 脚本
  • CICD 基础部署
  • Docker 基本概念与使用
  • 业务相关数据库，例如关系型，非关系型，图数据库部署与特性差异，常用SQL，等等，具体情况因公司业务需求而定

引用知乎测吧中一篇对于高级与资深在技术上的一个归纳，可以起到技术规模复杂度的参考作用，具体如下：


测试岗位 P5
jssh


测试岗位 P6
jssh

同时，在管理和业务上，也会要求除了交付，还要有质量目标规划，组内与跨组合作中的前后衔接，业务边界的熟悉，用户场景，竞品功能等多面的知识积累，慢慢的开始着手于下一层级的晋升。
P(Professional) 岗位不是只是IC(Individual Contributor)，而是会承载多方面的能力要求，其实只会低头走路是也不可能做好负责的工作，所以结合这些概念，下面让我们从 P5 到 P9 来详细阐述具体的要求和边界，同时也能形成有效的对比和直观的感受。

P5

对于 P5 来说，系统思考的范围是某个需求，熟练掌握本岗位的基本技术栈 （一般是本岗位工作经验 3 年左右，具体情况因业务和个人而异）
P5 的核心能力要求是在别人的指导下完成任务，主要提升目标是从 “工具人” 转变为 “工程师”。
技术方面 ，是核心中的核心，因为往往 P5 在业务和管理方面要求较少，在有能力晋升P6前，是一个夯实基础，循序渐进了解业务的过程。P5 需要打好基础，学习岗位要求的基础技术。采用 “碎片化时间，系统化学习” 的方法提高你的技术学习效率。
业务方面 ，也是 P5 要准备晋升 P6 时容易忽视的一方面， P5 需要熟悉各项业务功能的实现逻辑。对于 2C 业务，你要成为产品的深度用户；对于 2B 业务，你就要多跟客户交流。
管理方面 ，做好个人规划，需求规划，开始培养向上管理和向需求上下游管理的能力，P5 的重点是熟悉项目流程，避免踩坑。最重要： 熟悉业务的处理逻辑， 让自己成为产品的深度用户 有些技术人员连自己负责的产品都不用，只是机械地按照项目的要求完成任务（例如开发、测试、部署这些任务）。功能上线后，他们既不亲自体验，也不关心用户的反馈。 这样做的后果是，连基本的业务现状都很难清晰地了解，更别谈提升业务水平了。 这里引用 《大厂晋升指南》 关于 P5 的能力矩阵


技术 jssh

业务
jssh

管理 jssh

Q: 这里抛出1个问题，如果果在 P5 的时间很长，是因为什么问题？很短又是因为什么优势？这块会在后续我需要怎么做才能晋升中详细阐述。

P6

在 P6 这个岗位，核心能力已经从掌握所负责的业务模块，掌握岗位要求的技能，成长到有 技术深度，能够有 端到端的思维 去规划，分解，处理，落地所负责的具体任务的 负责人。
对于 P6 来说，系统思考的范围是某个需求，需要考虑需求的合理性、设计的可扩展性和上线后的稳定性等问题。
在技术方面 ，能够明白当前的所负责业务的所涉及技术栈的实现原理，不仅是知道 “如何(What)” ，也能够明白 “为什么(Why)”，核心源码，以及使用特性。例如对于后端，要深入了解springboot的设计思想，Bean 生命周期，Starter 实现原理，AWS Dynamodb Sharding，分布式，懒更新，渴更新等中间件实现机制与源码，JVM 核心机制，数据结构核心概念等等，从语言核心到中间件，到数据库，到服务器，容器化，分布式架构设计等等，这里无法一一列举，但是技术深度在这个环节就是核心中的核心，以满足在做设计时候的端到端系统性考量。
对于 P6 ，切记贪多求全，专注当前应用技术栈的深度提升，具体可以参考 知乎 中的一篇关于阿里P5-P8的技术要求，依据行业不同，业务不同，对于掌握的重点也会不一样，但是依旧具有参考价值，链接如下：
《Java全线成长宝典》，到了 P6 不代表已经全部掌握，而是代表 P5 的内容已经基本都掌握，可以开始自己的 P6 生涯，来不断精进当前的职级的要求。
在业务方面 ，需要开始关注需求的完整生命周期，用户场景，使用习惯以及后续反馈，能够在需求的评审中充分了解当前业务的上下文。了解竞品在相同场景下的优势劣势。
在管理方面 ，做好端到端的规划，掌握任务评估的方法，将任务做尽可能合理和准确的评估，做好跨层级，跨部门的依赖识别和沟通组织，做好技术方案的详细设计。开始做好 P5 同学的辅导工作。
对于任务的评估与设计，是 P6 在管理中的 核心能力，技术设计因业务不同而异，需要考虑的点会涉及从技术原理，技术实现，性能指标，成本指标，数据流转，边界异常，时序流转等等方面，可以归结到技术深度的思考部分。但是字啊工作量的评估上，则可以考虑以下一些关键方法：

  • 基于假设的经验主义
    • 对于粗的任务，基于过往经验与技术背景，做好合理假设，并充分考虑合理性
  • 群体评估
    • 对于详细的需求，多利用团队的思考，将范围尽量画完整，行程闭环
  • WBS
    • 对于完整的范围，利用 WBS 方法，将任务拆解成逐个小任务
  • 风险预判
    • 对于可能的风险，加上风险系数，留下合理的Buffer，以应对需求之外的变化
  • 任务支持
    • 对于任务的拆分，充分考虑支持任务的必要性，合理安排后续支持沟通时间

对于 P5 升 P6，只要 掌握好方法，有意愿向上，大多数人都是没有问题的。

这里引用 《大厂晋升指南》 关于 P6 的能力矩阵


技术 jssh

业务
jssh

管理 jssh

P7

如果说 P6 是一个过程，则升到 P7 就是很多人的一道坎，到了 P7 也会是很多人职业发展的天花版，这个级别很难再往上晋升，因为人们虽然进入到了一个职级，但是不一定达到人们的预期的中线和上线。艾伦斯.J.彼得讲到的是所谓职级就是你迟早会被提拔到你能力不可胜任的位置，也就是具有很强的天花板，如果不能突破天花板，就会被堵死在这。 对于 P7 来说，成为 团队专家 是 核心要求，领域专家在技术深度的基础上，还包括了一定的时间复杂度，和创新复杂度的问题，例如中长期的架构规划， 技术选型，领导技术方案落地的思考等，除了 “如何(What)” ，“为什么(Why)” 也要知道 “哪个（Which）”。对于 P7 要达到一定的技术宽度，学习能力 与 扎实的基础 是 必要条件。 技术方面，领域专家因岗位和行业而异，但是本质上是要有技术的 “宽度” 和 “广度”，以前端开发为例，在 P6 的台阶上（具体内容见下面截图），在 P7 中，不光是要能够掌握必要的 JS 框架，数据结构，网络知识，图表框架，图形库绘制API等等，更重要的是能够规划技术栈的演进，以及制定框架分层与管理规范，代码规范，提交规范等规划性的工作，能够在技术的演进和选型上引导团队 jssh

这里也说明一下技术深度，宽度，广度的定义：
技术深度：应用范围内技术核心概念的实现
* 例如：JVM 中并发标记的实现原理
技术宽度：应用范围内技术的全面特性和使用技巧
* 例如：JVM 垃圾回收的机制 Serial, Throughput, CMS, G1 等的横向比较
技术广度：应用范围内，多个技术的组合
* 例如：Java 高性能编程

业务方面，P7 对于所负责的业务，会开始有比较全面的思考，如果是2B业务，在了解上下文，业务模块的基础上，会开始涉及到竞争对手的营业模式，业务变化，业务与技术的实现关联，价值体现等 特别是对于前端岗位，因为需求在最前沿，变化和发展非常的快，无论是在技术还是业务的规划上，有着自己独特的优势，能够较直观的影响产品，但是也有着自己独特的要求，就是要适应相对来说频繁的技术和业务变迁，这里引用我比较认同的一段对于前端在业务上的一些思考，作者链接：

1 - 业务开发的前端难点在于对业务的理解和把控能力
业务开发的前端难点在于对业务的理解和把控能力。业务逻辑开发本身并不是难点，谁都可以写。但是对于你自己负责的这块业务，后续业务的发展方向和潜力，你有去了解过吗？
当业务方提需求过来时你是只负责执行还是和业务方一起探讨更合理的方案？你有没有给自己负责的产品提过一些建议？做过一些改善措施？
如果前端只是作为一个执行者，作为一种被调度的资源，那么即使最终项目取得了好的成绩，跟你有多大关系？你自己会有多大的成就感？
另外一个很重要的点：就是对业务的把控能力。业务方总是会催着上线，开发时间不断被压缩该怎么办？进度不如预期怎么办？开发遇到瓶颈怎么办？
发布新功能翻车了怎么办？我见过有默默加班保证进度的，也有跟需求方重新谈延期的，有发布出问题手足无措的，也有自己默默修复的，
有遇到瓶颈一筹莫展的，也有及时跟老板沟通，跟业务方撕逼的... 如何优雅的处理这些问题，有时候比写代码更难。为
什么有的人业务代码逻辑混乱，写的一团糟？我不相信是智力问题，反倒更相信是对项目本身没有把控好，本来排了5天工作量的需求被业务方压到了3天，
你还能保证写出健壮而不失风度的代码？

2 - 平台开发的前端难点在于产品化的把控和推进能力。
做业务时有人给你提需求，帮你出交互视觉稿，你只要负责写页面就行了。但是在支付宝前端，很多内部平台和技术产品都是技术自己主导，你需要自己发现问题，
出方案，设计数据库，自己出页面，这是一个从无到有的创造的过程。并且要保证你做的东西是真正解决问题的，而不是做一些自己觉得很牛逼实际上并没有解决用户痛点的东西，
用我老板的话说就是对产品的把控能力，不要跑偏了。前端是最容易做出产品化东西的工程师了，因为后端不会做 UI，UI 不会写代码，唯前端兼顾，这是最大优势。

这段看似粗糙的对于前端+业务的思考，道理却不粗糙。在业务上，P7，特别是前端的 P7 是一个可以推动产品向前的角色。 管理方面，P7 需要开始着手团队的技术（储备）中长期规划，规范团队技术栈，提升研发过程效率，辅助团队成员做技术突破，可以是一个3-10人团队的负责人，也可以是1-3人的骨干研发。 对于技术的使用，在 P7 很容易就陷入什么新用什么，有的时候甚至还没有完善的官方文档，也容易陷入大厂的盲目跟风，优秀的 P7 会依据自己本身的业务特点，来做技术规划，顺便也要想定义一下，什么是 大厂 除了BAT这样顶级大厂，我比较李运华对于大厂的理解，

1000人以上，研发产品设计人数400左右

TOC大厂会遇到几亿日活，巨型流量等问题，而TOB的大厂，也会遇到业务深度，数据深度，行业业务沉淀，行业强相关等问题。例如在一个TOB的数据服务公司，数据的加工和处理，数据内容的管理，数据的标准化，数据的分析以及事件抽取就显得尤为重要，P7 在数据的整体规划上体现的价值也尤为明显。但是并不代表只有数据的P7才要有数据技术的敏感度，作为后端，前端，测试的P7，一样需要知道大数据处理流程中的技术框架以及优劣之分。

这里引用 《大厂晋升指南》 关于 P7 的能力矩阵


技术 jssh

业务
jssh

管理 jssh

P8

对于 P8 来说，P8 是技术的成熟期了，在往后，随着精力，职责的扩大，已经不会再像 P8 这样在技术上的要求，甚至很多 P9 可能不会比某个 P8 在一些细节上掌握的更好，而P8的价值在于成为领域专家，需要考虑的是领域（Java后端，Web 前端，大数据后端等）的发展趋势、架构演进、团队组织结构，大团队或多团队管理等问题。
技术方面，后端领域，前端领域，测试工程领域，大数据领域，已经是有了前面所讲到的技术深度，宽度和广度，技能树上也有自己擅长的重点，掌握的要点，知晓的小点。可以看到每一颗技能树代表的就是 P8 需要深度，宽度上提升的，在之前的 《Java全线成长宝典》 中，可以了解到，作为 Java 后端的 P8，已经在大如 TDD，DDD，设计思想，数据中台，云原生框架上是专家，在细如 Spring 核心源码等方面也有不少的积累。真正是硬核的 P 级别人员了。
业务方面，P8 已经开始负责 更大 的业务 或 者 更多 的团队，比如文中 李运华 就是负责 2015 年当时阿里游戏中高可用项目，而例如一些大中企业，P8 也可以是负责多个产品线的技术负责人。
同时在业务的复杂度上，也会开始关心如何在业务上做出创新和改进，例如对于内容数据服务公司的 P8，技术上如何弯道超车，如何布局未来在技术上的壁垒，如何能够配合产品，打造市场上的优秀产品等就是其工作当中非常重要的一块。
管理方面，p8 对10-50个人的团队负责，在当前负责的领域有绝对的管理影响力，对于跨领域，也有着一定的跨域影响力，例如，从0开始构建团队，规划架构，培养梯队，完善流程，面向重点目标管理等。
这里引用 《大厂晋升指南》 关于 P8 的能力矩阵


技术 jssh

业务
jssh

管理 jssh

P9

对于 P9， 已经是 中层管理者 了，对应的职位是 XXX资深专家 等，在这个级别，不会只考虑当前的层的内容，更多会开始跨领域的组合业务，例如管理从前到后的整条技术产线，包括前后端，数据等跨领域的整合。同时，除了了解业内的新技术发展，也需要开始关心非本领域的技术动态，以便做出合理的决策。
技术方面，P9 不一定会比 P8 更深入，很多时候对于负责业务产线的 P9, 技术的广度在此时更加重要
业务方面，这也是最 P9 最 核心 的一块，开始负责从前到后的整体业务落地，包括本领域和非本领域的内容，同时开始规划一个业务的整体规划和突破，例如整个产品的 SLA 做到 5 个 9 等等，而是否能够 突破，其实是 8 到 9 的重要依据，当然也需要一定的机遇。
管理方面，管理人数不一定会有很大的改变，但是所面临的管理复杂度一定是会更高，因为涉及到了多个领域的内容。同时对于团队内梯队的建设，高职级人员的培养，也面临着更高的要求，例如对于 P7, P8 的骨干人员，需要给予到的支持，机会以及规划，复杂度，就比只负责一个领域要来的更高。优秀的 P9，一定是懂得如何与 P7, P8 如何配合，如何决策的。
简而言之对于 P9， 更多时候，核心还是要从业务中取得突破，获得成绩来不断提升团队和个人在本领域以及跨领域的影响力与决策力。 说道对于机遇的把握，不得不说，在机会面前人人平等，机会总是给有准备的人，可能平时的积沙，会变为最后的成塔，平时的输出，会潜移默化影响周围。 对于快速成长的企业，例如我现在所在的公司，能够一直有新的产品，新的变化是一件值得高兴的事情，因为快速的成长和打破的常规，很多时候就是代表了更多人有机会来展现自己的能力以及有机会来突破当前的壁垒。 同时，对于业务团队还是底层技术团队，我觉得没有孰好孰坏，只有围城。真正能够突破围城，看清价值才是核心。之前在平台组，也依旧有过无法直接推广到业务团队的困扰，而在业务团队，也有过怀念技术执着的日子。所以，在任何一个平台，努力将自己的能力模型提升，面向价值提升，才是最重要的。而价值，就是这一个个抽象的能力一点一点积累来的。 这里引用 《大厂晋升指南》 关于 P9 的能力矩阵


技术 jssh

业务
jssh

管理 jssh

如何判断是否达到晋升标准

  • 年限
  • 绩效 - 做好当前级别的事
  • 能力 - 下一层级能力的体现
    • 技术
    • 业务
    • 管理
  • 竞争 - 名额内, 比其他待晋升做的更好

对于年限，在跨越式职级的每个级别或者阶梯式职级的高职级中，一般不会连年晋升，因为一个能力模型成长，处理复杂度的能力不会在短时间内达到下一个层级的要求。 特别越到往上的职级，越是这样。 对于绩效，则是体现工作输出的直观表现，在 5 分制的考核中，一般不会说绩效2分，然后提名晋级这样的情况，因为被提名的同学，必须是有良好的执行力和规划力，在目标的达成上有一定贡献和突破的。
对于能力，在积累到一定经验后，把握机会，开始展现下一级别能力，并取得一定的认可。一般，对于每个级别，都不可能是因为一个候选人完全达标才能晋升，而是已经开始展现能够掌控更复杂场景能力的情况下，就会有机会。
对于竞争，每个公司都会在名额上进行严格的控制，这样是出于3个目的，1-级别的认可度，不至于通货膨胀，一文不值。 2-团队梯队的健康度，做到良好上下衔接与梯队管理。 3-能力的打磨度，避免浮躁的晋升狂热，而是专注在持续精进。

我需要怎么做才能晋升

回到之前抛出的问题：
Q: 如果果在 P5 的时间很长，是因为什么问题？很短又是因为什么优势？
A: 也许，这个问题每个人都会有自己的一个答案，例如机遇不佳，性格使然，晋升标准不明确等等。但是在我看来，这些都是可以改变的，尤其是在 P5 到 P6 的过程。在上面，我们看到了 P6 的能力模型和所要求的复杂度，其实本质上除了技术的深度是随着经验可以增加之外，对于业务和管理复杂度的把控能力不足是很多同学 P5 到 P6 一直止步的原因。 让我们做一次向上管理，当你期望你的主管提名你作为晋升候选人的时候，提名词你期望你的主管会写什么？技术上精通了某某技术？业务上完成了安排的任务？
这些是不足以打动审批人的，应该体现的是有掌控更复杂环境的能力。例如：技术方面：熟练掌握XXX技术，通过在XXX业务中，对XXX框架做出的改进，达成了XXX的性能提升和效率改进。业务方面，主动跟踪和分析竞品功能，推进XXX需求的改进和落地，从用户的 XXX 角度多次提出有效意见，并在此业务中承担主要工作。 在管理方面，能够在通过对于业务的掌握，产出完善的 XXX 技术方案，并依此准确评估了功能并推进落地。其次有着良好的自我成长规划，通过对 XXX， XXX 等主题的分享，激发了团队对于XXX的深度思考和讨论，建立了良好的技术影响力。 说到这里，再去看 P5 到 P6 容易忽视的3点，技术上体现出技术深度和产出价值， 业务上了解上下文，推动业务发展， 管理上体现出对于任务的掌控力和对于自我的规划力。 再来看到，“体现技术深度” 这个命题。事情做的多，做的好，不一定晋升，但是是晋升的前提，一般每个人都会随着经验的增长，而不断精进自己的技术深度，可是每个人虽然是自己生活的主角，但是在团队中不可能一直有一只眼睛盯着你的所有成长，此时以下工作中的安排就是我们可以良好展示自我的场合：

  • 代码走查
  • 主动分享
    • 文章
    • 培训
    • 发表意见与建议
  • 技术创新
  • 同事口碑
    • 效率口碑
    • 质量口碑
    • 教导口碑

再来看到，“机遇” 这个命题。正如我们之前所说，机会是留给有准备的同学。在框架内用于试错，经验一定是练出来的。同时，也要在工作中主动发现和推进合理的改进。所谓等待机会不如创造机会。

最后来看 “成长” 这个关键点，每个人在自我规划时总是渴望成长，但是只有很少人能够将自己的成长规划好，执行好，表达好。面向价值成长，是一个高效的成长方式。业务的价值，需要的技能不一，可以是某一个需求，对于推荐系统有着深度的要求，某个需求对于图表的深度定制有需求等等，能够通过自我成长，将需求结合自己的成长，并最终 “发出声音” 才是价值体现的良好闭环。

当然，除了这些主观能动性的点，有的时候，晋升也会面临客观因素的干扰

  • 频繁的更换主管和团队,。新的团队，新的主管，新的氛围，和团队文化，每个人都有互相了解的过程，有的时候，晋升，不光是主管，团队的认可也是很重要的一个因素。
  • 因业务需要更换岗位，重整技术栈。一般，更换岗位，更推荐互相有关联紧密的平移，例如从 Web测试工程师 到 大数据测试工程师，从 Web 后端研发到 搜索引擎研发。不推荐的则是完全重整自己的技术栈，例如从 前端 转 大数据研发， 从数据分析转后端研发等。 合理规划好自己的职业生涯，做好向上管理，期望管理，尽量避免客观情况，是能够保持晋升态势另一个重要的点。

保持一颗学习的心态

  • 不闻不若闻之，闻之不若见之，见之不若知之，知之不若行之；学至于行之而止矣 - 荀子
  • What i hear, i forget, what i see, i remember, what gi do, i understand ! - 荀子名言广泛被引用的英文版本
  • Concept （概念）、Teach （教给别人）、Review （评价）、Simplify （简化） - 费曼学习法

也许每个人都有自己的一套学习方法，但是要保持一颗学习的心态，是一件不容易的事情，也是随着年龄增加，所会面临的精力困境，但是同样，这个世界上也有很多终生保持学习，不甘原地踏步的人，以下的经验来自个人认同和实践

  • 成长规划，对于成长规划，有过面试经验的同学都会有同理心，这部分看似简单的问题，却常常让自己语塞。成长的规划有短期，中期，有长期。先有计划，再有执行，永远是不错的习惯。以一句俗语，低头走路，也要抬头看路。
  • 设定目标，针对于规划，制定相应的目标，例如通过考试，完成分享，实现 demo，落地业务，都是一个个具体的目标。成就的认同感，往往就是目标的达成，让目标驱动，并获得认可，是最好的成长闭环。
  • 面向岗位核心价值学习，这点是从小学课本上就教授过的，看到什么好，什么新就学什么，也许做业务开发，编译原理很难再实践到，在这个贩卖焦虑的时代，从领域内的核心价值开始，保持专注，永远都没错。随着积累越来越多，质变会让自己能够驾驭的范围越来越广。
  • 时间管理，要善于利用碎片时间系统学习。如 李运华 专题中所讲，可能普通人，10000 小时的专业时间下才能成为领域专家，10000小时，相当于假设平均每天4小时专注在当前专业，则需要8年的时间才能成为领域专家。而4小时，肯定不是重复的劳动，而是不断学习，精进的劳动。如果说工作的8小时换算成精进平均每天是3小时，则在工作之余，保持每天1小时的学习，周末每天保持2小时的学习，是非常有必要的。而睡前的半小时，早晨注意力最佳的半小时，周末挤出来的2小时，就能让平时有更多的时间学习，成长。

总结

职级，晋升 是个人成长的体现，就像游戏的打怪升级，段位提升。每个人天赋决定着上限，努力则体现着下限。望所有人能有一个无悔和多彩的职业生涯，大家加油。

Reference:
https://time.geekbang.org/column/intro/366 https://mp.weixin.qq.com/s/RFdUhXfJgYDnwaq7Dme8RQ https://zhuanlan.zhihu.com/p/117490792 https://www.mawen.co/question/589 https://zhuanlan.zhihu.com/p/89242311 https://www.zhihu.com/question/328835517 https://www.zhihu.com/question/31196176 https://zhuanlan.zhihu.com/p/348594410 https://www.zhihu.com/question/275915023