SaaS软件工程师成长路径

雨点打透心脏的1/2处 2024-03-17 20:42 37阅读 0赞

## 1. 背景 ##

SaaS软件工程师的成长需要循序渐进，和SaaS业务一样有耐心。SaaS工程师需要在“业务”、“技术”、“管理”三个维度做好知识储备、技能沉淀。本文基于“能力-知识-技能”模型，给出SaaS软件工程师成长路径、学习建议及要求。

[回到顶部][Link 1]

## 2. A-K-S模型 ##

“Ability（能力）”更多依赖个人品质，通过刻意练习可以逐步提升部分能力。“Knowledge（知识）”通常是理论的、确定的信息，通过学习可以不断积累，是最易获取的。“Skill（技能）”偏实操层面，往往和熟练程度成正相关，所谓“熟能生巧”，技能需要不断通过刻意练习来强化，相比“知识”更难获取，美团常提的“苦练基本功”，更多做功在这个维度；对应的，“技能”通常和特定知识领域不强耦合，具备更强的可迁移性。

关于如何提升 “Ability（能力）”，市面上有很多方法论，比如：很多公众号讲的如何提升底层思维，实际上提升的也是 “Ability（能力）”维度。“Ability（能力）”的提升需要个体保持开放的心态、提高对自己的要求，在不断地经验总结中，潜移默化去提升，这部分不在本文的讨论范围。

本文着重说明“Knowledge（知识）”、“Skill（技能）”，原因有三：首先，这两个维度存在领域差异性，SaaS工程师需要的“知识”、“技能”和后台开发工程师存在较大差异；再者，这两个维度和软件工程师的实际工作关联度高，是实际工作中实实在在用到的东西，参考价值更大；最后，这两个维度的内容可以通过学习或练习获得的，是个人成长的发力点所在。

Knowledge、Skill、Ability的对比如下表所示：

<table> 
 <tbody> 
 <tr> 
 <th> 维度 </th> 
 <th> Knowledge（知识） </th> 
 <th> Skill（技能） </th> 
 <th> Ability（能力） </th> 
 </tr> 
 <tr> 
 <td> 概念 </td> 
 <td> 理论、信息 </td> 
 <td> 实操、熟练程度 </td> 
 <td> 品质 </td> 
 </tr> 
 <tr> 
 <td> 获取途径 </td> 
 <td> 学习、经验总结 </td> 
 <td> 练习、经验总结 </td> 
 <td> 内生、学习 </td> 
 </tr> 
 <tr> 
 <td> 举例 </td> 
 <td> 从网络/书籍/教练处获取信息，汇总信息后总结得到骑自行车的要点：骑自行车需要保持平衡，腰和双肩不能需要随着自行车的摇摆实时调整，双手紧握手把，双眼平视前方... ... </td> 
 <td> 会骑自行车。 经过多次练习、过程中不断总结习得该技能 </td> 
 <td> 自驱力：想去学会骑自行车 洞察力：观察别人/视频教学中怎么骑自行车 坚韧：在多次摔倒后还能坚持不懈 </td> 
 </tr> 
 </tbody> 
</table>

来源于：Difference Between Knowledge, Skill and Ability

[回到顶部][Link 1]

## 3. 能力全景图 ##

回顾SaaS软件工程师日常工作用到的“知识”和“技能”，我们可以纵向归类为“业务”、“技术”、“管理”三个维度。“业务”、“技术”这两个维度通常认知比较一致，这里说下“管理”这个维度。

并非只有管理团队才叫“管理”，实际上我们每个人在日常工作也涉及很多管理内容，区别在于：不同角色，管理内容的侧重点、范围、复杂度存在差异。作为个人贡献者，我们需要做好时间管理，确保高效、按期、保质交付任务；作为项目成员，需要和其他成员协作，此时除了管理好自己，还需要和他人沟通、协作，这实际也是管理的一部分；作为项目负责人，需要做好项目管理，对项目最终结果负责，需要做好项目计划、任务安排、任务检核、风险管理、质量管理、总结复盘等；作为领域负责人，需要参与到需求计划、资源调配、方案把控、质量把控等管理内容。前面所述角色更多聚焦在“事”的管理，在“人”方面的管理通常不会特别明显，相对来说，TL会有更多“人”相关的管理工作，比如：目标管理、绩效管理、人才培养等等。

