Kalan's Blog

Kalan 頭像照片,在淡水拍攝,淺藍背景

四零二曜日電子報上線啦!訂閱訂起來

本部落主要是關於前端、軟體開發以及我在日本的生活,也會寫一些對時事的觀察和雜感
本部落格支援 RSS feed(全文章內容),可點擊下方 RSS 連結或透過第三方服務設定。若技術文章裡有程式碼語法等特殊樣式,仍建議至原網站瀏覽以獲得最佳體驗。

目前主題 亮色

我會把一些不成文的筆記或是最近的生活雜感放在短筆記,如果有興趣的話可以來看看唷!

成為 Tech Lead 的一些感想

被主管升上 Tech Lead 後我的心情有點複雜,因為職等既沒有對應的提升,也沒有一個實際的稱號,只是被指名了「嘿,從現在開始你就是 Tech Lead」,然後加了一點薪水。

不過對我來說是個很好的嘗試,在這邊記錄一些感想。

Tech Lead 與 Team Lead 的差別

在名詞的定義上我比較傾向於 Tech Lead 而非 Team Lead。

兩者對我來說意義不太相同,一個是單純在技術上跟開發上做領導,一個則是有點偏向管理職還有帶團隊了,我現在的角色比較偏向 1。(當然名詞的定義因人而已,這邊只是點出我的想法)

從開發早期的早期階段,我就算是一個喜歡埋頭寫程式碼的工程師,倒也不是說 spec 什麼的就不去理解,而是比起解決人之間的事情,我更喜歡直接從架構上下手。

這也是我最大的弱點且需要改善的地方之一,就算自己一個人寫很快,但不提升團隊開發速度的話其實沒有什麼太大效果。

為什麼這樣說?假設你完成功能的速度很快、品質好、Bug 也很少;但是你的團員知道這個功能在幹嘛嗎?你的團員跟得上你的腳步嗎?你的團員寫程式碼都是類似的思維嗎?

如果這些問題都是否,那麼你很有可能在開發中後期開始遇到各種不符合 spec、當初沒考慮的 Bug 噴出、被其他團員的程式碼拖慢腳步,最後全部的開發都會卡在 QA。

跟之前的差異

最明顯的差異就是會議變多了,以往只要開發者之間跟 Engineer Manager 內互相討論就好,但是升上 Tech Lead 之後開始要跟各個部門、專案的人合作。以前講英、日文的比例大概是 7:3,現在完全反過來,還好這家公司對敬語不太在意,不然感覺好辛苦。 另外就是大家對你的期望也理所當然越來越高了,任何規格、spec 不清楚的部分第一個就是先找你,所以對規格的掌握就要比其他開發者來得深,也要知道大概會遇到哪些問題給出解決方案。 另外就是寫扣的時間明顯減少了,但其實沒有少很多,而且資料抓出來反而我還是寫最多的那一個,這其實是個不太好的信號,我應該花更多時間去思考如何改善整體流程與團隊運作上,而不是花時間寫程式碼。

事前發現問題比解決問題更重要

我發現比起解決問題,發現問題本身重要更多。在這次的團隊中,我發現潛在問題有幾個:

  • 團隊成員相對沒有處理複雜場景的經驗
  • 不注重整體流程與程式碼品質
  • 不會完全按照(理解)spec 以及與 Planner 溝通可能的潛在場景。

舉例來說,我在開發階段就隱約感受到有一位團員會堅持某些細微的實作細節,雖然這本身是好事,但如果花了兩個月還做不出任何東西,導致時程延誤的時候就是大事了;另外就是對品質與整體流程的不注重,什麼問題都想靠其他團員的 Code Review 來抓錯,導致後來 QA 回報的問題越來越多,整個開發團隊忙得不可開交。

說真的那段時間我很失望,但也反省了很多事情。

  • 在開發中沒有所謂的英雄主義,別妄想成員們會一夕之間改變
  • 比起程式碼品質(當然這也很重要),先把問題的根源釐清再說

上述提到的問題導致開發後期修 Bug 的成本增加很多,也因為時程的關係每個人情緒都很緊張,也要投入更多時間,整體的品質就會下降很多。也因此比起解決問題,早期發現早期治療這句箴言也應該被當作信條遵守才是。

視團員們準時下班為第一守則

我自己很希望做到的一件事是,讓其他團員們準時下班,在專案上也可以盡情做到想嘗試的事情,但總覺得自己離這樣的理想還有好一段距離。

掌握團員進度很重要

我會升上 Tech Lead 的原因或許是因為在第一季的活躍跟積極度讓主管注意到我,也可能是因為在技術與業務場景處理上比其他團員更有經驗。

但是如果只有自己擅長的話那也沒有用,會自己忙到死,同時也要讓其他成員知道業務場景的重要性以及需求才行。

如果這個團隊存在沒有你就做不到的事,那麼這就不是一個理想的團隊

