SaaS軟體工程師的成長需要循序漸進,和SaaS業務一樣有耐心。SaaS工程師需要在「業務」、「技術」、「管理」三個維度做好知識儲備、技能沉澱。本文基於「能力-知識-技能」模型,給出SaaS軟體工程師成長路徑、學習建議及要求。
「Ability(能力)」更多依賴個人品質,通過刻意練習可以逐步提升部分能力。「Knowledge(知識)」通常是理論的、確定的資訊,通過學習可以不斷積累,是最易獲取的。「Skill(技能)」偏實操層面,往往和熟練程度成正相關,所謂「熟能生巧」,技能需要不斷通過刻意練習來強化,相比「知識」更難獲取,美團常提的「苦練基本功」,更多做功在這個維度;對應的,「技能」通常和特定知識領域不強耦合,具備更強的可遷移性。
關於如何提升 「Ability(能力)」,市面上有很多方法論,比如:很多公眾號講的如何提升底層思維,實際上提升的也是 「Ability(能力)」維度。「Ability(能力)」的提升需要個體保持開放的心態、提高對自己的要求,在不斷地經驗總結中,潛移默化去提升,這部分不在本文的討論範圍。
本文著重說明「Knowledge(知識)」、「Skill(技能)」,原因有三:首先,這兩個維度存在領域差異性,SaaS工程師需要的「知識」、「技能」和後臺開發工程師存在較大差異;再者,這兩個維度和軟體工程師的實際工作關聯度高,是實際工作中實實在在用到的東西,參考價值更大;最後,這兩個維度的內容可以通過學習或練習獲得的,是個人成長的發力點所在。
Knowledge、Skill、Ability的對比如下表所示:
維度 |
Knowledge(知識) |
Skill(技能) |
Ability(能力) |
---|---|---|---|
概念 |
理論、資訊 |
實操、熟練程度 |
品質 |
獲取途徑 |
學習、經驗總結 |
練習、經驗總結 |
內生、學習 |
舉例 |
從網路/書籍/教練處獲取資訊,彙總資訊後總結得到騎自行車的要點:騎自行車需要保持平衡,腰和雙肩不能需要隨著自行車的搖擺實時調整,雙手緊握手把,雙眼平視前方... ... |
會騎自行車。 經過多次練習、過程中不斷總結習得該技能 |
自驅力:想去學會騎自行車 洞察力:觀察別人/視訊教學中怎麼騎自行車 堅韌:在多次摔倒後還能堅持不懈 |
來源於:Difference Between Knowledge, Skill and Ability
回顧SaaS軟體工程師日常工作用到的「知識」和「技能」,我們可以縱向歸類為「業務」、「技術」、「管理」三個維度。「業務」、「技術」這兩個維度通常認知比較一致,這裡說下「管理」這個維度。
並非只有管理團隊才叫「管理」,實際上我們每個人在日常工作也涉及很多管理內容,區別在於:不同角色,管理內容的側重點、範圍、複雜度存在差異。作為個人貢獻者,我們需要做好時間管理,確保高效、按期、保質交付任務;作為專案成員,需要和其他成員共同作業,此時除了管理好自己,還需要和他人溝通、共同作業,這實際也是管理的一部分;作為專案負責人,需要做好專案管理,對專案最終結果負責,需要做好專案計劃、任務安排、任務檢核、風險管理、質量管理、總結覆盤等;作為領域負責人,需要參與到需求計劃、資源調配、方案把控、質量把控等管理內容。前面所述角色更多聚焦在「事」的管理,在「人」方面的管理通常不會特別明顯,相對來說,TL會有更多「人」相關的管理工作,比如:目標管理、績效管理、人才培養等等。
對於各個維度的「知識」和「技能」具體包含哪些內容,會在後面成長路徑中詳述
圖1.SaaS軟體工程師能力全景圖
為便於更清晰講述成長路徑,按照初級、中級、高階三個檔位進行分層。某一項知識或者技能可能在三個檔位都會存在,但在不同檔位下,涉及的範圍、複雜度存在差異。
鑑於「技術」維度是軟體工程師的核心,且「技術」維度成長路徑個體差異更小,更具有普適性,故下面主要以介紹「技術」維度的成長路徑為主,「業務」和「管理」維度為輔。
初級階段負責的任務往往是點狀的,通常負責中小型專案,負責的業務範圍通常在模組級別,這個階段的要點在於快速構建自己技術知識體系及專案管理知識體系,打牢技術和專案管理的基本盤。這個階段的提升更多依賴於個體自身的驅動,受具體工作任務的影響較小,因此,初級階段的知識積累越快越好,週期控制在2到3年時間為佳。
成長要點:快速積累技術基礎知識、通識類基礎知識
1)成長目標:精通模組內業務知識,熟悉領域內業務知識;掌握JAVA、SPRING、MySql、設計模式、ORM等技術基礎知識;掌握時間管理、專案管理、溝通、結構化表達等通識類基礎知識。
2)具體要求及建議:
維度 |
項 |
具體要求 |
---|---|---|
技術 |
計算機基礎知識 |
掌握作業系統、資料結構、網路基礎知識、資料庫原理等計算機基礎知識,重點關注日常工作中用到的核心知識點,知道大致原理。 舉例:網路基礎知識,需要知道cookie和session的差異,這在後面進階的SSO、跨域存取等知識學習中會用到。 |
JAVA語言 |
掌握OOP語言特性、Stream、集合、j.c.u並行程式設計、Object常用方法。 eg:需要知道j.c.u包中的常用類,需要知道執行緒池的工作原理,這為後面進階的非同步化/並行化、線上排障提供理論輸入。 |
|
MySql |
掌握MySql的InnorDB引擎、索引、事務(mvcc)。 eg.知道索引的最左匹配原則對後續建立索引及效能優化有幫助。 |
|
Spring |
掌握Spring出現的背景、解決的問題、核心設計思想(IOC、AOP);掌握Spring生態各個元件的職責、關係、適用場景;掌握Spring Core核心技術;掌握SpringMVC常用元件的用途、限制條件。 eg:業務應用程式碼通常會使用Spring的切面解決跨模組橫向的通用能力建設,如許可權校驗等,需要知道Spring切面實現的原理,知道其作用在哪個階段,為後面的工程應用提供理論儲備。 |
|
ORM |
掌握JDBC理論知識、關鍵元件,知道資料庫連線池設計思想,知道JDBC原生資料庫連線池關鍵引數及設定要點;掌握mybatis出現的背景、解決的問題、核心設計;對比JDBC、mybatis、其他ORM框架(如:Hibernate)優劣勢 eg:ORM框架本質上是在JDBC之上搭建資料模型和資料庫表結構的對映關係,降低程式設計師的編碼成本,其底層依然是JDBC,對於資料庫連線池的管理和調優需要知道JDBC的相關原理。 |
|
平臺工具 |
公司內外常用的軟體開發相關的平臺/工具,比如:IDEA、GIT、lion、octo、crane、avatar、squrrel等 eg:掌握這些平臺/工具的作用、常見使用方法,確保開發工作能正常開展 |
|
UML |
掌握UML語言特徵,知道元素、元素關係的定義; 知道常見的關係及其圖示化表達(如:整合、組合、聚合)。 |
|
設計模式 |
掌握設計模式的6大原則,掌握常用的設計模式:單例模式、工廠方法模式、模板方法模式、代理模式、介面卡模式、觀察者模式、責任鏈模式、狀態機模式。 eg:spring、mybatis、應用服務架構通常會使用模板方法模式約束業務程式碼,訊息中介軟體的釋出訂閱模式實際就是觀察者模式的體現。 |
|
管理 |
時間管理方法 |
掌握常見的個人適用的時間管理方案,PDCA理論 |
專案管理方法 |
瞭解專案管理的鐵三角理論;掌握專案管理各個階段的工作內容和要點,包括:計劃、推動、檢核、執行、覆盤;能夠較好識別干係人;掌握常見的進度管理方法/工具,如:甘特圖、站會、進度檔案等。 |
|
批判性思維 |
掌握批判性思維的要點,應用場景 |
|
結構化表達 |
掌握常見的結構化表達理論 |
|
業務 |
瞭解業務線全域性檢視,知道業務線由哪些業務模組組成;熟悉所負責業務領域的業務知識;熟悉所負責業務模組關聯的上下游模組的業務知識。 |
1)成長目標:快速提升編碼、SQL、介面設計、建模等基本功,熟悉常見的中介軟體使用、效能優化及故障處置思路和技巧;能獨立負責中型需求,沉澱自己的專案管理技巧;掌握中小型專案的需求分析、需求評審技巧。
2)具體要求及建議:
維度 |
項 |
具體要求 |
---|---|---|
技術 |
編碼 |
能熟練使用程式語言完成業務程式碼開發; 寫出的程式碼命名達意、結構清晰、方法定義合理,具備較好的可讀性、可維護性; 掌握常見的重構技巧。 |
SQL |
會寫常見的DML、DDL指令碼; 會根據實際業務場景,建立索引。 |
|
介面設計 |
能結合團隊介面設計規範,在實際業務場景下,設計合理的介面契約: 介面契約命名達意、職責清晰、符合規範要求; 介面設計能考慮到冪等、安全性、引數校驗、效能等非功能性要素。 |
|
建模 |
會使用ER圖表達資料模型; 會使用時序圖或流程圖表達關鍵業務流程/邏輯; 會使用類圖表達業務模型。 |
|
工程應用 |
會在跨模組範圍使用常見的中介軟體解決實際業務問題,如:mq、RPC、redis、ES; 會藉助網路知識、公司內知識庫解決遇到的常見工程問題,如:加/解密、冪等、本地事務控制。 |
|
效能優化 |
會簡單的SQL調優,會優化程式碼結構提升服務效能 |
|
故障處置 |
會看監控和告警,及時響應告警,能完成穩定性巡檢; 會通過伺服器紀錄檔、trace、業務程式碼排查常見的線上業務問題; 作為值班人能夠解答常見的客戶諮詢業務問題。 |
|
管理 |
計劃 |
中小型專案範圍:識別干係人;通過甘特圖、日曆等工具完成排期;完成專案里程碑的對齊和確認 |
決策 |
中小型專案範圍: 能自主完成模組內的技術、專案管理相關決策; 對於跨模組/跨領域的決策,能夠基於分析梳理出可選的方案,作為更高階別決策的輸入; 及時同步決策結論到干係人,確保資訊傳遞的有效性。 |
|
風險 |
能識別各類風險,找準並推動干係人解決; 對於無法處置的風險,能夠及時上報,並尋求組織幫助。 |
|
檢核 |
及時跟進會議紀要TODO、評審TODO; 及時跟進專案成員進度,識別風險。 |
|
協調 |
中小型專案範圍: 能主持10人以下的會議,能主導會議流程,嘗試控制住會議節奏,保持聚焦、高效; 能主導完成跨職能、跨組織的分工、協同; 在出現變更(需求、資源、時間)時,能夠及時找到干係人,協調解決方案。 |
|
溝通 |
掌握各類渠道的溝通技巧,如:即時通訊工具、會議、線下面對面; 掌握不同場景下的溝通技巧。 |
|
總結 |
中小型專案範圍: 能回顧專案過程,識別做得好的、做得不好的,形成自己的經驗。 |
|
業務 |
需求分析 |
中小型專案範圍: 能獨立完成負責需求的需求分析,識別需求要點,找出需求PRD存在的問題,包括但不限於:產品方案合理性、業務邏輯閉環、功能完整度、使用者體驗、歷史客戶相容考慮、對系統的衝擊; 能在需求評審前,主動和產品經理溝通對齊大的產品方案、關鍵問題點,減少需求評審會議上的討論時間。 |
需求評審 |
中小型專案範圍: 能夠合理、充分表達自己的觀點,提出自己的問題,並通過溝通獲得有效的解決; 能夠站在技術視角,基於成本、擴充套件性、效能、可用性等要素,給出問題反饋,儘可能給予產品更合理的建議; 能協助PM記錄並跟進需求評審會議紀要。 |
|
諮詢解答 |
模組/領域範圍內: 能夠解答各類業務問題,物件包括但不限於:QA、產品經理、客戶、其他研發。 |
中級階段通常負責中大型專案,負責的業務範圍通常為跨模組模組、領域級別,這個階段的要點在於:聚焦業務的同時,擴大業務視野;夯實系統設計相關「知識」,熟悉常見的架構設計「知識」;循序漸進提升技術、管理方面的「技能」。這個階段的提升,個人的自驅和組織的支撐同等重要,一方面,需要有較多合適的業務專案來訓練個體的技能,另一方面,也需要個體提高對自己的要求,追求卓越,做好事情的同時,及時覆盤總結,沉澱自己的經驗。「技能」維度的提升不是一觸而就的,這個階段需要保持耐心,抓住機會,循序漸進地提升。
成長要點:業務聚焦,夯實系統設計相關「知識」,熟悉常見的架構設計「知識」;循序漸進提升系統設計、管理方面的「技能」
1)成長目標:精通所負責領域的業務知識;掌握DDD、OOD等業務建模基礎知識,熟悉JVM及常用中介軟體的原理;掌握人際管理、系統化思維等通識類基礎知識。
2)具體要求及建議:
維度 |
項 |
具體要求 |
---|---|---|
技術 |
OOD |
瞭解物件導向分析和設計的理論知識; 熟悉不同領域通用的建模模式。 |
DDD |
瞭解DDD出現的背景、解決的問題; 熟悉DDD的戰略、戰術相關理論知識。 |
|
JVM |
熟悉Java虛擬機器器記憶體模型,熟悉常見的垃圾回收演演算法; 掌握常見的JVM監控方法,瞭解常見的JVM調優方法; 熟悉CMS、G1垃圾回收器的原理細節、常見引數。 |
|
中介軟體 |
掌握常見的中介軟體核心原理和技術關鍵點,包括但不限於:mq、快取、ES、RPC、分散式job、設定中心。 |
|
WEB架構知識 |
瞭解常見的WEB架構知識,包括但不限於:RESTful、閘道器、微服務架構設計、SSO; 瞭解「三高」問題及解決思路,常見套路:叢集部署、負載均衡、快取、非同步化、分庫分表、降級、容錯等; 瞭解常見的加解密演演算法,瞭解常見的安全問題及架構解決思路,包括傳輸、儲存等環節。 |
|
企業架構知識 |
瞭解SaaS相關係統架構的要點,包括但不限於:多租戶、流程引擎、規則引擎、個性化解決方案; |
|
通用領域知識 |
瞭解負責模組/領域相似度高、關聯性高的通用領域知識 |
|
管理 |
人際管理 |
|
目標管理 |
||
... ... |
||
業務 |
瞭解產品線全域性業務知識;熟悉所負責業務線的業務知識;精通所負責領域的業務知識,熟悉所負責領域關聯的上下游領域的業務知識。 |
1)成長目標:快速業務建模、技術選型、工程應用等系統設計相關基本功,熟悉常見的架構思路和技巧;能獨立主R中大型需求,強化自己的專案管理技巧;掌握中大型專案的需求分析、需求評審技巧,參與需求調研。
2)具體要求及建議:
維度 |
項 |
具體要求 |
---|---|---|
技術 |
工程應用 |
能合理組合使用多種中介軟體解決一類問題,這類問題通常是全域性共性的、偏架構層面的問題。如:能合理使用ES + DTS解決全域性訂單檢索問題 |
技術調研 |
中大型專案範圍: 能找準當前問題對標的最佳目標; 能找準調研的要點、方法; 能識別調研物件的優勢、劣勢、可借鑑點,並能據此形成個人觀點; 能體系化地輸出調研材料、結論,並將調研結論很好地應用在專案中。 |
|
方案分析 |
中大型專案範圍: 能夠找到方案分析的維度,針對不同維度進行對比分析; 能夠儘可能量化各個維度對比的優劣、權重; 能夠以表格或其他結構化的表達方式呈現分析的思路。 |
|
方案決策 |
中大型專案範圍: 能夠基於現狀分析、方案分析、未來擴充套件等方面,綜合考慮決策方案選型; 能夠平衡好短期成本和長期收益的關係,做好方案選型的取捨; 能夠有邏輯、有條理地陳述方案決策的結論和思路。 |
|
服務架構設計 |
領域服務範圍: 能夠基於對業務特徵的認知、系統現狀、人員情況,運用設計模式等沉澱合理的服務架構,提升程式碼的可維護性,降低工作量。 |
|
系統架構 |
領域服務範圍: 能夠做好領域內系統的長期演進,確保領域邊界的穩定性、領域內服務的內聚,關注領域上下游。 |
|
管理 |
計劃 |
中大型專案範圍: 初級階段「計劃」相關要求; 有預見性地做好可能的風險預見,並做好風險預案,比如:技術B方案、人力buffer、對外deadline合理承諾等。 |
協調 |
中大型專案範圍: 初級階段「協調」相關要求; 能主持超過10人的會議,能控制住會議節奏,保持聚焦、高效; 能主導完成跨團隊的分工、協同、推進,能找準關鍵干係人,並使用多種方式推動專案; |
|
決策 |
中大型專案範圍: 能夠自主完成領域內的技術、專案管理相關決策; 對於全域性影響、架構層面的決策,能夠基於分析梳理出可選的方案,作為更高階別決策的輸入; |
|
領導力 |
具備一定的領導力,能夠帶領其他同學一起交付專案; 能夠指導新同學完成工作,能夠在評審類會議上發表自己的觀點,能夠在團隊會議上分享、交流,通過各種渠道提升自己的影響力。 |
|
業務 |
方案決策 |
領域範圍內: 能夠參與到產品方案的討論和分析中,能夠從技術視角,基於成本、可持續演進等維度,給予合理的產品方案建議,幫助取得更合理的方案決策。 |
需求調研 |
能跟隨產品經理完成一線商家調研,針對領域內相關問題,能夠現場給出較合理解釋和方案。 |
思考不夠充分,暫略,後續再補充。