團隊進步的秘訣


其實這是一篇標題殺人的文章。 我們並不知道怎麼建立一個”超強”的團隊,”超強”太難也太遙遠惹。 但如果說,怎麼建立一個”一直變強”的團隊,我們倒是略懂略懂!

從一開始到現在,Codementor 的團隊從一個人成長到目前的近三十人。 雖然說以絕對值來說並不是什麼太了不起的數字, 但是以支撐產品快速前進為前題,過程當中各個階段都隨時會出現不同的挑戰。

現在回頭看,其實大部份的事情我們並不是一開始就有一個明確的想法或方向, 而是透過團隊成員們的相處,自然而然地收斂成為大家共同的中心思想。

在這篇文章裡面,我們把一些作法整理歸納,和大家分享一些關於團隊合作的各種東西。 我們會先由比較抽象的概念和目標開始,再到我們嘗試過或正在進行的具體方法。

在開始之前

現在回想起來,在解決問題的時候,”大家最後最後是在乎同一件事情”是很重要的。

對於 Codementor 來說,我們的那件事情是 又快又好

對我們來說,一個新創團隊唯一的優勢就是快。 我們希望用最快的速度,把任何產品的想法交到使用者手上去驗証。 但大家也都知道,如果凡事都要求快,最後的結果就是大爆炸一發不可收拾。 所以 “又快又好” 的白話版本是:

如何在持續高速前進下又可以維持一定水準以上的品質呢?

當然,每個團隊的最重要的事情鐵定是不一樣的。 但不管那是什麼,找到最在乎的事情,並且取得團隊的共識是相當重要地!

在有了”最在乎的事情”之後,接下來就是要怎麼達成它了。 對我們而言,”人”是最重要的關鍵。 而”人”的因子,又跟招募有直接的相關。 簡單的說就是,只要找到對的人,後面一切都好辦。 但是怎樣的人才是對的,怎樣又才是錯呢?

我們把人的特質分成兩類:第一類是容易改變的特質。 像是熟不熟悉某個程式語言、會不會用某個工具、知不知道某個 framework 怎麼使用等等。 這些特性有一定的參考價值,但它們是容易改變的。 今天你問我 Database 的 index 是什麼我可能回答不出來(但其實我答得出來 XD) 但可能我 google 一下立刻就可以回答了。

第二類型的特質是不容易改變的。 好比說”絕對不能妥協的事情”,溝通的方式等等。 基本上就是江山易改本性難移的意思。

在招募的時候,我們的作法是先定義出期望中的第二類特質,然後用這些特質為目標找尋適合的夥伴。

從一開始到現在,我們慢慢歸納出我們希望的”第二類特質”有:

1. 喜歡我們的產品

對產品的熱情是我們最看重的項目之一。其實背後的原因是,我們認為每個人都應該要做他最喜歡的事。 人生很短,要做的事情很多。而人的一天有三分之一甚至更多都在上班。 我們實在想不到任何理由讓一個人每天和他不喜歡的產品為伍。

從正面的角度來看,我們認為團隊裡的每個成員,都是共同打造產品的重要角色。 如果真心喜歡這個產品,那會有源源不絕的好主意可以讓它變得更好。

2. 喜歡自己在團隊裡做的事情

這點和上面的出發點差不多,只是切入的度入略有不同。 以工程師來說,在 Codementor 的 dev team 我們每天花很多時間寫程式、討論程式、看別人的程式。 所以我們想要找到也喜歡做這些事情的人,跟我們一起工作。

3. 和團隊互相喜歡

這點的出發點又再度跟上面重覆 XD 如果人一天有八個小時,要跟一群你不喜歡的人一起密切討論各種事情,那簡直超痛苦阿。 在更正式的描述下,通常這點稱作 cultural fit。 但我們又認為 cultural fit 實在有點太籠統了,所以試著把它再細分成下面兩點:

3.1 在乎相同的事情

