上一篇 Sam 分享他如何從新聞系轉職成網路開發者。在這篇，我們會討論以下如何打造團隊，以及 microservices 與辦公室政治的關聯。

—
Bernard：那我們來談一下你建立團隊的經驗。在上一份工作，你是從零打造一個工程團隊，後來團隊有多少人啊？

Sam：在台灣這邊大概六十出頭。

Bernard：這應該是個滿有趣的經驗。可以講一下這個過程嗎？比如說你第一個 team member 是怎麼找的？然後怎麼把團隊建立起來的？

也先說，很感謝 Sam，過去錄取了不少 ALPHA Camp 的學員。我們學生在你那邊學到很多。

所以請你分享一下，在不同階段，如何建立、如何管理團隊的？我覺得第一至五個是最難的，過三、四十的話，後面也很難，所以團隊是怎麼發展的？

Sam：我覺得 Bernard 講到一個關鍵，就是在不同的規模、不同的 timeline 下，你管理團隊的方式是不一樣的。一開始我們小團隊的時候找人，我們是靠關係、靠朋友介紹。「我們這麼熟，你要不要來幫我一下？」就這樣。那時候團隊的士氣 (morale) 是非常非常高的。你在維繫團隊，你也會跟他們打成一片。這時候團隊的向心力，取決於你跟團隊成員的信任度。

Bernard：沒錯。其實一個團隊的初步階段，信任是非常重要的。

Sam：因為如果你今天是 hire 一個你完全不認識的人進來，一定需要跟他磨合。你需要花心思、花時間去了解他。可是當初我們的任務是把 team build 起來，在一個月之內，launch 一個新的 service。這是一個非常困難的任務。

其實現在回想起來，我還是覺得有點不可思議，可是我們真的做到了。起初的五個，我記得好像只有一個是透過朋友介紹，有跟我真正面試進來的。其他都是我的朋友，或是甚至是以前我有 interview
過，私底下有聯絡的社群朋友。一開始的草創的時期，我還記得那時候辦公室很小，大家擠在一個狹小、擁擠的空間，可是感情是最好的，我也過的蠻開心，之前 ALPHA Camp 的一些成員，也是那個時候加入。

在那個時候，我在評估成員的 quality 的時候或是他們的能力時，我比較在乎的是這個人跟我是不是 match，能否快速建立默契。如果他/她跟我平常相處、對話，或是溝通事情上面，我都需要花時間去讓對方理解，那我覺得他/她不是適合一開始的這個小團隊。因為小團隊最沒有的就是時間。速度要快，我只要起一個頭，你就可以幫我把尾巴接完。這種默契是非常重要的。

小團隊最沒有的就是時間。速度要快，我只要起一個頭，你就可以幫我把尾巴接完。這種默契是非常重要的。

Bernard：嗯。我在過去創辦過兩家公司時，也有類似的領悟。那後來呢？團隊到了中期時，有什麼改變？

Sam：後來一直擴展到中期二、三十個，然後再三、四十個人，每個階段都會遇到不同的問題。但是我覺得有一個比較大的中心思想是：小團隊有小團隊做法，大團隊有大團隊的模式。比如說小團隊你可能向心力高、士氣高，但是等到你變成大團隊的時候，process 就變得很重要。你不能說一個 team 去 follow 一種 coding standard ，另一個 team 就 follow 另一種。這樣的開放是沒有辦法銜接的。在團隊協作上也會造成很大的溝通障礙。這是後要注意的是如何把 process run 順。你說要跑 scrum，每團隊對 scrum 的理解與定義都可能不一樣。

你怎麼去取得共識，align 不同的團隊？你怎麼讓大家可以利用你的 process，去很順暢做事，而不是拘泥 process 上面？其實後來，這些 process 都讓我覺得工作很困難。

Bernard：我先多問一些細節。你們在台灣有幾十位工程師，但是你們在亞洲四個國家也有工程團隊？可以大概講一下，組織架構是什麼嗎？團隊又是如何分工的？是「臺灣做後端，新加坡做前端」的這種？還是從產品線、或是客戶端來分？

Sam：基本上，我們四個團隊，它們的分工與 functionality 是不同的。有一個重點是，每一個國家的團隊都可以完整地運作。所以不是台灣只做前端、或是新加坡只做後端。No! That’s not gonna work。因為這樣溝通成本太高了。我們現在的區分是，台灣全部是做消費者相關的產品，而新加坡是做所有跟物流有關的功能，包括我們的 data team 也在新加坡。物流包括些什麼呢？我們如何去演算，用最短距離去配送，我們怎麼做倉儲的控管等等。印度的團隊主要是輔助企業客戶做 data handling，幫助大的企業客戶上架。最後，越南就是做所有跟 payment 有關的功能。我們自家蓋了一個錢包，有自己的 payment gateway。這些都是越南的團隊負責。

所以你可以很清楚看到，四個國家有負責自己不同的 functionality。其實這個概念有點像業界近幾年在講的 microservices 架構。

Bernard：哦？所以你們也是以 microservices 的模式來開發、來管理的？

Sam：為什麼我們要做 microservices 呢？其實我覺得 microservices 不是一個萬靈藥，可是 microservice 可以確切解決一個很麻煩的問題，就是「政治 (politics)」。

其實我覺得 microservices 不是一個萬靈藥，可是 microservice 可以確切解決一個很麻煩的問題，就是「政治 (politics)」

Bernard：怎麼說？

Sam：假設今天三個 team ，他們都用同一個 code base，然後他們都要發佈新的版本 (release)，你覺得 release 的步驟給如何管理？可能 A team 我下個禮拜要的東西，可是 B team 你還要再做兩個禮拜，那我就被卡住了！

但 microservice 就可以分批應付不同的 release，讓整個流程更快、更有效率。也就是說，其實我們做 microservice 最重要的其一個原因，是讓每一個「小隊 (squad)」可以更有效率，更完整的去執行它的 squad 的精神與任務，快速迭代。

Bernard：瞭解。聽說你們也慢慢在離開 Ruby-on-Rails 這個框架。這也是跟 microservices 有關的嗎？

Sam：我們一開始主要 backend framework 跟 code structure 都是 Ruby-on-Rails。其實我們 Rails codebase 積近非常巨大。達數十萬行的 Rails codebase。但就像我剛剛提到的，每一個 team 他們維護同一套 codebase 的時候，發生了很多的問題。比如說以前發生過一個 pull request review 花了七到十二天，因為那個變動實作是太大、太多 PR 了，團隊裡沒有人有時間去看。

所以我們在去年年初時，慢慢導入 Golang。導入 Golang 的目的，第一個是希望去提升效能，第二個是希望朝向 microservice 的方向前進，讓所有的小隊 (squad) 可以獨立的運行。

現在我們的模式變得越來越流暢。我們會去評量每個 sprint 結束時，小隊是不是可以完成這個功能，能否做個簡單的 demo。

以前發生過一個 pull request review 花了七到十二天，因為那個變動實作是太大、太多 PR 了，團隊裡沒有人有時間去看。

Bernard：所以聽起來，每個小隊都是 full-stack，都有自己的 KPI。而 microservices 也會把他們開發的技術分開，不會造成很嚴重的 dependency，而造成互相依賴、互相卡關的狀況。這樣就算是幾百人的開發團隊，速度都可以維持的很快。