内容简介:很多技術背景的工程師,隨著年紀與歷練,會有機會帶團隊,成為 Team Leader / Techincal Leader,甚至轉換身份成為管理者。這些轉換很常是學而優則仕、公司上級的期待、被逼上火線 … 但這都算是被動因素,也就是不是自己願意的。這一收一放,一段時間之後會發現,自己對技術會越來越陌生,跟團隊成員比較起來會越來越不如,很常會被底下的人質疑自己的技術能力,但身為管理者、Leader,卻需要做技術決策、選擇、提出建議 … 等,很多人因此就打退堂鼓放棄了,回到純粹的 Tech Leader 的角色。
很多技術背景的工程師,隨著年紀與歷練,會有機會帶團隊,成為 Team Leader / Techincal Leader,甚至轉換身份成為管理者。這些轉換很常是學而優則仕、公司上級的期待、被逼上火線 … 但這都算是被動因素,也就是不是自己願意的。
管理
實際上是另一個高度專業的工作,所需要的技能與技術工作者是截然不同的,也因此很多初任管理工作會常常出現患得患失的狀況,因為需要慢慢地放手最熟悉技能 (技術) 讓團隊去執行,而自己卻要面對陌生的管理工作,像是協調、溝通、管人、管事 … 等看起來很雜、非常雜的任務,簡單說:像是打雜的。
這一收一放,一段時間之後會發現,自己對技術會越來越陌生,跟團隊成員比較起來會越來越不如,很常會被底下的人質疑自己的技術能力,但身為管理者、Leader,卻需要做技術決策、選擇、提出建議 … 等,很多人因此就打退堂鼓放棄了,回到純粹的 Tech Leader 的角色。
接下來,我打算整理一些列文章,分享我轉換到技術管理者多年之後的心得,先以這個問題開始:
管理者如何持續學習技術?
如何持續學習技術?
對於一個技術背景的管理者,沒有時間寫程式,該如何持續學習呢?
訂閱相關技術專欄,保持對新技術、新名詞的靈敏度
管理者基於溝通與引導團隊的原則,需要對於新技術要有認識。認識新技術如同認識產品的新需求、新功能一樣,要了解以下:
- 為什麼有這樣的技術出現?
- 這技術它要解決什麼問題?
- 這個技術的最佳使用情境?
- 其他類似的技術有什麼?
- 使用這個技術有什麼前提?
- 目前組織裡面,使用這技術的效益在哪?
- 導入新技術要面對哪一些新問題?
了解這些背後的原因,最好個人做一些簡單的 Lab,體驗與感受新技術。
除了了解新技術,另外透過訂閱技術專欄,知道一些新名詞的出現。新名詞通常是新時代的開始,像是 DevOps、Cloud Native、Kubernetes、Service Mesh … 等。這些名詞的出現,往往背後隱含著接下來排山倒海的改變與翻轉,技術管理者必須要有靈敏,感覺接下來可能要面對的變革,要面對的挑戰,然後要面對的就是 技術決策
:到底要不要用?
研讀經典
新技術會不斷出現,但是大部分所謂的 新技術
實際上都只是重新包裝的新實踐。包裝什麼?包裝 電腦科學核心知識
,也就是資訊工程研究所的必考科目:
- Operating Systems (作業系統)
- Algorithm (演算法)
- Data Structure (資料結構)
- Compiler (編譯器)
- Computer Architecture (計算機系統結構)
- Computer Organization (計算機組織)
- Computer Network (計算機網路)
- Distributed Systems (分散式系統)
深根這些核心知識,然後工程實踐的部分則是:
- OOP / Design Pattern
- Linux / Unix
- AWS / GCP
- Kubernetes / Microservices
- 軟體工程、軟體開發
- DevOps / SRE / DevOps
這些範圍都很大,一些具體的實踐方法就是研讀經典:
- 持續交付
- Clean Architecture
- SRE
- Code Complete
- Refectoring
- Thinking in Java
- Introduction to Algorithms
- Effective Java
- Design Pattern
- 人月神話
- Peopleware
整理與組織過去所學
技術管理者通常也會是資深開發者,會具備一定的實務經驗,而且通常會有很多想法。而這些經驗與想法常常會因為專案趕時程,因而被埋藏在深邃的記憶中,沒有被組織、整理下來,也鮮少分享出來。
如果可以定期地把這些想法、心得、遭遇到的問題,透過文字方式寫下來,然後重新組織與思考,這個過程可以重新思考全貌,然後了解自己已經有的、不足的,進而刺激自己把它完整的動力,最後自己會有很大的受益。
相關經驗: Designing Test Architecture and Framework 、 聊聊軟體交付的濫觴 談產出物管理 (Artifacts Management)
相關文章:怎樣看見全貌、 閱讀能力的重要性 、 為什麼寫文件?
定期做自己的 Side Project,保持手感,整理心得文
技術管理者不會實際下去執行任務,怎麼指導團隊?特別用的是新技術時怎麼辦?答案很簡單:
做自己的 Side Project
Side Project 通常是很小的,主要是了解新技術的核心概念、運作原理、應用場景、驗證技術的特性。而這過程不是要做出很完整、或者很大的東西。重點是自己可以掌握這些技術的核心概念,未來跟團隊協作時,可以與團隊流暢的溝通,可以決定技術的選擇方向。做的過程,可以把心得整理成文章,放在 Blog 形成自己的知識體系。
相關經驗:Overview API Gateway
與團隊成員發想、討論,讓團隊成員 PoC 技術
上一段提到做自己的 Side Project 保持手感,但現實往往沒那麼美好,上班時間多時候技術管理者需要花費大量心力在於帶人、溝通、協作之上,實際上只能利用下班自己找時間做研究,而往往下班要面對的會是家庭問題,時間能放在技術研究之上,實際上會少之又少。
如果是這樣的管理者,就要指派可靠的團隊成員,然後定期向自己討論新技術研究,透過這樣的形式,團隊成員學習到了新技術,自己也能夠掌握大概的狀況,不會完全不知道。過程中也可以分享自己的經驗,與團隊成員一起成長。
教學、分享、演講
做 Side Project 的過程,通常可以累積大量的核心觀念與想法,這些想法透過系統化的整理,可以漸漸的行程有價值、可重複使用的知識體系。我的經驗通常可以有三個圈圈:
- 核心技術
- 問題選型
- 解決方案
核心技術大概是每個技術的基本概念,像是我在研讀 AWS 過程中,了解到每個 Service 的設計、功能,之後透過這些 Service 解決了工作上的問題,最後則是形成一種 Pattern:解決方案 (Solution)
這些過程累積的知識與經驗,不管是成功的、或者是失敗的,都是值得分享的。透過內部的教學、分享,外部的分享與演講,可以漸漸行自己的個人品牌。某種程度,也為技術管理者開拓新的舞台,重新建立職場的技術貢獻與價值。
結論
管理工作有一個核心概念:
成就團隊的成就:團隊的成功,是管理者的義務;團隊的失敗,則是管理者的責任
而 技術
則是技術管理者的本,雖然隨著身份的轉換,但依舊可以透過持續學習,讓管理工作更有生命力、更有動力,也影響團隊更多。
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
URL 编码/解码
URL 编码/解码
Markdown 在线编辑器
Markdown 在线编辑器