以我們來說,在工程上我們最在乎的事情就是 “開發的速度” 和 “程式碼的品質” 之間的平衡。 有時候這類東西不一定可以找到明確的量化標準, 但透過和應徵者討論各種問題,大概可以做出判斷。

3.2 可以理性地進行激烈辯論

我們相信,任何好的決定,不管是程式、產品流程等等,都鮮少是在一開始就想到最好的答案。 而是要經過不斷的嘗試在錯誤中學習,最後修改而成最適合當時的選項。 而這個過程中,有一個重要的關鍵就團隊的夥伴們必須不斷地挑戰對方,進而得到最好的解法。 於是我們對於要加入的成員有了這樣的期待。 翻成白話文就是:要可以互相挑戰對方而不會生氣,也不會讓對方覺得生氣。

實驗、實驗、實驗

在”人”的因素之外,另一項我們得到的珍貴結論是:建立在各種地方做實驗的環境和習慣。 現在回想起來,眼前我們覺得很棒的產品、流程、技術上的選擇等等,其實都是當時實驗得到的結果。

打造實驗的環境和流程

在小學做實驗的時候,流程大致上會是:

  1. 定義要解決的問題
  2. 做出假設並且設計實驗
  3. 驗証實驗的結果,和預想的一不一樣
  4. 如果不一樣的話,試著找到其中的原因,進行下一次的實驗

在 Codementor,我們試著在各種情境下進行實驗。 像是”要不要做一個新產品“,”大家都說 pair programming 很不錯,要不要試看看”、”現在用 Rails 好像蠻爽的,但要不要試看看 Golang 呢?”。

但是實驗在進行的同時,產品前進的步調還是不能停下來阿。 這時候定義問題、實驗的 scope、評估實驗成敗的標準就是很重要的事情。 這些看起來單純的步驟,其實執行起來並不一定容易。 但以我們的經驗來說,多練習幾次會變厲害是肯定的!

舉例來說,現在的 CodementorX 是我們的主力產品之一。 但當時是來自於我們本來的平台上,有一部份的使用者希望直接外包案子,而不是進行1:1的教學。 最一開始我們直接發問卷給 user, 用人力直接幫他們媒合。 接下來在經過無數次的迭代之後,才有了現在的 CodementorX。 (當然還有更多失敗的例子就留到以後再說了 XD)

透過實驗可以讓我們不用去猜說這個作法到底會不會 work,而如果實驗不小心失敗了,在檢討的過程中往往可以學到更多。

每天都要變厲害! – 讓知識快速流通

如果每天都變強百分之一的話,一年就會變厲害 (1.01)^365 = 37.78 倍! 在一個團隊裡面,每個人都有各自學習的領域。 但如果可以透過某些方式讓每個人的知識都可以快速地流通讓其他人學到,那簡直事半功倍阿! 而如果每個人都變強了,整體的生產力自然就提高了。 這一點是在我們團隊成員漸漸變多之後,覺得效果顯著的一個方向。

在過程中,我們在各個階段嘗試了各種方法,有幾個跟大家分享:

Weekly Dev Sharing

從2017一月開始,我們試著每周一次的 Dev sharing。 每周請大家輪流分享各種跟工程相關的東西,在星期三的中午分享讓大家配飯吃。 可能是最近讀到的書、看到的 blog、解的很難的 bug、或是踩到的 legacy code 的雷等等。 並且把它們記錄在一個共同的文件下可以用來搜尋。

分享的主題五花八門,從基本的”深入淺出 unit testing”, 到比較硬派的 DynamoDB, Google Cloud Composer、 再到 Design Thinking、Design Language(是的,這些是由工程師主講的主題) 等都有。

到目前為止還是認為它是一個很棒的事情。 對於聽眾來說,可以快速了解一個全新的東西的大架構、要解決的問題等等。 而對於講者來說,則是會更仔細的記錄自己的學習。

Code Review