我相信這個道理,也在上一間公司體驗到類似的事(在上一間公司並非 Tech Lead),當大家幾乎都擁有同樣的價值觀、技術力、個性時,不論經驗或是職位差距,合作起來就會非常順利。不需要特別跑 Scrum,開各種會議,大家就會準時甚至提早交出成果來。

當然這種團隊可遇不可求。所以大部分的時候我會透過在 Daily Meeting 的詢問,讓他們知道該設計的地方有哪些。這是最直接影響 Sprint 產出的要素之一,也是解決問題的好方法。

但這就需要我不僅要顧及自己的開發進度,同時也要對整體的架構、規格非常熟悉,才能知道可能的問題有哪些。

理解自己的優劣勢

我非常不擅長於說教跟改變一個人,也不是容易跟人打成一片的個性,所以一旦我希望成員做到某些事情,口氣往往聽起來會有點激進。

我完全無法忍受有人偷懶拖慢團隊進度,當上 Lead 之後開始會追蹤各個團員的進度,我發現當中有一位成員在提交的 Pull Request 以及 Code Review 上是明顯小於其他成員的(大約 2 倍以上)。我試過很多方法,包含在 Code Review 上積極點出錯誤、在 Slack 上提點細節、對於延誤沒回應的 Pull Request 做詢問,但如果對方都不改善的話,我其實也沒有任何職權做什麼就是了。

找到 Blocker 指標

對我來說有幾個指標是要特別注意的

  • 複雜且有大量更動的 Pull Request:這很有可能會是 QA Issues 的主要觸發區,所以要確保測試通過還有開發人員的一致理解。
  • 在 Sprint 結束前的 Task 數量:很多開發人員不會特別在意。如果他們有非常多 Working In Progress 的 Task,可以詢問一下他們的進度。如果太常發生類似的狀況,代表團隊中有人超載
  • 過度或不適當的重構:我們應該要避免不適當或是過度的重構,如果重構破壞了原有架構,會讓 QA Issues 非減反增,反而得不償失。
  • 用指標來評估團隊效率:Code Review 時間、Pull Request 數量、一個 feature 從開發後到 merge deploy 要多久?
  • 有團員一直卡在某個 Issue 上,沒有任何詢問。往往是他們卡關又沒有發出求救信號

要深究下去還有很多,這裡只講我想到覺得很重要的幾點。

後記

老實說我還是有點迷惘,一方面是我在這裡遇到的開發者,比起以往的同事對於技術比較沒有那麼熱衷,很多時候都是求任務完成就好。也不會特別在意開發流程或其他改善,這是讓我非常沮喪的地方。而主管也認為我應該要去幫助他們,多多體諒文化差異。

但如果一個人不願意改變,然後做了各種影響團隊產出跟動機的事,為什麼要被譴責的是我而不是他?還要用我的績效考核來陪葬?還是用文化差異就可以無限上綱到蹺班不工作也沒關係?

另一方面,我並沒有實際的職權去做人力、資源的調整,頂多就是把問題再丟給上層而已,這次的開發不僅時程緊湊,加上各種經驗的不熟稔和人力的調整過於緩慢,導致整個開發根本沒有什麼時間在做真正應該處理的事,我也根本無力改變什麼。

當上 Tech Lead 之後的確也開啟我不少視野,以往跟非工程師的交流並不多,但現在幾乎每天都要頻繁跟跟 Planner 協商、討論各種 Spec 上的細節,東京人不知道為什麼講日文要快兩倍,讓我日文瞬間進步不少,也學了一大堆業務用日文。 很多時候只要從公司的角度出發去想規格就可以解決很多問題,在交涉的時候也只要想辦法解決他們的問題,雙方的僵持就不會那麼嚴重。

哎,結果到頭來最大的問題還是人。

更新(2020/06/15)

在文章發布之後,主管有主動跑來找我聊天,解答了一些我在文章中提出的疑問。這篇文章意外地受到蠻多迴響,或許是大家的經驗上都有類似之處而產生共鳴。比較想要補充的一點是,這篇文說到底也只是個人感想的總結,也有可能因為觀點不同而有所偏頗。

另外感謝推友 @brucesu 推薦的文章「breaking the senior developer ceiling」 ,蠻認同文章中的觀點,如果希望繼續往上爬,有時候寫扣已經不是必要,而是專注提供價值更高的事,也要試著多從公司的角度來看。

雖然如此,我自己認為在技術上還是有很多磨練不足、不成熟的地方,因此在這個階段還是想要多技術為主,並且多往架構層面邁進。

上一篇

科技始終來自於人性(Svelte Society: Frequently Asked Questions 筆記)

下一篇

eRemote 紅外線遙控器與 Google Home 實現智慧家庭

如果覺得這篇文章對你有幫助的話,可以考慮到下面的連結請我喝一杯 ☕️ 可以讓我平凡的一天變得閃閃發光 ✨

Buy me a coffee