聊一聊 P4-P7 的跨级瓶颈及如何有效突破

一、前言

本文尽量大白话，少点啰嗦，内容都是堂主（本名马翀，2006 年开始捣鼓前端）这些年工作下来的一些思考，不可能面面俱到，但尽量把我认为重要的点能提到。

二、关于层级

在交流不同阶段的成长瓶颈之前，我们先对称下岗位层级的概念。这里以阿里的层级体系（P 序列）为参考，这里重点阐述下 P4 ~ P7 这四个 Level，这也是目前绝大部分前端同学所处的层级区间段。

P4 初级工程师

一般是指刚毕业的应届生，或还不具备独立研发执行能力、仍需辅导的职场新人。阿里巴巴等一线企业，因为招聘标准的提高，2013 年以后应届生逐渐就是 P5 能力起招了。但对于其他绝大部分互联网公司而言，实习生、刚毕业 1 年左右的应届生，多是在这个能力层级内。



初级工程师还不具备独立解决问题的成熟度，需要必要的辅导。其能力和解决的问题都是 “点” 的形态，把离散的需求点一个个的执行完成。

P5 高级工程师

一般初级工程师工作 1 ~ 3 年左右（受学历、平台、业务、个人悟性要性等因素影响）即可晋升到这一层级。高级工程师在公司内基本上都是业务执行为主导，在明确的业务、团队目标下，独立的执行完成既定内容的工作。



高级工程师在解决问题的过程中，需要能在点的基础上纵深的扩展，在把一个点做完的基础上，能继续深入做到更好，即面向 “线” 的能力。

P6 资深工程师

多是工作 2 ~ 5 年左右能达到这一层级。资深工程师在团队中的角色，一般是业务上作为某块业务的核心接口人、组长，或该业务的职能 PM 角色；技术创新上，也能在某方向的某个专项上，作为主力核心角色；团队层面可以作为师兄，承担辅导角色，带动新人成长。

P7 技术专家

前端行业的硬通货，晋升到这一层级多是在参加工作 3 ~ 8 年左右 —— 你没看错，确实是存在参加工作仅 3、4 年就晋升到这一层级的优秀同学。在大厂，P7 一般是团队内核心，部分 P7+ 可以作为一线团队的 TeamLeader，或某方向技术建设的核心中坚、Owner；在比大厂体量小些的独角兽或中型企业，P7 多是一线团队的 TeamLeader 或架构师。



从初级到专家，从点到线，从线到面，从面到体，不同阶段会有不同阶段的瓶颈。对应的，是其背后的认知局限。



如上图，从抽象提炼的关键字角度来看：

• 初级工程师的核心能力，是执行上能够 独立做完；

• 高级工程师是要能够 做好，能持续优化、追求卓越；

• 资深工程师需要开始突破自身，对他人和业务产生积极有效的 影响；

• 技术专家要能够塑造环境和空间，成就 团队。

三、瓶颈与破局

技术的价值在于解决业务问题，层级 or 身价取决于解决问题的能力。

初级到高级（P4 → P5）

先谈下我个人的一个观点，刚毕业的应届生，尤其是本科生，我强烈建议最开始的头 2 年，应尽可能的扎到业务里去。这个阶段对职场新人来说是非常宝贵的沉淀时期。你做的业务越多，你积累的面向业务的研发能力和技术方案就越多，你所掌握的解决单点问题的能力和方案就越多。这个时期别怕累，也别怕事情杂，因为这个阶段做什么对刚毕业的同学来说都是一次 0 到 1 的积累。在这个时期，重要的事，是养成一个良好的职业习惯，保持住积极的要性和冲劲，重视沟通能力的培养，多主动承担，多阅读、多思考、多沉淀总结。

很多同学在工作 1 年多或 2 年左右，会开始遇到第一个明显的瓶颈期，这个阶段一般的状态会是：

• 一聊到业务，头脑里最清楚的是需求列表里未来 2、3 周的那些需求；

• 往往评审时 PRD 也不太认真看，反正做的时候哪里不明白，问问产品或者后端就行了；

• 自己对接的业务已经挺熟了，该做的功能也基本上都做过一遍，感觉业务做的越发没意思，每天就是各种小修小补，没什么成长的感觉了。

我相信很多同学都经历过这个状态，或者目前就在这样的状态里，但还没认识到风险，只是觉得不像最开始那么有冲劲了。这是因为过去的新人期，已经习惯了被动执行，且因为经验和能力的不足，事情都是奔着独立执行做完，逐渐习惯了 “做完就好”。



对于这个阶段的突破，需要先从认知上做转变 —— 做完不等于做到，要对自己有更高的要求，从做完到做好。



