0 你的困惑，我知道！
- 我现在职业发展到哪步了？
- 再往前走，我还得往哪努力？
- 如想转岗，有啥困难？
- 技术飞速发展，经常岗位消失、岗位融合、轮岗调岗，咋办？
慌张来源无法及时认清自己位置！
本文跳进不同技术角色，看职业发展路径和能力要求差异。让你：
- 对未来有更清晰认知
- 减少迷茫
- 在别人的路径中找到适合自己的路
1 研发规划
研发细分前端、客户端、后端、算法等。
1.1 趋势
都是：
- 向上靠近产品、业务的业务研发
- 向下沉，做专业技术攻坚的底层技术研发
1.2 要求
TODO。
如客户端研发：
- 底层技术研发，负责基础架构设计，解决性能和稳定性问题及客户端的容器、配套工具链的设计研发等。需研发对相应底层技术掌握炉火纯青，强的专业技术攻坚能力。还要具备良好服务意识，因为虽不直接面向外部用户，但面对用户是工程师。还要有内部产品设计、推广及最终落地的产品闭环能力
- 而业务研发就不单工程师。除了编码、问题分析定位等研发基础能力，更考验把业务或商业问题转为技术问题，并能最终解决掉的技术应用能力。和产品、业务等职能的跨角色沟通协作能力
两种分工好比练武：
- 有人对剑法感兴趣，每天苦练剑法，把剑法练到天下第一
- 有人会点剑法，也会短刀、大刀，还会点拳法，每项都不是精通，但知道面对敌人，在啥场景，咋组合运用本领对敌
1.3 发展路线
底层技术研发发展三条路：
- 剑法”练够好，成为领域专家。如玉伯老师一直致力于设计语言 Ant Design、数据可视化 AntV 等的研发，在大前端圈享有盛名
- 只要这个世界上还有场景需要你的独门绝技，你就有生存空间，甚至当你有足够技术壁垒，还可技术创业，如很多 RPA 创业公司
- 一旦成为某领域专家，也可将技术传授给更多人，助人成长：知识付费
底层技术研发的发展，就像手有厉害的剑，满世界找场景需要用这把剑，业务研发，就是手无厉害的剑，但背一包武器，去找世界还有啥场景有未满足的需求、没解决好的问题，再用这些武器解决。
所以，业务研发常见发展路径：
- 成为业务方向的专家。聚焦一个业务，解决问题越多，对这业务面临问题和解决思路越熟悉，逐渐成为业务方向专家。有人几份工作都在金融，也对互联网金融感兴趣，致力于成为互联网金融领域资深架构师。这是技术与业务领域深度结合。不但技术架构能力要够好，还要对金融行业专业知识了解
- 更综合方向发展。业务研发本身对一个人的业务、产品、技术能力有综合要求，只是最开始更多是技术手段。不断解决真实世界中的问题，随发展，逐渐组合运用更多能力。早早跳出技术人标签，做业务、做销售、做投资或创业，走出更广阔发展路径
2 测试规划
2.1 业务测试 V.S 测开
TODO。
业务测试
服务业务系统的质量保障工作。除了项目测试，还要快速判断业务质量，然后基于现状灵活制定方案、解决问题。
因此，一个优秀业务测试：
- 测试基础。如测试 Case、测试场景构建、测试方案落地
- 专项测试。利用开源工具或现有工具，完成性能测试、稳定性测试、竞品评测等业务专项质量保障
- 项目管理。测试属发布前最后一环，为保证项目顺利交付，测试天然被赋予项目管理职责
- 测试架构。业务质量的识别能力，尽可能量化的质量分析能力，根据质量分析结果设计质量方案的能力，推进质量方案落地、复盘以及迭代优化的能力
如负责交易系统，业务测试要：
- 与研发一起梳理系统关键链路，结合历史质量情况分析出当前系统的质量隐患
- 结合业务发展阶段及当前资源，给出明确质量提升计划。计划可能涉及稳定性建设咋加强，咋设计核心链路监控，啥链路需自动化测试及项目流程哪些环节需改进
测试开发
测开更多负责通用测试工具或测试框架开发。但所有行动最终指向业务系统质量和效率提升，不局限工具开发，低头造轮。还需深刻理解团队需啥工具，跟进工具落地及工具使用效果。目前，测开越来越关注研发效能，从全局思考提升交付效能，提升研发效率。
如张三负责外卖检索服务系统，发现产品、研发每天处理商户反馈问题。如商户经常问，为啥我家店铺没展示在相应位置？诊断过程可流程化。于是小 A 做检索工具，输入商户 ID，搜索地点，就可显示整个检索召回的中间步骤和结果，还根据研发和产品使用反馈，不断将中间结果可视化，优化工具使用，大大解放研发和产品人力。
测开能力要求与研发类似，都要有编码能力。但测试更关注技术广度。交付产品一般公司内部，不像研发面对高并发流量，对测开，快速完成工具开发是关键。
随测试人才发展，很多大厂测试团队对测试同学编码能力也有很多要求。很多业务测试日常也做测开，继续降本增效趋势。
2.2发展路线
测试整体多面手，很多人调侃，测试比开发懂产品，比产品懂实现。测试日常经常负责项目管理、质量运营，长远发展路径很多：
- 专注于提升研发效能，做技术专家。比如业界知名的软件质量和研发工程效能专家茹炳晟
- 业务领域测试专家。即在一个行业深耕，技术上走专项路线，比如《云原生研发测试》的作者孙高飞一直深耕云原生领域，成为了这个领域的测试专家
- 转型。因为测试岗的多面性，天然具备转型的可能性。比如我看到不少测试转研发，转产品，甚至转 PMO 项目管理岗
2.3 “研发:测试” 比持续下降，测试岗何去何从？
很多大厂降低“测试: 研发”比，08年很多团队“测试:研发”比1:3 到 1:5 间，这些年，1:6成基础要求，有的成熟部门做到1:10，甚至“去 QA（去掉测试岗）”。
未来测试岗会消失吗？
去 QA
本质在解决效率冗余问题。程序在不同角色流转，一定会造成效率浪费。一个产品诞生，经历“产品 - 研发 - 测试”，然后测试发现 Bug，再反馈研发。这期间确实存在资源浪费。理想情况，若研发交付高质量产品，QA确实可被裁剪。
因此，去QA前提：研发开发高质量代码。再往前，就是让产品交付高质量PRD。质量要求是恒定的，即使 QA 没了，质量保证从未消失，只是转移到其他角色或方式。只是不用业务测试保障了。
测试逐渐从原业务测试、流动的团队，过渡到一个赋能团队。不再是点对点测试，而是提供质量保证的思路和能力，把质量保障框架的设计能力、方案实现能力及测试落地能力，以培训、流程梳理或工具方式赋能团队。
3 运维规划
过去十几年技术岗中变化最大的一个岗位。系统都上云了，运维还有发展？
3.1 发展趋势
运维国内发展阶段：
① 打杂
21 世纪初，国内运维岗随第一批互联网公司出现诞生。
那时百度运维段子：招运维是“靠称称的”。体重得够。那时运维要扛机器，跑机房。最开始运维诞生是因为有很多杂活。招研发太贵，那就招运维岗。
学历、经验要求会比研发低。
② 规模化带来的精细化运维
2008-2010 年之间，各大互联网公司快速扩招，研发人数迅速增加。人越多，犯错率越高，业务体量扩大，犯错成本也增加。
因此，运维职责是减少研发失误，降低线上系统故障的概率。至此，运维岗有了精细的分工，如网络机房、基础组件运维、业务运维等。
③ NoOps
系统工具完善及公有云，2015 年左右，业内开始推 NoOps。很多之前的运维工作被系统和工具取代，运维岗大规模缩减，很多运维同学转岗或离职。
④ 面向业务的 SRE
上云后，系统问题没彻底解决，故障依然存在，研发系统模块互相依赖，查 Bug 成本很高。于是，最近这几年出现了面向业务的 SRE，尽可能降低研发开发成本，让研发将更多精力聚焦业务。头部大厂都有SRE部门。随着 AI 技术的发展，在运维领域可能也会出现更多 AIOps。
当前运维岗的工作价值与业务规模强相关，规模越大，越能更好地发挥杠杆效应，因此好运维离不开大厂。
随公有云普及，运维朝与业务结合方向发展，能力要求逐渐综合。如面向业务的 SRE 岗，既要有运维经验，懂网络、机房、常见中间件，又要了解业务架构。
而且，运维的能力模型，除了技术、经验之外，通用的软素质也越来越重要。比如要有大心脏，遇到故障不能慌，还要有很好的推动协调能力，最好还要有对问题的洞察力，也就是思考、分析以及解决问题的能力。
3.2 发展路径
SRE 是一条路径，很多的运维小伙伴都在大厂做 SRE，还有做业务架构。
做几年运维，因为努力，也做非常多技术积累，高并发架构设计、多机房主备架构等都很清晰，还多次帮助业务搭建更稳定的架构。有这些积累，拿到央企架构师 Offer，帮助央企下属子公司系统上云。成功转型业务架构师，后来也做起了技术管理。环境不好，央企也有变化，他用复合经验和朋友创业做技术咨询。
4 岗位融合与能力发展
转岗很多：从测试/运维转研发更多。因为技术具备相通性，且研发处上游，整体岗位需求量大。如大厂现在的“测试: 研发”比一般在 1:6 左右，成熟业务可以做到 1:10，而运维（含 SRE）: 研发在 1:100 左右。
未来这几个岗位会融合吗？毕竟细化分工是公司到规模后才出现，很多小公司无细致划分，随 AI，可能还有新变化。
但技术都可选择在自己擅长的领域不断打磨技术，走技术极客路线，成为某技术领域专家。
由于技术发展积累和城市“水电煤”类似的基建基础，技术也能更好解决真实世界问题。所以，无论研发、测试，还是运维，都诞生了非常多和产品、业务贴合非常紧密的业务研发、业务测试以及面向业务的 SRE 岗位。这些都可以考虑。
能力要求
相比技术的酷炫，代码的优雅，未来更侧重的是解决方案的实用性。除了技术攻坚能力，也还有越来越多综合能力的要求。
在技术人的能力发展要求上，我推荐往 T 型人才发展，既有一技之长（｜），又不断去突破舒适区，历练自己的综合能力（一）。
TODO。
技术人职业发展，技术只是打底，只是我们的“竖线”，是第一步，当横线越来越长，发展之路才会越走越宽。
大厂做测试的朋友，虽然在外人看来不错，但内心焦虑：“怀疑自己除测试，啥也不会”。但他直面焦虑，先在公司转岗，发现还是没有解决问题。后来领导创业，他就跟着去，“当时就想做没做过的事”。虽然创业没成功，但打开更大世界。
为更好锻炼，尝试给创业公司做顾问。综合能力比大厂提升几十倍。一直在找自己下一个赛道”的路上。
5 总结
无论当前研发、测试or运维，想更好发展，除了解路径和能力要求，还要回归本源：理解岗位对公司的价值。如：
- 业务研发，理解当下业务发展阶段，是大力冲 GMV，还是降本增效。围绕这些目标，公司对研发岗位的期待是啥？也许你可通过提升业务链路的转化率，帮助 GMV 提升或将部分线下工作通过技术手段线上化，缩减开支，从而达到降本增效的目的。说白了，就是利用技术帮助业务达成目标
- 测试岗，可能未直接给公司创造营收，但在公司是守门员。基本职责是把产品线测好，让所有项目快速发布，线上质量还棒。把岗位要求做到极致，就是给公司创造了极高价值
真正理解企业对岗位的要求，就能助你日常工作不偏离，做正确事，再日常在“事上练”，不断修炼正确做事能力。做正确的事、正确做事，两手都抓都硬，职业发展才走得扎实。
FAQ
数据科学我会倾向于是业务研发，因为数据是用来驱动业务，最终数据发挥价值也是要回到业务场景中。跟编程能力要求无关哈，业务研发本身对编码能力要求也挺高的。 一对一教练陪跑好几个在大厂做数据科学家的小伙伴，这个岗位如果做得好确实是业务的“大脑”，但要做得这一步不但数据科学相关技术能力很扎实，更重要的事要深刻理解业务场景，能确定好的指标去做业务诊断，帮助业务更好地决策。
Q：前端，但是中间做了很多产品沟通的工作，想向上浮，但是： 1. 具体怎么变成业务领域的专家不是很懂，开发咋往上浮呢？ 2. 业务向的思考与深度不是产品经理、销售更懂，在那搞需求吗？ 对于一线开发来说，具体的思路或者实践应该怎么迈出去呢
A：从分工的角度，业务的思考是产品经理、销售更懂，但技术要更大发挥价值，不能只是埋头接需求。 至于具体如何向上浮，你是做前端的，下边这些问题你可以参考一下： 1.你做的产品整体日活/访问量多少？你负责业务的pv/uv多少？ 2.了解用户进入你的产品，动线是什么？也就是最常用的是哪些功能？他从哪里进，从哪里出？这里挺考验数据埋点的。 3.整个系统的流畅性如何？比如你负责模块的bug率？如果是APP，可能还有crash率？页面的秒开率？这些数据有哪些优化方案？ 4.今年业务对于这个产品的目标是什么？你这边可以提供的价值是什么？
Q：SRE方向上的技术架构的工作，偏向于从前到后都需要关注，但是由于组织架构目前是有点难理解：运维是按照职能来分，但是开发团队是按照业务域来分，这就会导致只要跟运维相关的工作流程，沟通效率以及落地质量很难得到保证。比如要开展一项SRE稳定性的工作，对于服务团队来说只要按照业务域说明对应的技术改动步骤以及影响功能范围即可，但是对于运维团队就比较吃力，因为运维团队比较脱离一线业务，按实际技术来讲他们的深度也难达到，请问老师对于这种情况应该如何处理？
A：这个问题在很多大厂都存在，从流程机制设立来说，稳定性SRE是研发和运维要一起去负责的，很多大厂会要求每个业务单元有研发的稳定性接口人，与运维协同去把稳定性方案落地，这样双角色保障，会减少很多真空区。 除了流程，从运维岗本身的要求来说，确实是一个综合性要求很高的岗位，技术上对于业务细节可能没那么懂，但对于一个系统常见的稳定性梳理思路要非常清晰。比如你可以给研发提要求，梳理核心链路图，从这些核心链路中对于研发的监控、故障预案，提各种细致的要求。还可以结合之前的故障和线上bug，明确哪些是重灾区，服务如何分级等等。这是技术方面，那除了技术方面，运维作为研发的下游，下游想要推动上游，就必须先得主动，还得有一定的流程约束，对研发提一些要求。
