管理者如何持續學習技術?


很多技術背景的工程師,隨著年紀與歷練,會有機會帶團隊,成為 Team Leader / Techincal Leader,甚至轉換身份成為管理者。這些轉換很常是學而優則仕、公司上級的期待、被逼上火線 … 但這都算是被動因素,也就是不是自己願意的。

管理 實際上是另一個高度專業的工作,所需要的技能與技術工作者是截然不同的,像是協調、溝通、管人、管事、領導、激勵 … 等看起來像是打雜的任務。因為需要漸漸地放手最熟悉技能 (技術) 讓團隊去執行,也因此很多初任管理工作會常常出現 患得患失 的狀況。

這一收一放,一段時間之後會發現,自己對技術會越來越陌生,跟團隊成員比較起來會越來越不如,很常會被底下的人質疑自己的技術能力,可是頭上戴著主管的帽子,需要做技術決策、選擇、提出建議 … 等,很多人因此就打退堂鼓放棄了,回到純粹的 Tech Leader 的角色。

接下來,我打算整理一些心得,分享從工程師到技術管理者的心得,先以這個問題開始:

管理者如何持續學習技術?


如何持續學習技術?

對於一個技術背景的管理者,沒有時間寫程式,該如何持續學習,保持手感呢?

掌握趨勢:保持對新技術、新名詞的靈敏度

管理者基於溝通與引導團隊的原則,需要對於新技術要有認識。認識新技術如同認識產品的新需求、新功能一樣,要了解以下:

  • 為什麼有這樣的技術出現?
  • 這技術它要解決什麼問題?
  • 這個技術的本質是什麼?
  • 這個技術的最佳使用情境?
  • 其他類似的技術有什麼?
  • 使用這個技術有什麼前提?
  • 目前組織裡面,使用這技術的效益在哪?
  • 導入新技術要面對哪一些新問題?

了解這些背後的原因,最好個人做一些簡單的 Lab,體驗與感受新技術。

除了了解新技術,另外透過訂閱技術專欄,知道一些新名詞的出現。新名詞通常是新時代的開始,像是 DevOps、Cloud Native、Kubernetes、Service Mesh … 等。這些名詞的出現,往往背後隱含著接下來排山倒海的改變與翻轉,技術管理者必須要有靈敏,感覺接下來可能要面對的變革,要面對的挑戰,然後要面對的就是:

  1. 技術決策:到底要不要用?跟既有的比較起來有那些優勢?
  2. 技術落地:這技術怎樣在團隊以及產品中使用?
  3. 教育訓練:如何讓成員能知道技術的價值?如何讓團隊接受這種技術?有沒有老司機可以支援?

研讀經典

新技術會不斷出現,但是大部分所謂的 新技術 實際上都只是重新包裝的新實踐。包裝什麼?包裝 計算機科學核心知識,也就是資訊工程研究所的必考科目:

深根這些核心知識,然後工程實踐的部分則是:

  • OOP / Design Pattern / SOILD
  • Linux / Unix
  • AWS / GCP
  • Kubernetes / Microservices
  • 軟體工程、軟體開發
  • DevOps / SRE

這些範圍都很大,一些具體的實踐方法就是研讀經典:

  • 持續交付
  • Clean Architecture
  • SRE
  • Code Complete
  • Refectoring
  • Thinking in Java, Effective Java
  • Design Pattern
  • 人月神話
  • Peopleware

研讀經典的目的在於掌握本質,工作上則掌握全貌:

跳出來、看全景;看進去、學本質

底下是我持續、反覆複習的:

整理與組織過去所學

技術管理者通常也會是資深開發者,會具備一定的實務經驗,而且通常會有很多想法。而這些經驗與想法常常會因為專案趕時程,因而被埋藏在深邃的記憶中,沒有被組織、整理下來,也鮮少分享出來。

如果可以定期地把這些想法、心得、遭遇到的問題,透過文字方式寫下來,然後重新組織與思考,這個過程可以重新思考全貌,然後了解自己已經有的、不足的,進而刺激自己把它完整的動力,最後自己會有很大的受益。

相關經驗:Designing Test Architecture and Framework聊聊軟體交付的濫觴 談產出物管理 (Artifacts Management)演講:從理想、到現實的距離,開啟品味軟體測試之路

這時候,會發現 寫作閱讀、以及 組織能力 的重要性,這些能力其實類似於程式的輸入、輸出、以及重構的概念。

相關文章:

定期做自己的 Side Project,保持手感,整理心得文

技術管理者不會實際下去執行任務,怎麼指導團隊?特別用的是新技術時怎麼辦?答案很簡單:

做自己的 Side Project

Side Project 通常是很小的,主要是了解新技術的核心概念、運作原理、應用場景、驗證技術的特性。而這過程不是要做出很完整、或者很大的東西。重點是自己可以掌握這些技術的核心概念,未來跟團隊協作時,可以與團隊流暢的溝通,可以決定技術的選擇方向。做的過程,可以把心得整理成文章,放在 Blog 形成自己的知識體系。

持續深耕自己的技術主軸