对于各个维度的“知识”和“技能”具体包含哪些内容，会在后面成长路径中详述

![a242059fbedebbe106af39b386e44f10.png][]

图1.SaaS软件工程师能力全景图

[回到顶部][Link 1]

## 4. 成长路径及建议 ##

为便于更清晰讲述成长路径，按照初级、中级、高级三个档位进行分层。某一项知识或者技能可能在三个档位都会存在，但在不同档位下，涉及的范围、复杂度存在差异。

鉴于“技术”维度是软件工程师的核心，且“技术”维度成长路径个体差异更小，更具有普适性，故下面主要以介绍“技术”维度的成长路径为主，“业务”和“管理”维度为辅。

### 初级阶段 ###

初级阶段负责的任务往往是点状的，通常负责中小型项目，负责的业务范围通常在模块级别，这个阶段的要点在于快速构建自己技术知识体系及项目管理知识体系，打牢技术和项目管理的基本盘。这个阶段的提升更多依赖于个体自身的驱动，受具体工作任务的影响较小，因此，初级阶段的知识积累越快越好，周期控制在2到3年时间为佳。

成长要点：快速积累技术基础知识、通识类基础知识

#### “知识”维度 ####

1）成长目标：精通模块内业务知识，熟悉领域内业务知识；掌握JAVA、SPRING、MySql、设计模式、ORM等技术基础知识；掌握时间管理、项目管理、沟通、结构化表达等通识类基础知识。

2）具体要求及建议：

