軟體公司的技術管理

Tony Yeh
Aug 3, 2023

--

我的前公司,雖然在PTT的評價並不好,但我仍然可以公正地說:他是我20年的職涯以來,親身經歷過最好的公司管理制度。(但顯然我前同事都不這麼認為)

技術方面:

Code Review: 在merge到main之前,要經過languange commitee的code review, 需要至少一個approval才能進。對於提交PR的人影響是讓自己看到程式架構上的盲點,code裡行間的一點鬆懈之意都可能會被揪出來公諸於世。

Unit test coverage & code quality: 在提交PR之前,一定要過unit test coverage跟code quality這兩關,沒過的話連code review機會都沒有。

績效考核方面:

Peer Review: 匿名評論,用他人的角度客觀地了解自己的優點與缺點。很殘忍,但個人進步的第一步是發現問題。給了自己進步的目標。每個人在平時都要在自己的工作職責內做好服務,每一個跟你合作的人都是自己的client,每次跟他人有合作機會,都要控制好自己的EQ,儘量多做好服務,提供好的建議,在自己份上多做一步,這些微小的舉動都會讓你在每半年的Peer Review獲得好評。

Performance Review: 半年一次。先寫自評 => 再參考Peer Review =>再來team內做ranking => 然後加入不同team的越來越多人一起sorting,最後每個人會得到一個A+, A, A-, B, C等符合常態分佈的分數。然後這個分數會跟你最終拿的bonus有正相關。所以對個人來說是超級大事。如果不幸得到grade C,就可能會離開這個公司。自評面向包括Product Impact, Technical Excellence, Mission Mentality,每一大項都有很明確的定義,不是抒情文。你要提出足夠的事實跟數據來證明你在以上這幾個方面有做出貢獻,如果你稍微誇大,在ranking meeting裡manager也很容易可以把你揪出來。

這2個制度的好處是:讓同事之間有競爭(grading)、也有合作(Peer Review)。必須要保持自己在組織中前20%優秀,如果落後了,ranking結果會告訴你,你在下一個半年就要比其他人更努力地趕上來。

專案Review方面:

EOM (End Of Milestone) Monthly Review: 每個project每個月會舉行一次,最大的老闆會參加,由PO來做報告。報告的內容,除了要列出what went well之外,也要講出what’s not on track,不能報喜不報憂。老闆會針對每次的EOM提出一些他認為下個月應該要進步的地方。老闆情緒表達很直接,進展很好就會大力稱讚,如果project看起來沒什麼希望,可能當場就會砍掉,直接團滅。每個月每個project都必須死命地往前突破,不能停在某個地方,或是突然轉換題目,在EOM裡很容易會被發現,被嗆到爆。

量化指標:我們用Monthly Active Request來量化每個project的user喜愛程度。每個MAR的定義也是都要經過老闆approve,不能說user按一個鈕發3個API就算3個request,這一定會被打槍。而是要從end user角度來計算MAR,例如他登入後,必須要在頁面停幾秒才算一個MAR,那也不是每個user activity都算數,要有意義的action才算,用這個數據來量化這個service的被使用程度。每個PO再也不能空口說白話說自己的服務user很多、大家都很喜歡用。每個月Review MAR的數字,成長趨勢就很容易看得出哪個project猛烈成長,哪個停滯不前。

服務品質方面:

On-call system:每個online service都需要訂自己的SLA,例如response time P95 200ms以上就是sev3, 300ms 以上是sev2, 500ms以上是sev1. 而sev2以上就會馬上打電話給排班的人,也同步會create一個issue,需要即時處理。而每週也都有meeting會去review每個service的quality (sev count, availability, reliability)。常出包的service會被highlight,自己就要想辦法減少sev1, sev2出現的次數。這是認真要做online service所要展現出來的態度,排班的人半夜接到電話也要爬起來修。我們的user雖然不多,但都很重要。我們自己要在客戶發現問題之前就要修好,不能等對方發現了才用line來抱怨,這樣都太慢了。在Amazon有一個不成文規定,就算是在高速公路開車中接到service alert call,也要pull over到旁邊趕快修,就是要做到這種程度。

Release Process: 我們要release到production環境之前需要提供非常多資訊,例如最基本的repo/branch/commit,stress test result,SLA definition,call chain,test plan and report,code quality,UI and usability report,End to End test,MAU/MAR definition。然後每一關都有相關人要approval,Devops才能上到Stage,測試過後,再deploy到production。如果出問題了,也不能輕易地上production改,需要再上一張Hotfix Request ticket,當然不需要跑全套,但也要某部分的approval才能更新。很多時候Engineer會自己Hotfix或是release到production而PO不知道,可能沒有經過嚴謹的測試跟review就上去,導致user無法使用。或是根本沒有需要做這次的release。這個流程很大部份是為了因應ISO27001,但這樣的制度也讓每次release的目的被記錄下來,該被inform的人都知道這件事,雖然麻煩但仍利大於弊。

組織管理方面:

All Hands: 每兩週的週五(通常)會有一次全員大會,由大老闆簡單present一下每個project的進展,讓所有人都了解大致的business情況。也會開放匿名問題,老闆會當場一一回答,這也是展現公司文化的大好時機。例如表揚某員工的mission mentality,鼓勵大家work/life balance,以家庭為重,或是如何處理實際問題,例如我們常說要尊重每個engineer的喜好,但如果有一件必要的事但是沒有人願意做,這時manager該如何處置。All Hands比較像是大內宣的時間,搭配上吃吃喝喝,比較輕鬆的氣氛,個人覺得QA環節非常有意義,可以觀察組織文化被現實挑戰時,文化是否依然是贏家。

定期1–1:大老闆每一季會跟每個員工排一次1–1,EM也需要每個月跟自己的team member排一次1–1。在1–1會比較輕鬆地進行,不會在裡面交代工作的目標或進度。比較多是關心個人的狀況:例如工作生活有沒有遇到問題,對於組織、管理有沒有想法,有什麼建議等。我覺得這是建立彼此信任關係很好的管道。信任關係是不能速成的,依據我的經驗,大概到第3次,當你的member確定你會認真傾聽他的回饋之後,他才會說得更多。這也很適合告訴你的member他做得好的部分、可以努力的方向、以及你會對他在公司的職涯做什麼樣的規劃。

總結

仔細看的話會發現上面很多會議都是Routine進行,而非Event-Driven。也許有人會覺得會議過多,但這跟主持人組織的功力有很大關係,如果每個會議所有參與人都覺得很有收穫,獲得很棒的建議,跟清楚的方向,相信頻繁的溝通就會省掉很多走歪路的時間。

大部分的公司都是Event-Driven的會議,為了處理緊急狀況、救火。再厲害的人如果長時間處在救火模式,他也在公司待不久的。

--

--

Tony Yeh
Tony Yeh

Responses (1)