02 规划之问（2）：研发、测试、运维不同技术岗常见职业路线

你好，我是雪梅。

不知道你有没有这样的疑惑：

我现在的职业发展进行到哪一步了？
再往上走还需要往哪方面努力？
如果我想转岗，会面临什么困难？

更不用说在技术飞速发展的今天，还经常出现岗位消失、岗位融合的论调。

很多时候，我们的慌张来源于无法及时认清自己所处的位置。

这一节，我们就跳进技术人不同的角色，研发、测试、运维，去看看不同角色常见的职业发展路径和能力要求差异。有了这份导航，也会让你对未来有更清晰的认知，减少很多迷茫，甚至在别人的路径中找到适合自己的路。

这里先提一句，无论是研发、测试、运维，都有可能走向管理岗。转管理的事情，我们下节课再说，今天我们只探讨非管理岗的发展。

研发岗规划之问

研发岗细分为前端、客户端、后端、算法等。无论哪个研发岗位，在我看来，目前的趋势都是朝着两个方向分化，一个是向上浮，靠近产品、业务的 业务研发，一个是向下沉，做专业技术攻坚的 底层技术研发。

这两个方向对于能力的要求会有哪些差异呢？

业务研发 VS 底层技术研发

以客户端研发为例。底层技术研发，主要负责客户端的基础架构设计，解决性能和稳定性问题，以及客户端的容器、配套工具链的设计研发等。这就需要研发同学对相应的底层技术掌握到炉火纯青的地步，有非常强的专业技术攻坚能力。除了技术，还要具备良好的服务意识，因为虽然不直接面向外部用户，但面对的用户是工程师。当然，还要有内部产品的设计、推广以及最终落地的产品闭环能力。

和底层技术研发相比，业务研发就不再单单是个工程师了。除了常见的编码、问题分析定位等研发基础能力之外，更考验的是把业务或商业问题转变为技术问题，并能最终解决掉的技术应用能力。最后，就是和产品、业务等职能的跨角色沟通协作能力。

这两种分工就好比练武。有的人对剑法很感兴趣，就每天苦练剑法，把剑法练到天下第一。有的人可能会一点剑法，也会短刀、大刀，可能还会点拳法，每一项都不是最精通，但他知道面对什么样的敌人，在什么样的场景下，如何组合运用这些本领打败敌人。前一种就好比底层技术研发，后一种好比业务研发。

未来的发展路线

底层技术研发的发展，有三条路。当你的“剑法”练得足够好，你就会成为这个 领域的专家 。比如玉伯老师一直致力于设计语言Ant Design、数据可视化AntV等的研发，在大前端圈享有盛名。

未来只要这个世界上还有场景需要你的独门绝技，你就有生存空间，甚至当你有足够的技术壁垒，还可以实现 技术创业，这就是第二条路。

而一旦你成为某个领域的专家，也可以把技术传授给更多的人，帮助别人成长。这就是第三条路， 知识付费。

如果说底层技术研发未来的发展，相当于我手里有一把厉害的剑，满世界去找什么场景需要用这把剑，那么业务研发的发展，就是手里没有厉害的剑，但我们背了一包武器，去找这个世界还有哪些场景有未被满足的需求、没解决好的问题，再用这些武器去解决。

所以，业务研发有两条常见的发展路径。

一种是成为某个 业务方向的专家。当你聚焦于一个业务，解决的问题越多，对这个业务面临的问题和解决思路就会越来越熟悉，逐渐成为这个业务方向的专家。

比如我的一个朋友，最近几份工作都在金融领域，他本身也对互联网金融感兴趣，所以致力于成为互联网金融领域的资深架构师。这其实是技术与业务领域的深度结合。对他来说，不但技术架构能力要足够好，还要对金融行业的专业知识有一定了解。

业务研发的另一条路是 往更综合的方向发展。因为业务研发本身对一个人的业务、产品、技术能力有一些综合要求，只是最开始用得更多的是技术手段。这个方向的同学会不断地解决真实世界中的问题，随着后续发展，逐渐组合运用更多的能力。我身边有不少四十岁以上的朋友，早就跳出技术人的标签，去做业务、做销售、做投资或者自己去创业，走出了一条更广阔的发展路径。

测试岗规划之问

测试岗和研发有些相似，常规路径就是业务测试和测试开发。

业务测试 VS 测试开发