<table> 
 <tbody> 
 <tr> 
 <th> 维度 </th> 
 <th> 项 </th> 
 <th> 具体要求 </th> 
 </tr> 
 <tr> 
 <td> 技术 </td> 
 <td> 计算机基础知识 </td> 
 <td> 掌握操作系统、数据结构、网络基础知识、数据库原理等计算机基础知识，重点关注日常工作中用到的核心知识点，知道大致原理。 举例：网络基础知识，需要知道cookie和session的差异，这在后面进阶的SSO、跨域访问等知识学习中会用到。 </td> 
 </tr> 
 <tr> 
 <td> JAVA语言 </td> 
 <td> 掌握OOP语言特性、Stream、集合、j.c.u并发编程、Object常用方法。 eg：需要知道j.c.u包中的常用类，需要知道线程池的工作原理，这为后面进阶的异步化/并行化、线上排障提供理论输入。 </td> 
 </tr> 
 <tr> 
 <td> MySql </td> 
 <td> 掌握MySql的InnorDB引擎、索引、事务（mvcc）。 eg.知道索引的最左匹配原则对后续创建索引及性能优化有帮助。 </td> 
 </tr> 
 <tr> 
 <td> Spring </td> 
 <td> 掌握Spring出现的背景、解决的问题、核心设计思想（IOC、AOP）；掌握Spring生态各个组件的职责、关系、适用场景；掌握Spring Core核心技术；掌握SpringMVC常用组件的用途、限制条件。 eg：业务应用代码通常会使用Spring的切面解决跨模块横向的通用能力建设，如权限校验等，需要知道Spring切面实现的原理，知道其作用在哪个阶段，为后面的工程应用提供理论储备。 </td> 
 </tr> 
 <tr> 
 <td> ORM </td> 
 <td> 掌握JDBC理论知识、关键组件，知道数据库连接池设计思想，知道JDBC原生数据库连接池关键参数及配置要点；掌握mybatis出现的背景、解决的问题、核心设计；对比JDBC、mybatis、其他ORM框架(如：Hibernate)优劣势 eg：ORM框架本质上是在JDBC之上搭建数据模型和数据库表结构的映射关系，降低程序员的编码成本，其底层依然是JDBC，对于数据库连接池的管理和调优需要知道JDBC的相关原理。 </td> 
 </tr> 
 <tr> 
 <td> 平台工具 </td> 
 <td> 公司内外常用的软件开发相关的平台/工具，比如：IDEA、GIT、lion、octo、crane、avatar、squrrel等 eg：掌握这些平台/工具的作用、常见使用方法，确保开发工作能正常开展 </td> 
 </tr> 
 <tr> 
 <td> UML </td> 
 <td> 掌握UML语言特征，知道元素、元素关系的定义； 知道常见的关系及其图示化表达（如：集成、组合、聚合）。 </td> 
 </tr> 
 <tr> 
 <td> 设计模式 </td> 
 <td> 掌握设计模式的6大原则，掌握常用的设计模式：单例模式、工厂方法模式、模板方法模式、代理模式、适配器模式、观察者模式、责任链模式、状态机模式。 eg：spring、mybatis、应用服务框架通常会使用模板方法模式约束业务代码，消息中间件的发布订阅模式实际就是观察者模式的体现。 </td> 
 </tr> 
 <tr> 
 <td> 管理 </td> 
 <td> 时间管理方法 </td> 
 <td> 掌握常见的个人适用的时间管理方案，PDCA理论 </td> 
 </tr> 
 <tr> 
 <td> 项目管理方法 </td> 
 <td> 了解项目管理的铁三角理论；掌握项目管理各个阶段的工作内容和要点，包括：计划、推动、检核、执行、复盘；能够较好识别干系人；掌握常见的进度管理方法/工具，如：甘特图、站会、进度文档等。 </td> 
 </tr> 
 <tr> 
 <td> 批判性思维 </td> 
 <td> 掌握批判性思维的要点，应用场景 </td> 
 </tr> 
 <tr> 
 <td> 结构化表达 </td> 
 <td> 掌握常见的结构化表达理论 </td> 
 </tr> 
 <tr> 
 <td> 业务 </td> 
 <td></td> 
 <td> 了解业务线全局视图，知道业务线由哪些业务模块组成；熟悉所负责业务领域的业务知识；熟悉所负责业务模块关联的上下游模块的业务知识。 </td> 
 </tr> 
 </tbody> 
</table>

#### “技能”维度 ####

1）成长目标：快速提升编码、SQL、接口设计、建模等基本功，熟悉常见的中间件使用、性能优化及故障处置思路和技巧；能独立负责中型需求，沉淀自己的项目管理技巧；掌握中小型项目的需求分析、需求评审技巧。

2）具体要求及建议：