前面一段中提到訂閱技術專欄、了解新名詞,但沒有動手了碰過,還是與實際應用有段落差。

所以在這些眾多的主題中,一定有些主題與自己工作,或過去經驗相關。可以利用小小的 PoC、Lab,同時記錄相關的實驗筆記給自己參考,注意幾點:

  • 不用擔心有錯誤,筆記是給自己看的
  • 筆記整理以解決問題、了解原由、設計優先
  • 描寫以生命週期為主,也就是有頭有尾,像是安裝起迄、功能的開始與結束 … 等
  • 每次需要的時候,就順手調整與修改

這樣的方式可以讓自己對於新技術有一些手感,同時可以累積一些未來有參考價值的資訊,一段時間之後,數量多了,重新組織分類他們,把錯誤的刪去,留下好的,形成自己的技術脈絡與資產。

我最近幾年的研究主軸:

與團隊成員發想、討論,引導團隊成員精進

上一段提到做自己的 Side Project 保持手感,但現實往往沒那麼美好,上班時間多時候技術管理者需要花費大量心力在於帶人、溝通、協作、管理 … 等工作,實際上只能利用下班自己找時間做研究,而往往下班要面對的會是家庭問題,時間能放在技術研究之上,實際上會少之又少。

如果是這樣的管理者,指派可靠的團隊成員,定期向自己討論新技術研究,透過這樣的形式,團隊成員學習到了新技術,自己也能夠掌握大概的狀況,不會完全不知道。過程中也可以分享自己的經驗,與團隊成員一起成長。

這過程中,一定遇到幾個不錯的團隊成員在技術上超越自己,身為團隊的領導者,不需要跟團隊成員比較,而是要鼓勵他繼續精進,同時引導他影響更多人,幫他創造舞台。

技術的道路是這樣的:

學無前後,達者為先

掌握本質的人,能更快掌握技術的精髓與奧義。管理的角度就是讓這件引導成員掌握本質,擴散掌握技能能力。這是個從技術人,轉換到技術管理必經,也是一定會遇到的狀況。因為:

時間在哪,成就就在哪

當管理佔據大部分時間時,要認知到,不是每個技術都能花時間去鑽研。

教學、分享、演講

做 Side Project 的過程,通常可以累積大量的核心觀念與想法,這些想法透過系統化的整理,可以漸漸的行程有價值、可重複使用的知識體系。我的經驗通常可以有三個圈圈:

  • 核心技術
  • 問題選型
  • 解決方案

核心技術大概是每個技術的基本概念,像是我在研讀 AWS 過程中,了解到每個 Service 的設計、功能,之後透過這些 Service 解決了工作上的問題,最後則是形成一種 Pattern:解決方案 (Solution)。

學習技術的過程,通常都會經歷以下的階段:

  • 第一:了解功能、名詞(定義 Class 職責)
  • 第二:了解其必要條件(清楚依賴、注入條件)
  • 第三:思考始用場景的前中後(new Class / destory instance,生命週期管理)
  • 第四:依據需求,選擇適當的使用策略 (Design Patterns)
  • 第五:找出最佳實踐原則與方法 (Arch & Framework)

對於技術管理者來講,使用場景必要前提條件 會是最重要的,因為這是 Why 的層次,也是通常對外溝通、技術決策必須面對的題目,同時也要清楚知道 TA,技術的服務對象,也就是 Who 的層次。至於 How 則可以讓團隊成員去深度探索,探索過程中,藉由討論了解 WhatWhen … 等,這個過程也可以分享自己的經驗,新舊的交替,會有很多激盪與相法,然後落筆寫下。

這些過程累積的知識與經驗,不管是成功的、或者是失敗的,都是值得分享的。透過內部的教學、分享,外部的分享與演講,可以漸漸行自己的個人品牌。某種程度,也為技術管理者開拓新的舞台,重新建立職場的技術貢獻與價值。而這個具體實踐的方法,請參閱 一個人的 Working Backwards 的介紹。

技術學習筆記的相關整理:


結論

管理工作有一個核心概念:

成就團隊的成就:團隊的成功,是管理者的義務;團隊的失敗,則是管理者的責任

技術 則是技術管理者的本,雖然隨著身份的轉換,但依舊可以透過持續學習,讓管理工作更有生命力、更有動力,也影響團隊更多。

彈吉他數十年,深切知道樂器沒有練,就會失去手感,特別是吉他這種樂器是極度重手感的,找回手感往往需要很多時間的積累,讓肌肉記憶回復,那種感覺就像有股氣流在手指上來回跑來跑去,泊泊然、綿綿然,弦上的每個輕微的震動、Pick 與弦的 Touching 都是吉他手非常重視的手感。而且程式也是,久沒寫了,IDE 更版了、工具變了、API 變了、工作環境變了,感覺都不一樣了。但是透過 Side Project 讓手感延續,也找回熱情。


延伸閱讀

站內延伸

參考資料



Comments

  • 全站索引
  • 關於這裏
  • 關於作者
  • 學習法則
  • 思考本質
  • 一些領悟
  • 分類哲學
  • ▲ TOP ▲