业务测试，顾名思义，做的是服务于业务系统的质量保障工作。日常的工作除了项目测试之外，还需要快速判断业务的质量状况，然后基于现状灵活制定方案、解决问题。

因此，一个优秀的业务测试，需要具备4项能力。

测试的基础能力。比如测试Case、测试场景构建、测试方案落地的能力。
专项测试能力。指的是利用开源工具或公司现有工具，完成性能测试、稳定性测试、竞品评测等业务专项质量保障。
项目管理能力。因为测试属于发布前的最后一个环节，为了保证项目的顺利交付，测试同学就天然被赋予了一部分项目管理的职责。
测试架构能力。包括业务质量的识别能力，尽可能量化的质量分析能力，根据质量分析结果设计质量方案的能力，推进质量方案落地、复盘以及迭代优化的能力。

比如你负责的是一个交易系统，作为业务测试，你需要与研发一起梳理系统的关键链路，结合历史质量情况分析出当前系统的质量隐患。还要结合业务发展阶段以及当前的资源情况，给出明确的质量提升计划。这个提升计划可能涉及稳定性建设需要怎么加强，怎么设计核心链路的监控，哪些链路需要引入自动化测试，以及项目流程中哪些环节需要改进等等，这些都要想到。

再说说 测试开发。和业务测试相比，测试开发负责的更多的是通用测试工具或测试框架的开发。但一个优秀的测试开发，所有的行动最终都要指向业务系统质量和效率的提升，不能局限在工具的开发，低头造轮子。除此之外，还需要深刻理解团队需要什么样的工具，跟进工具的落地以及工具使用的效果。而且你会发现，在目前的发展趋势中，测试开发同学越来越关注研发效能，要从全局维度思考如何提升交付效能，提升研发效率。

举个例子，小A负责外卖的检索服务系统，发现产品、研发每天都要花不少时间处理商户反馈的问题。比如商户经常会说，为什么我家的店铺没有展示在相应的位置上？其实这个诊断过程是可以流程化的。于是小A做了一个检索工具，输入商户ID，搜索地点，就可以显示整个检索召回的中间步骤和结果，还根据研发和产品使用过程中的反馈，不断地将中间结果可视化，优化工具的使用，大大解放了研发和产品的人力。

测试开发的能力要求与研发有些类似，都需要有不错的编码能力。但相比研发对技术深度的要求，测试更关注技术的广度。测试开发同学要交付的产品一般都是公司内部产品，不像研发要面对高并发流量，但对测试开发同学来说，能快速地完成工具开发非常关键。

随着这几年测试人才的发展，很多大厂测试团队对于测试同学的编码能力也有了很多要求。很多业务测试小伙伴在日常中也会做测试开发的工作，有互相融合的趋势。

未来的发展路线

测试岗整体来说是多面手，很多人调侃说，测试比开发更懂产品，比产品更懂实现。测试同学在日常工作中经常负责项目管理、质量运营等多个方面，因此长远发展路径有很多，我看到的主要分为三种。

专注于提升研发效能，做技术专家。比如业界知名的软件质量和研发工程效能专家茹炳晟。
业务领域的测试专家。即在一个行业深耕，技术上走专项路线，比如《云原生研发测试》的作者孙高飞一直深耕云原生领域，成为了这个领域的测试专家。
转型。因为测试岗的多面性，天然具备转型的可能性。比如我看到不少测试转研发，转产品，甚至转PMO项目管理岗。

“研发:测试”比例持续下降，测试岗何去何从？

关于测试岗，我们再多聊一个问题。

这几年，很多大厂都在降低“测试:研发”比例，我记得2008年，很多团队的“测试:研发”比例大概在1:3到1:5之间，而这些年，1:6成了基础要求，有的成熟部门做到了1:10，甚至在“去QA（去掉测试岗）”。

不少测试小伙伴担心，未来测试岗会消失吗？我该何去何从？这个问题我跟几位从业十几年的测试大佬交流过，这里也分享给你。

我们先说说“去QA”的本质。 去QA，本质是在解决效率冗余问题。 程序在不同角色中间流转，一定会造成效率的浪费。一个产品的诞生，通常会经历“产品-研发-测试”这样的过程，然后测试发现Bug，再反馈给研发。这期间确实存在资源的浪费。在理想情况下，如果研发能交付高质量产品，那么QA确实是可以被裁剪的角色。