<table> 
 <tbody> 
 <tr> 
 <th> 维度 </th> 
 <th> 项 </th> 
 <th> 具体要求 </th> 
 </tr> 
 <tr> 
 <td> 技术 </td> 
 <td> 编码 </td> 
 <td> 能熟练使用编程语言完成业务代码开发； 写出的代码命名达意、结构清晰、方法定义合理，具备较好的可读性、可维护性； 掌握常见的重构技巧。 </td> 
 </tr> 
 <tr> 
 <td> SQL </td> 
 <td> 会写常见的DML、DDL脚本； 会根据实际业务场景，创建索引。 </td> 
 </tr> 
 <tr> 
 <td> 接口设计 </td> 
 <td> 能结合团队接口设计规范，在实际业务场景下，设计合理的接口契约： 接口契约命名达意、职责清晰、符合规范要求； 接口设计能考虑到幂等、安全性、参数校验、性能等非功能性要素。 </td> 
 </tr> 
 <tr> 
 <td> 建模 </td> 
 <td> 会使用ER图表达数据模型； 会使用时序图或流程图表达关键业务流程/逻辑； 会使用类图表达业务模型。 </td> 
 </tr> 
 <tr> 
 <td> 工程应用 </td> 
 <td> 会在跨模块范围使用常见的中间件解决实际业务问题，如：mq、RPC、redis、ES； 会借助网络知识、公司内知识库解决遇到的常见工程问题，如：加/解密、幂等、本地事务控制。 </td> 
 </tr> 
 <tr> 
 <td> 性能优化 </td> 
 <td> 会简单的SQL调优，会优化代码结构提升服务性能 </td> 
 </tr> 
 <tr> 
 <td> 故障处置 </td> 
 <td> 会看监控和告警，及时响应告警，能完成稳定性巡检； 会通过服务器日志、trace、业务代码排查常见的线上业务问题； 作为值班人能够解答常见的客户咨询业务问题。 </td> 
 </tr> 
 <tr> 
 <td> 管理 </td> 
 <td> 计划 </td> 
 <td> 中小型项目范围：识别干系人；通过甘特图、日历等工具完成排期；完成项目里程碑的对齐和确认 </td> 
 </tr> 
 <tr> 
 <td> 决策 </td> 
 <td> 中小型项目范围： 能自主完成模块内的技术、项目管理相关决策； 对于跨模块/跨领域的决策，能够基于分析梳理出可选的方案，作为更高级别决策的输入； 及时同步决策结论到干系人，确保信息传递的有效性。 </td> 
 </tr> 
 <tr> 
 <td> 风险 </td> 
 <td> 能识别各类风险，找准并推动干系人解决； 对于无法处置的风险，能够及时上报，并寻求组织帮助。 </td> 
 </tr> 
 <tr> 
 <td> 检核 </td> 
 <td> 及时跟进会议纪要TODO、评审TODO； 及时跟进项目成员进度，识别风险。 </td> 
 </tr> 
 <tr> 
 <td> 协调 </td> 
 <td> 中小型项目范围： 能主持10人以下的会议，能主导会议流程，尝试控制住会议节奏，保持聚焦、高效； 能主导完成跨职能、跨组织的分工、协同； 在出现变更（需求、资源、时间）时，能够及时找到干系人，协调解决方案。 </td> 
 </tr> 
 <tr> 
 <td> 沟通 </td> 
 <td> 掌握各类渠道的沟通技巧，如：即时通讯工具、会议、线下面对面； 掌握不同场景下的沟通技巧。 </td> 
 </tr> 
 <tr> 
 <td> 总结 </td> 
 <td> 中小型项目范围： 能回顾项目过程，识别做得好的、做得不好的，形成自己的经验。 </td> 
 </tr> 
 <tr> 
 <td> 业务 </td> 
 <td> 需求分析 </td> 
 <td> 中小型项目范围： 能独立完成负责需求的需求分析，识别需求要点，找出需求PRD存在的问题，包括但不限于：产品方案合理性、业务逻辑闭环、功能完整度、用户体验、历史客户兼容考虑、对系统的冲击； 能在需求评审前，主动和产品经理沟通对齐大的产品方案、关键问题点，减少需求评审会议上的讨论时间。 </td> 
 </tr> 
 <tr> 
 <td> 需求评审 </td> 
 <td> 中小型项目范围： 能够合理、充分表达自己的观点，提出自己的问题，并通过沟通获得有效的解决； 能够站在技术视角，基于成本、扩展性、性能、可用性等要素，给出问题反馈，尽可能给予产品更合理的建议； 能协助PM记录并跟进需求评审会议纪要。 </td> 
 </tr> 
 <tr> 
 <td> 咨询解答 </td> 
 <td> 模块/领域范围内： 能够解答各类业务问题，对象包括但不限于：QA、产品经理、客户、其他研发。 </td> 
 </tr> 
 </tbody> 
</table>

### 中级阶段 ###