如同样是写业务需求，如大家最熟悉的写代码上，能考虑并践行代码的语义化、可读性，注释的有效性，合理的利用数据结构、面向对象的设计，而非是面向过程的意识流堆砌代码；考虑函数的单一性、可扩展性；考虑代码的运行时性能；文件之间考虑合理的功能解耦和模块化拆分，核心组件接入单测保证可测试性；引入 *Lint 优化代码的合规性；考虑代码的可协作性、可维护性；优秀的文档沉淀，不限于业务文档、技术文档、接口文档、流程图。

上面还仅仅是针对个人本地编码环节的一点事。在面向业务支撑中，能做的更好的方面非常多。请注意，这里我说的“业务”，和很多同学眼里的 “业务”，可能不是一个 “业务”。试着自己思考一下，下面这些问题：

• 角色上有协同执行、核心主程、接口人 PM；

• 流程上有不同环节的评审、方案、拆解、执行、过程跟进、资源协同、风险控制、复盘总结；

• 深入度上，业务理解和优先级的判断、业务节奏和技术前置储备、目标对齐和产出 ROI、局部价值和业务大盘；

• 成本上对人效和质量的认知，具体的应对策略、落地路径；

• 能力上除了基础的技术能力为代表的专业能力，还有沟通、反馈、协作等为核心的职业能力；

• ...

这些是我眼中，独立跟好一块业务，需要考虑和面对的那些基本的事，而绝不仅仅只是把需求列表里的那几个需求做完。不满足于完成某个点的功能，而是进一步尝试，在自己能力范围内做到极致，由点及线。

高级到资深（P5 → P6）

一般在高级工程师的位置上做了一段时间后，一般的优化能力往往都具备了，不同的框架、库玩得都溜溜的，高级 API 也掌握了不少；谈到提效、体验或稳定性，也能侃侃而谈不同选型、工具、策略的差异性；开评审的时候往往瞬间就能在脑子里形成相对优异的技术方案，或看出产品设计中某处存在问题的细节。在高级工程师的这个时期，能力上已经是一个合格的业务主程，不论是专业能力还是职业能力，都能较好的完成并做到持续优化。

这个时期的瓶颈，往往体现在下面的这些状态：

• 对自己负责的业务很熟悉也很尽责，但对其他业务了解的并不多，也没有主动去了解的想法；

• 比较清楚的知道自己的特长和阶段性能力短板，但对其他同学在做什么、为什么做没有更多的了解；

• 知道团队中正在进行的一些建设，但基本是作为旁观者或产出结果的使用者；

• 知道自己的绩效目标，但不清楚业务方、协作方的目标；

• 比较清晰的知道哪些事是自己的，哪些事不是自己的。

如果说，初级和高级的阶段，是从业务、团队中汲取，那资深工程师及以后的阶段，就是要向业务和团队进行反哺。如果说，初级和高级的阶段，是别人叫你去做什么事，那资深工程师及以后的阶段，就是你要想去推动什么事 。





作为资深工程师，很重要的一个特质是需要能开始去影响，由之前的单维度的输入，变为输入 + 输出。基于自身已成长出的优势，主动的帮业务和团队解决更多问题，产生积极正向的影响。

资深到专家（P6 → P7）

在资深工程师这个层级上一段时间以后，其能力上已经成为团队的执行中坚。业务角色中，可以影响业务预期，主动推动业务在流程、方案、架构等方面的优化；技术创新上，能在某个专项主导攻坚并拿到结果；团队建设上，具备当师兄带新人的能力，也能作为小组组长带动新人的成长等等。能够独立的发现问题，且能主动推动着手解决问题。

资深到专家这个阶段的瓶颈，往往体现在下面的这些状态：

• 具备良好的发现问题、推动和技术攻坚的能力，但往往自己一个人就能搞定了；

• 推动和解决的事，往往是针对已有问题的补窟窿、打补丁；

• 能很好的解决问题，但没太想过如何能前置性的避免问题。

这个时期的瓶颈，同样是因为认知的局限，破局策略在于两个方向的大维度：空间 上和 时间 上。

• 空间维度，需要建立一个立体的体系化认知模型，不论是业务支撑策略，还是技术发展策略，都需要建立对应的体系化认知。

• 时间维度，需要在深入了解业务、团队的基础上，站在未来看今天，看半年、一年、两年后的业务会是什么阶段，从那时候的业务支撑诉求看今天的体系和团队的能力，谋而后动，前瞻性布局。

到了专家这个职级，需要通过 前瞻性 的审视，推动 体系化 的建设和落地，帮助业务和团队持续的带来 改变。

专家到高级专家（P7 → P8）

其实对于本文的看官，相信绝大部分同学还没到这个阶段，但这里还是说一下，从专家到高级专家或更高的瓶颈会是什么。

