Tech Lead 和 Engineering Manager 有什麼不同 - 2
Tech Lead 和 Engineering Manager 有什麼不同 - 1
Tech Lead需要關注的第二個面向是「實作」。
這裡的實作，可能寫code佔的比例不會很高(有點失望嗎？😅)。因為Tech Lead要跳出來解決的，正是那些所謂的「xx障礙」。大部分是技術障礙(但現實是難免會有一些"別的"障礙…😏)，團隊成員的"功夫"越好，這障礙就會越難處理。除非你跟他們的差距真的太大了，不然他們的障礙必然也是你的障礙，別人可以向你求救，但你可沒人可以求救了，只得挑戰自己的專注力和耐心了。剛剛有提到導入新技術的評估對嗎？其實有些時候，新技術是否應該導入，並不容易光從規格，教程，文件或是作者等一些檯面上的資料來決定，很多時候還是要進入實驗的階段，才能知道新技術是不是解決了舊問題，卻導入了新問題。所謂的"實驗"當然是寫code，只是該怎麼寫？怎麼樣才客觀？這也是需要你和團隊伙伴有足夠的深入討論。
在「實作」面向中還常見一種工作叫「系統整合」。
有時前人所做的一些小工具，只為了滿足當時的一些小需求。但隨著業務範圍或深度變大，以前的系統可能會無法滿足需求，可能需要串連別的系統，或是加入一些新的元件做一些整合。有時候這不是工程問題，而是業務邏輯問題。如果不是很瞭解用戶很niche的需求，沒向工程師解釋清楚我們要滿足什麼，實作者很容易就會把一個簡單的盪秋千，搞成透過馬達全自動甩盪的威力版。這個過程中不管是因為需求，還是無意為之，有時也都會有一些意外的發明。
第三個需要關注的面向是「控制」，可視為是品質控制。
Tech Lead因為是熟悉技術的領隊，所以也是組織「源碼覆審(code review)」的主要人員。每個團隊會有自己的一個開發共識，可能是有編碼風格(coding convension)，有寫好的軟體元件(component)必須複用，或是有既有的框架(framework)供成員填入實作。不管是哪種規範，基本上都是為了品質而制定的，而Tech Lead在源碼覆審的會議中，就是要確保送交(commit)上去的源碼，有符合團隊的開發共識。如果有人"破框"，也要仔細的理解其理由，評估是否採納這份"創新"。
以上是Tech Lead的回顧，接下來就是Engineering Manager了。