中级阶段通常负责中大型项目，负责的业务范围通常为跨模块模块、领域级别，这个阶段的要点在于：聚焦业务的同时，扩大业务视野；夯实系统设计相关“知识”，熟悉常见的架构设计“知识”；循序渐进提升技术、管理方面的“技能”。这个阶段的提升，个人的自驱和组织的支撑同等重要，一方面，需要有较多合适的业务项目来训练个体的技能，另一方面，也需要个体提高对自己的要求，追求卓越，做好事情的同时，及时复盘总结，沉淀自己的经验。“技能”维度的提升不是一触而就的，这个阶段需要保持耐心，抓住机会，循序渐进地提升。

成长要点：业务聚焦，夯实系统设计相关“知识”，熟悉常见的架构设计“知识”；循序渐进提升系统设计、管理方面的“技能”

#### “知识”维度 ####

1）成长目标：精通所负责领域的业务知识；掌握DDD、OOD等业务建模基础知识，熟悉JVM及常用中间件的原理；掌握人际管理、系统化思维等通识类基础知识。

2）具体要求及建议：

<table> 
 <tbody> 
 <tr> 
 <th> 维度 </th> 
 <th> 项 </th> 
 <th> 具体要求 </th> 
 </tr> 
 <tr> 
 <td> 技术 </td> 
 <td> OOD </td> 
 <td> 了解面向对象分析和设计的理论知识； 熟悉不同领域通用的建模模式。 </td> 
 </tr> 
 <tr> 
 <td> DDD </td> 
 <td> 了解DDD出现的背景、解决的问题； 熟悉DDD的战略、战术相关理论知识。 </td> 
 </tr> 
 <tr> 
 <td> JVM </td> 
 <td> 熟悉Java虚拟机内存模型，熟悉常见的垃圾回收算法； 掌握常见的JVM监控方法，了解常见的JVM调优方法； 熟悉CMS、G1垃圾回收器的原理细节、常见参数。 </td> 
 </tr> 
 <tr> 
 <td> 中间件 </td> 
 <td> 掌握常见的中间件核心原理和技术关键点，包括但不限于：mq、缓存、ES、RPC、分布式job、配置中心。 </td> 
 </tr> 
 <tr> 
 <td> WEB架构知识 </td> 
 <td> 了解常见的WEB架构知识，包括但不限于：RESTful、网关、微服务架构设计、SSO； 了解“三高”问题及解决思路，常见套路：集群部署、负载均衡、缓存、异步化、分库分表、降级、容错等； 了解常见的加解密算法，了解常见的安全问题及架构解决思路，包括传输、存储等环节。 </td> 
 </tr> 
 <tr> 
 <td> 企业架构知识 </td> 
 <td> 了解SaaS相关系统架构的要点，包括但不限于：多租户、流程引擎、规则引擎、个性化解决方案； </td> 
 </tr> 
 <tr> 
 <td> 通用领域知识 </td> 
 <td> 了解负责模块/领域相似度高、关联性高的通用领域知识 </td> 
 </tr> 
 <tr> 
 <td> 管理 </td> 
 <td> 人际管理 </td> 
 <td></td> 
 </tr> 
 <tr> 
 <td> 目标管理 </td> 
 <td></td> 
 </tr> 
 <tr> 
 <td> ... ... </td> 
 <td></td> 
 </tr> 
 <tr> 
 <td> 业务 </td> 
 <td></td> 
 <td> 了解产品线全局业务知识；熟悉所负责业务线的业务知识；精通所负责领域的业务知识，熟悉所负责领域关联的上下游领域的业务知识。 </td> 
 </tr> 
 </tbody> 
</table>

#### “技能”维度 ####

1）成长目标：快速业务建模、技术选型、工程应用等系统设计相关基本功，熟悉常见的架构思路和技巧；能独立主R中大型需求，强化自己的项目管理技巧；掌握中大型项目的需求分析、需求评审技巧，参与需求调研。

2）具体要求及建议：