因此，去QA的前提，是保障前置的研发步骤中开发出高质量的代码。再往前倒，就是让产品交付高质量的需求文档。质量的要求是恒定的，即使QA角色没了，质量保证工作并没有消失，只是转移到了其他角色身上，或者以其他方式提供。简单来说，就是质量还在，只是不用业务测试来保障。

现在我们再谈“去QA”这个问题，就很清楚了。在“去QA”趋势下，测试会逐渐从原来的业务测试、流动的团队，慢慢过渡到一个赋能的团队。不再是点对点去测试，而是提供质量保证的思路和能力，把质量保障框架的设计能力、方案实现能力以及测试落地能力，以培训、流程梳理或者工具的方式赋能给整个团队。

最后我想说，国内的“去QA”是一个漫长的过程，即使在去QA的趋势之下，质量保障工作并不会减少，测试同学依然还有很多要去历练和成长的能力，依然有很多可供选择的发展路径，不用过于焦虑。

运维岗规划之问

运维岗可以说是过去十几年技术岗中变化最大的一个岗位。不少运维小伙伴问我，现在系统都上云了，未来运维还有发展空间吗？要回答这个问题，就要先了解运维岗的诞生和发展过程。

运维岗的发展趋势

运维岗在国内的发展大致经历了4个阶段。

第一阶段，打杂。 大约在21世纪初，国内运维岗随着第一批互联网公司的出现而诞生。

那时候百度盛传关于第一代运维的段子：招运维是“靠称称的”。什么意思？就是体重得够。为什么？因为那个时代的运维是要扛机器的，要自己跑机房。这里有段子的成分，不过也从侧面反映了最开始运维的诞生是因为有很多杂活。但是招研发太贵了，那就招一些运维岗吧。

第一代运维一般对学历、经验的要求会比研发低一些。我有个朋友之前在新疆当计算机老师，后来决定北漂，面试研发岗根本没机会，最后通过运维岗拿了一个满意的Offer。

第二阶段，规模化带来的精细化运维 。随着互联网飞速发展，大概在2008-2010年之间，各大互联网公司快速扩招，研发人数迅速增加。人越多，犯错的概率越高，而且随着业务体量的扩大，一旦犯错，成本将也大大增加。

因此，这个阶段运维的主要职责是减少研发的失误，降低线上系统故障的概率。至此，运维岗有了精细的分工，比如网络机房、基础组件运维、业务运维等。

第三阶段，NoOps。 随着系统工具的完善以及公有云的普及，在2015年左右，业内开始推NoOps。很多之前的运维工作被系统和工具取代，运维岗大规模缩减，很多运维同学被迫转岗或离职。

第四阶段，面向业务的SRE 。上云之后，系统的问题没有彻底解决，故障依然存在，研发系统模块互相依赖，查Bug成本很高。于是，最近这几年出现了面向业务的SRE，尽可能降低研发的开发成本，让研发将更多的精力聚焦到业务上。目前很多头部大厂都有专门的SRE部门。随着AI技术的发展，在运维领域可能也会出现更多AIOps。

在运维岗的发展历程中，你会发现，当前运维岗的工作价值与业务规模强相关，规模越大，越能更好地发挥杠杆效应，因此好的运维离不开大厂。

其次，随着公有云的普及，运维越来越朝着与业务结合的方向发展，能力要求也逐渐综合。比如面向业务的SRE岗，既要有运维经验，懂网络、机房、常见中间件，又要了解业务架构。

而且，运维的能力模型，除了技术、经验之外，通用的软素质也越来越重要。比如要有大心脏，遇到故障不能慌，还要有很好的推动协调能力，最好还要有对问题的洞察力，也就是思考、分析以及解决问题的能力。

未来的发展路径

那运维岗未来的发展路径会是什么样呢？前面提到的SRE是一条路径，很多的运维小伙伴都在大厂做SRE工作，还有一条路，就是做业务架构。

我的朋友杰老师做了几年运维，因为工作特别努力，也做了非常多的技术积累，对于高并发架构设计、多机房主备架构等都了解得非常清晰，还多次帮助业务搭建更稳定的架构。有了这些积累，后来他拿到一家央企的架构师Offer，帮助央企下属子公司的系统上云。