在每個 feature branch 要 merge 前,我們會請一到兩位同事幫忙 review code。 透過這樣的過程,會讓每個同事對整份 code base 都有一定的了解。 而如果 reviewer 對於這個 feature 有什麼覺得可以調整的地方,可以立刻針對實際的 code 討論。 對於雙方來說都是很棒的激盪和學習。

Post-mortem (learning review)

在每一次重大的 outage (這種事總是會發生的 XD)之後,我們會把詳細的處理步驟記錄下來。 包括幾點幾分怎麼發現狀況的、在每個階段做了什麼處置等等。 這樣的流程目的並不是檢討是誰的錯抓出戰犯, 而是要建立出一個機制,讓我們下次就算一樣不小心,也不會造成可怕的後果。

另外,我們也發現,找到一個合適的記錄方式在上面的流程中是很重要的。 把這些東西變成一個團隊裡公開的資源,可以讓大家快速的站在團隊累積的成果上,而不用從頭開始。

加速 feedback loop

身為工程師,我們都知道在種時候加快 feedback loop 會發生很多好事情。 可以讓我們立即修復錯誤、調整方向,同時也避免往不對的方向走太遠。

舉例來說,當我們寫了一段程式之後,如果可以”立刻”知道它是不是可以正確地被執行, 那我們就可以立刻修復錯誤,並且進行下一輪的”知道結果 → 修復錯誤”的循環。 相反地,如果我們無法”立刻”知道結果,而是要等好久才能知道的話,那這個循環就會變得非常沒有效率。 因為除了等待的時間之外,在等待的當下,我們有可能又犯了同樣的錯誤, 於是在下一個循環就必須再修復同樣的錯。 在工程上,常見的流程像是 TDD、CI/CD 等其實一大部份都是在加速這個循環。

而除了工程之外,其實團隊的開發流程也是在不斷的 “知道結果 → 修復錯誤” 中進行。 和程式的錯誤相比,團隊的開發流程的”錯誤”帶來的代價更高。 可能是某個溝通環結有了不必要的來回,又或者是需要一個新的工具來管理文件等。 這類的錯誤也要花更多時間去嘗試修復的辦法。 於是加速 feedback loop 就在這邊就顯得更為重要了。

在 Codementor,針對這個問題我們的做法是:制定一個流程,定期地收集大家的 feedback。 其實在 scrum 的流程裡,retrospective 應該是企圖做到類似的事情。(我個人對 scrum 不是相當熟悉,所以如果有誤請大家指正 :p ) 但因為我們目前的開發流程並沒有 follow scrum,所以我們安排每個月一次,然後叫它 Process Review。

Process Review

每個月,Dev team 會聚在一起討論在開發的流程上有沒有什麼可以更好的地方。 這個作法的出發點是,我們認為:

  • 流程合適與否是動態的。一個月前覺得很OK的流程,現在可能已經造成困擾。
  • 總是有辦法可以讓我們更快更通暢

而所謂”流程”,其實每個團隊都有所不同。技術上來說,我們目前會用下面這些點來看:

  • 開發的速度
  • release 的容易程度
  • code quality
  • 有沒有學習到新東西

但整體來說,這件事情的目的是希望可以回答這個問題:有沒有什麼事情可以讓我們開發的更順利呢?

而有固定的頻率來做這件事,可以讓我們有機會在問題變成很難解決之前先發現它。 另外,常常我們在發現問題之後,並不一定可以立刻想到解決的辦法。 但是實驗可以讓我們一步步更靠近 :D

寫在後面

以上大概就是我們目前對於 “如何變得更厲害” 這件事情的看法跟作法。 對我們來說,要變得更厲害,第一步是要先能夠認知到自己還不夠厲害,並且相信自己和團隊能一起互相砥礪進步下去。 這當然不會是一件容易的事情,但我們相信如果我們打造一個可以犯錯的環境,設法存到犯錯的本錢, 在不斷嘗試下總是可以慢慢靠近。 如果有任何想法,歡迎來找我們聊天