<table> 
 <tbody> 
 <tr> 
 <th> 维度 </th> 
 <th> 项 </th> 
 <th> 具体要求 </th> 
 </tr> 
 <tr> 
 <td> 技术 </td> 
 <td> 工程应用 </td> 
 <td> 能合理组合使用多种中间件解决一类问题，这类问题通常是全局共性的、偏架构层面的问题。如：能合理使用ES + DTS解决全局订单检索问题 </td> 
 </tr> 
 <tr> 
 <td> 技术调研 </td> 
 <td> 中大型项目范围： 能找准当前问题对标的最佳目标； 能找准调研的要点、方法； 能识别调研对象的优势、劣势、可借鉴点，并能据此形成个人观点； 能体系化地输出调研材料、结论，并将调研结论很好地应用在项目中。 </td> 
 </tr> 
 <tr> 
 <td> 方案分析 </td> 
 <td> 中大型项目范围： 能够找到方案分析的维度，针对不同维度进行对比分析； 能够尽可能量化各个维度对比的优劣、权重； 能够以表格或其他结构化的表达方式呈现分析的思路。 </td> 
 </tr> 
 <tr> 
 <td> 方案决策 </td> 
 <td> 中大型项目范围： 能够基于现状分析、方案分析、未来扩展等方面，综合考虑决策方案选型； 能够平衡好短期成本和长期收益的关系，做好方案选型的取舍； 能够有逻辑、有条理地陈述方案决策的结论和思路。 </td> 
 </tr> 
 <tr> 
 <td> 服务框架设计 </td> 
 <td> 领域服务范围： 能够基于对业务特征的认知、系统现状、人员情况，运用设计模式等沉淀合理的服务框架，提升代码的可维护性，降低工作量。 </td> 
 </tr> 
 <tr> 
 <td> 系统架构 </td> 
 <td> 领域服务范围： 能够做好领域内系统的长期演进，确保领域边界的稳定性、领域内服务的内聚，关注领域上下游。 </td> 
 </tr> 
 <tr> 
 <td> 管理 </td> 
 <td> 计划 </td> 
 <td> 中大型项目范围： 初级阶段“计划”相关要求； 有预见性地做好可能的风险预见，并做好风险预案，比如：技术B方案、人力buffer、对外deadline合理承诺等。 </td> 
 </tr> 
 <tr> 
 <td> 协调 </td> 
 <td> 中大型项目范围： 初级阶段“协调”相关要求； 能主持超过10人的会议，能控制住会议节奏，保持聚焦、高效； 能主导完成跨团队的分工、协同、推进，能找准关键干系人，并使用多种方式推动项目； </td> 
 </tr> 
 <tr> 
 <td> 决策 </td> 
 <td> 中大型项目范围： 能够自主完成领域内的技术、项目管理相关决策； 对于全局影响、架构层面的决策，能够基于分析梳理出可选的方案，作为更高级别决策的输入； </td> 
 </tr> 
 <tr> 
 <td> 领导力 </td> 
 <td> 具备一定的领导力，能够带领其他同学一起交付项目； 能够指导新同学完成工作，能够在评审类会议上发表自己的观点，能够在团队会议上分享、交流，通过各种渠道提升自己的影响力。 </td> 
 </tr> 
 <tr> 
 <td> 业务 </td> 
 <td> 方案决策 </td> 
 <td> 领域范围内： 能够参与到产品方案的讨论和分析中，能够从技术视角，基于成本、可持续演进等维度，给予合理的产品方案建议，帮助取得更合理的方案决策。 </td> 
 </tr> 
 <tr> 
 <td> 需求调研 </td> 
 <td> 能跟随产品经理完成一线商家调研，针对领域内相关问题，能够现场给出较合理解释和方案。 </td> 
 </tr> 
 </tbody> 
</table>

### 高级阶段 ###

思考不够充分，暂略，后续再补充。

[Link 1]: https://www.cnblogs.com/daoqidelv/p/17552443.html#_labelTop
[a242059fbedebbe106af39b386e44f10.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/9ea794f7f3a5433d8f0d96a673dbb771.png