在这段经历中，他已经成功转型为一名业务架构师，后来也做起了技术管理。这几年环境不好，央企也有很多变化，他用自己的复合经验和朋友创业，现在做着技术咨询工作。

岗位融合与能力发展

前面我们分析了研发、测试、运维这些不同岗位的常见发展路径，其实，这几个岗位也有千丝万缕的联系。事实上，这几个岗位之间的转岗也很多。

其中，从测试或运维转到研发岗的相对更多。因为技术具备相通性，且研发处于上游角色，整体岗位需求量大。比如大厂现在的“测试:研发”比一般在1:6左右，成熟业务可以做到1:10，而运维（含SRE）:研发在1:100左右。

那你可能会问了，未来这几个岗位会融合吗？我觉得有可能。毕竟细化的分工是公司到一定规模之后才出现的，很多小公司就没有细致的划分，随着AI的渗透，可能还会有新的变化。

不管未来会不会融合，作为技术同学，都可以选择在自己擅长的领域不断打磨技术，走技术极客路线，成为某个技术领域的专家。

如果你不想走技术专家路线也没关系。由于过去技术的发展已经积累了和城市“水电煤”类似的基建基础，技术也能更好地解决真实世界中的问题。所以，无论是研发、测试，还是运维，都诞生了非常多和产品、业务贴合非常紧密的业务研发、业务测试以及面向业务的SRE岗位。这些都可以考虑。

这里我们再说远一点，说说能力上的要求。这些岗位，相比技术的酷炫，代码的优雅，未来更侧重的是解决方案的实用性。除了技术攻坚能力，也还有越来越多综合能力的要求。

在技术人的能力发展要求上，我推荐往 T型人才 发展，既有一技之长（｜），又不断去突破舒适区，历练自己的综合能力（一）。

虽然是老生常谈，但我们一定要记住， 技术人的职业发展，技术只是打底，只是我们的“竖线”，是第一步，当横线越来越长，发展之路才会越走越宽。

我的一个朋友，之前在大厂做测试，虽然在外人看来，他发展得不错，但自己内心还是有焦虑。当时他说，“我怀疑自己除了测试，啥也干不了”。但他直面了这种焦虑，先是在公司内转岗，当时发现还是没有解决自己的问题。后来正好有领导创业，他就跟着去了，“当时想法就是要去做自己没做过的事”。虽然创业最后没有成功，但他打开了一个更大的世界。

为了更好地锻炼自己，他还尝试给创业公司做顾问。这几年做的事情，有的成功，有的失败，但对他来说，自己的综合能力比在大厂时提升了几十倍。大家都在讨论内卷，讨论35+危机，他笑着说，“我快45了，依然活得好好的，还在找自己的下一个赛道”。

小结时刻

这一节我们讨论了研发、测试、运维这几个岗位的常见发展路线以及可能需要的能力，你是不是对于自己的发展方向多了一些信心呢？

最后咱们聊聊别的，其实，无论我们当前的岗位是研发、测试还是运维， 想要更好地发展，除了了解路径和能力要求之外，还要回到一个本源问题：理解自己岗位对于公司的价值。

比如业务研发岗，需要理解当下业务发展的阶段，是需要大力冲GMV，还是要降本增效。那围绕这些目标，公司对研发岗位的期待有哪些呢？也许你可以通过提升业务链路的转化率，帮助GMV提升，或者将部分线下工作通过技术手段线上化，缩减开支，从而达到降本增效的目的。说白了，就是利用技术帮助业务达成目标。

举个测试岗的例子，看起来可能没有直接给公司创造营收，但在公司中是守门员的角色。基本的职责是把产品线测好，让所有的项目快速发布，线上质量还特别棒，这是一个测试岗位的要求。把岗位要求做到极致，就是给公司创造了极高的价值。

当你真正理解企业对于岗位的要求，就一定能帮助你在日常工作中不偏离，做正确的事，再加上日常我们在“事上练”，不断修炼正确做事的能力。做正确的事、正确地做事，两手都硬，你的职业发展之路一定会走得很扎实。内心笃定，眼里有光，相信我，职场上最靓的仔就是你！

聊聊发展

你当下是什么岗位？对于自己的发展路径是怎么规划的？看完今天这节课，你有哪些收获和思考？欢迎留言讨论。

如果觉得有所收获，也可以把课程分享给更多的朋友，一起学习程序员职业规划手册，心里不慌，脚下不乱，做好每一天的成长。