這一篇是紀錄閱讀 《知行》: 技術人的管理之路 的讀書筆記，這本書是參加 TGONetwork 所舉辦的 TGONext - TGONetworks 導師計畫 成果發表會導師 Taien 所贈送的，能夠拿到導師所贈送的書自己也有點意外(當天上台分享時蠻掉漆 XD)。這半年來工作上寫 Code 的時間越來越少花很多時間都在與團隊同仁溝通，在規劃新項目或是簡報時不是那麼的流暢(得心應手)似乎總覺得少了什麼，因此決定靜下心來好好的把導師所贈送的書了解一番，才不會枉對導師對我的期待(自以為?)。這篇文章僅介紹第一章節 : 管理路口的徬徨，整理可能當開發者要轉換成技術管理職可能會遇到的一些問題，其中若是自己有理解不正確的地方是錯誤的部分歡迎各位管理大神一同討論或給予指導
工程師發展路徑
在書的一開始，作者提到過去有一群從 2005 年開始工作的工程師好友們，在某次聚會中整理這些好友目前的職務可以分為幾大類 (作者為大陸人，書中內容可能會因為場景或是地區不同有所差異)
技術類 : 架構師、技術專家 管理類 : 技術管理者、職業經理人 創業類 : 創辦人、技術合作者 顧問類 : 投資顧問、管理顧問可能隨著能力的提升可以做的事情越來越多，提升架構能力後轉為架構師；或是專案管理及帶團隊能力越來越強，逐漸轉為技術管理者；有很好的想法想要做自己的一番事業，成為創業公司的技術合夥人；書中提到特點之一是 10 年後堅持做技術比例的只剩 20% 左右 (沒有一定，最自己而言做自己最喜歡與認同的角色即可)。不管是走上述哪一條路，有些基本能力可能會是通用的，像是規劃、帶人、管理、溝通及執行能力，也可以說是環繞著技術與管理這兩條路在走，只是不同職務所面臨與擔負的責任不同。
我到底要不要做管理
作者常常被工程師問到我適不適合做管理?您對我有甚麼建議，作者則會反問工程師幾個問題
做管理對您來說意味什麼? 您覺得它能給您帶來什麼希望可以透過此問題來讓提問者去了解到做管理的初衷，而非直接透過回答的方式取得答案；如何審視管理對您來說是不是真愛呢，可以透過三個問題幫自己做判斷
您是否認同做管理的價值 ? 您是否對管理充滿熱情 ? 並享受這些工作呢 您是否看中在管理方面的成長呢 ?管理與技術的挑戰不一樣，常常會需要接觸很多雜事像是面試、團隊溝通、規劃流程、與主管匯報、資源協調與績效評估等各式各樣的管理工作，與開發工作相較之下項目較多且較為雜亂，可能也很難從中獲得成就感與價值，如果不認為管理是有價值的可能較難持久下去，可能會有覺得寫代碼較為單純的念頭出現。但從另一個角度來思考，過去在開發可能只要做好主管交辦的項目即可，但轉做管理為了要帶領整個團隊前進，就須思考上級、同一層單位、下級各方面的期待與訴求，要求自己用更全面的角度來思考問題的解決方式，這些挑戰也會替您帶來成長，成就感與影響力。
我要不要轉回去做技術
俗語說《人窮則反本》，當人們遇到挫折就會想回到老路上。作者提到在訪談的 2/3 的新技術經理，都有類似的擔心跟問題，問題像是做了管理之後沒時間寫Code，覺得離本行越來越遠；不知道在管理與技術中如何取得平衡，兩者兼顧；管理工作瑣碎，技術越來越少接觸覺得心虛；因為技術人員常常會專心在代碼或是某些技術上，但對於職業生涯思考方向算是被動，可能不是主動的或是被動推到經理的位置上，過去沒有經驗且可能對管理沒有深入的了解，初期在不熟悉的情況下可能感到慌張或焦慮；或是覺得 技術才是自己的根本，在面對上述問題，作者提到親自寫代碼是很好的實現方式，但作為管理者必須要掌握更多的技術，快速判斷該如何搭配使用，所以必須有更高效的學習方式，建議如下
建立你的學習機制 : 思考團隊內可以建立甚麼樣的學習機制，可以借助團隊的力量提升技術判斷力，也讓團隊能力提升。 請教專家 : 借助平台找到該領域專家大神進行請教，能成為某領域高手都有深厚的知識累積，且能用簡單精準的說明讓人容易明白與了解。 共創 : 對於知識型工作者來說，和大家共創所收穫的成功，比自己埋頭思考高效許多。如果您對技術充滿著熱情，目標是成為一位優秀的架構師的話，做管理所累積的能力是完全可以遷移到架構師上，在管理上所具備的全局視野、規劃能力、結果導向、專案規畫及溝通與協調能力，這些都是優秀的架構師必須具備的條件之一。其次，不管是做技術管理或是架構師角色，看事情的角度都必須從 High Level 的角度來思考，建議如下
從目標出發看待技術 : 目標明確，才可以選擇最佳的技術方案，做出最合理的技術決策。 從評估角度看待技術 : 必須清楚了解技術方案是透過哪一些維度來評估好壞優劣，當技術問題暴露出來時會造成甚麼影響，損失的邊界為何 ? 從依靠自己技術到借助大家的技術 : 要熟悉團隊每位成員的技術情況，知道誰可以勝任做什麼事，適合做什麼，借助大家的技術去做事即便做不好也不是沒有回頭路，在轉作技術管理者時離技術很近，如果嘗試下來認為管理工作確實不是自己想要的(天命)，那麼回頭繼續做工程師是幾乎沒有門檻的，但前提是自己必須先全力以赴的去嘗試一段時間，盡全力的去做一件事之後才不會有遺憾，才可以知道自己到底適不適合做技術管理的工作。
如何保持技術競爭力
如何保持技術競爭力是自己最感興趣的議題，在轉型技術管理者之後，自己可以支配與寫代碼的時間會越來越少(最近感觸很深阿)，書中提到當你的角色從《技術實現者》轉變為《技術管理者》時，與技術的關係就發生了變化，過去開發者對技術的追求可能是以《技術實現者》的角度出發，但現在是轉變為技術管理者的角色，對於技術能力這詞也就悄悄的開始轉變，應該以技術應用者的角度出發，技術評估能力變得為其重要，要關心與思考的是 why & what，也就是要不要做這件事以及這是件什麼事情?並在綜合評估之後做出決策與判斷。
那麼如何精進技術判斷力就會是一個重要議題，作者提到技術評估有以下三個維度
維度一 : 技術項目結果評估
在決策要不要做一個事情時，需要回答三個問題
這究竟是件什麼事情 希望得到的結果是什麼 要用什麼角度/維度衡量結果，從那些技術指標去驗收結果有個目標與希望預期得到的結果，才可以有始有終的做出準確的判斷與正確的決策，舉例來說
- 可能為了要提升服務穩定性，去調整服務架構
- 可能為了提升數據的準確性，去改寫技術數據的收集流程
- 可能為了提升系統效能指標，去調整數據庫效能讀寫模組
維度二 : 技術可行性評估
可行性有兩層涵義，分別是 能不能做 與 值不值得。
- 能不能做 : 是指有沒有能力做到，這是能力問題
- 值不值得 : 是指能力允許，全力投入之後的結果是否是值得的(效益)，這是選擇問題
投入的資源成本 技術維護的成本 - 技術選型成本 - 技術升級成本 - 問題盤查成本 - 代碼維護成本 機會成本 協作成本
維度三 : 技術風險評估
技術風險評估也叫技術風險判斷，也就是有哪些技術風險需要未雨綢繆，該技術方案帶來最大的損失的可能性是什麼，以及在甚麼情況下會發生。舉例來說，為了降低 DB Loading 可能會加上像是 Redis 的 cache 機制，在使用時可能要思考當快取發生異常時，快取 Server 重啟因為沒有對應的快取資料，這時請求全部都跑去訪問資料庫，可能會造成快取雪崩或是快取穿透的狀況發生，這時候的解決方案或是甚麼 ? 要如何防範以及團隊同仁要如何解決，這些都可能是上線後可能會遇到的問題。風險評估考驗技術管理者的技術經驗與風險意識，經驗越豐富則對風險的判斷也就越敏銳。去拓展技術視野與技術判斷力常見方式如下
建立技術學習機制 專項技術調研項目化 與技術專家交流 聽取工作匯報另外，你不是一個人在戰鬥，因此風險評估上也需要借助團隊的技術力量做出準確判斷，並非只靠技術管理者的技術判斷力，能從周圍人群學到多少訊息與資訊，而不是在靠自學。
核心是在如何提升技術實現的能力，轉變為提升技術判斷力與技術評估能力，有些管理者擔心自己一旦不是團隊技術能力最強的人，會因此有團隊成員不服氣，但從另外一個角度來看，管理者的職責是帶領團隊高效的交付高質量的產品與系統上，隨著年紀的增長，團隊中比你優秀的人才會越來越多，是一種好的現象，如果多年之後你依然是團隊裡技術最強的一員，可能不是一個好的現象。
...To Be Contined
心得
這篇文章僅介紹第一章節 : 管理路口的徬徨的部分，擔任開發人員也有10年的時間，其實在最近幾份工作主管都有建議可以嘗試往技術管理的路前進，但由於自己認為技術能力還尚未到一定的水準所以都不小心
參考
《知行》: 技術人的管理之路
0 意見:
張貼留言