说这些之前，先说一下我自己成长中的一个故事，那时的我参加工作还不久，满脑子最令我兴奋的，还是在琢磨代码的可读性、结构分层、模块拆分等应该怎么折腾，在半年后重新再看，依然能第一时间看懂其中的流程和逻辑 ；或者力求视觉还原度能精确到 1 像素，且能保持近乎完美的 HTML 结构上语义性和可用性 —— 恩，那个阶段的我有很长一段时间沉迷于此不能自拔，乃至还拿过那一年淘宝前端团队的 “精益求精” 奖。那时候的我曾经问过一个现在看起来很 Sha X 但当时确实很困惑我的问题：“某某是怎么晋升到 P8 的？”

是的，那时候的我确实很困惑于此，看上去某某手里也没什么业务，又不怎么写代码，但是晋升到了 P8，水不水？

现在的我对这个问题已经有了自己的答案，回顾当时的自己，实际上是在拿一条线的认知去理解多维体系的价值，看不到全部。现在我会知道，当时之所以会有这样的困惑，是因为不同阶段的不同段位，并不能在同一个维度上去认知问题和解决问题。这就好像当年老赵小品中的段子，问有钱了怎么花 —— “也学人家去大城市旅旅游，去趟铁岭”。

每一次破局的背后，实质上都是认知的一次突破。比如对于 P8 眼中的 “基本功”，可能会包括但不限于如下的这些：



这些关键字背后，往往都有对应的体系化能力。能认知并为自己所理解是一个局面；光知道远远不够，实践过知道怎么去落地拿结果是进一步的层次；知进退懂取舍，能知道什么时候该做什么，是再进一步的段位。



对于从专家到高级技术专家，不论是继续走 P 序列（专业线），还是转为 M 序列（管理线），这个阶段的瓶颈很多是在于打破职能、业务对自身带来的边界感和惯性，如只局限于从本职能视角看问题和解决问题；只看到自己部门，局在自己的业务领域跨不出去；局限在通过单一维度的体系能力解决问题，认知不到其他体系建设的复利价值。

四、一些感悟

1、业务与技术，是同一件事的两个面

技术的价值在于解决业务问题，“业务支撑” 和 “基础建设” 从来都是同一件事的两个面，这个 “同一件事”，就是帮助业务解决问题。前一个解决业务 “活在当下” 的问题，后一个解决业务 “拥抱未来” 的问题；前一个是对业务诉求的单点式解决，后一个是提供通用方案解决共性普遍问题。都是在用技术的方式解决业务问题，但投入产出比上存在着不同。架构能力和技术创新，从来都是伴随着业务的普遍、共性、高频问题，不会凭空生出。不深入业务，不直面问题，也就谈不上技术成长和创新。

2、成长，从来都是自己的事

《庄子·列寇传》有一则寓言，“朱评漫学屠龙于支离益，单千金之家，三年技成而无所用其巧”。讲的是一个人散尽家资学习屠龙之技，学成却发现世界上本没有龙。对于研发同学，同样会存在从方案出发找场景的问题，如想学习 Node 不知道如何学习，照着书中的例子学，最后发现都忘了效果很不好。没有一个作家是看小说看成的，也没有一个语言学家是看字典看成的，同理技术专家也不会是通过看技术书籍养成的。在实践中学习，从来都是最快的方式。有价值的事从来都是从业务本身的问题出发。问题就是机会，问题就是长萝卜的坑。

这个市场永远不缺资源型的执行。快速发展的企业，基本的业务建设支撑，可以通过校园招聘应届新人，或者借助劳务外包的方式解决。对于很多企业来说，花大力气去搞定一个资深工程师、专家甚至高级专家的社招坑，要的是这个人能去推动正确的事情发生，让事情朝着更好的方向推进落地，这要求有能力突破个人的范畴、通过影响他人去一起拿结果。

公司和管理者能做的，是提供发展的业务、多维度的空间、必要的辅导给到员工。但其中的成长，从来都是员工自己的事。

3、晋升是一个结果，而非目标

晋升是一个结果而非目标。绩效好不等于一定能晋升，晋升一定是已有明确的落地结果，自己的工作对这个结果是产生直接、具体且显著的贡献。在这个过程中，体现了像下一个层级那样思考问题，在做下一个层级做的事、并拿到结果。

4、离职应是个匹配行为，而非冲动

一如招聘入职，离职也应是个匹配性行为。但很多的离职，是因为正处在当前层级的瓶颈而不自知，如同会有同学拿平台光环和其放大器作用，误认为是自身能力，也会有同学拿瓶颈期的不适当成是平台或空间的问题，但当他自己没具备看清当前问题的认知、没具备打破当前局的能力时，离职换一个平台做缓冲，新工作的 "蜜月期" 一过，同样的问题还是会重新出现。

5、最后，问自己一个问题

◆ ◆ ◆  ◆ ◆
长按即刻关注

你的在看我当成喜欢