在台灣獨自一人，遠端帶領印度外包軟體公司

我之前在台灣工作時，曾有「在台灣獨自帶領印度外包軟體公司」的經驗，在做模擬面試時，才察覺這樣經驗似乎蠻少見，趕緊趁還沒忘光之前寫下來。

前因後果是，我的前公司在美國的 team 想要做一個全新的產品，是將現有的一個複雜網站，包裝成人人可用、簡單上手的新網站。所有後端的 API、資料庫都已存在了，唯有網頁的呈現（UI、UX）需要拉新的皮。當時公司裡沒有前端 team 可以支援，於是就找了一間在印度的軟體外包公司來幫忙，期待達到「小精靈在晚上工作，等到睡醒後功能就做好了」的理想。

我接觸這個產品時，網頁已經上線一陣子了。但是有蠻多小問題：外包商無法完美達到切版的需求（瀏覽器 resize 一下就破版）、修 A 壞 B、bug 來不及修、需求來不及做、時差問題、溝通不順暢等等。

也就是在 UI、UX 的部份，美國總部需要一個公司內的資深前端工程師進來盯，我的時區很適合（印度一大早=台灣中午=美國西岸傍晚。如果再加個以色列進來就慘了，一定有人要熬夜），又剛好有辦法挪出時間，所以就參與了這個專案。

我剛加入的時候懵懵懂懂，先跟美國負責後端的工程師拜個碼頭、參加 Daily sync up，接幾個 ticket 試試水溫，觀察一下程式、ownership 和大家的個性。

沒過幾個禮拜，某次三方 sync up 之前，先跟美國大老闆 1-on-1，
大老闆：「咻咻呀～你要不要 take over leadership？」
我：「喔…好呀我試試看」（心裡想著下週開始吧）
過十分鐘的 Daily sync up，大老闆：「即刻宣布，這個案子從此就給咻咻帶了歐」
我：「驚」

趕鴨子上架又有冒牌者症候群的我，很擔心自己是否能夠勝任，但過了幾週，我還是很明顯感受到：一個有經驗的工程師，即便是面對自己不太熟的技術架構或產品，還是能給團隊帶來價值。以下有幾點心得分享：

多時區的工作模式可能是蜜糖或毒藥

我從出社會以來，參與的所有專案幾乎都是跨時區，所以非常熟悉這樣的工作模式。
原本此專案的參與者是美國西岸與印度，雙方開會的時間是美國晚上、印度早上，所以美國開需求，印度當天開始做，如果印度做到一半有問題的話，沒辦法問美國（已經是美國半夜了），要等隔天才能問，一來一往就浪費了寶貴的開發時間。
在我加入之後，我變成雙方的窗口，我可以一大早起床跟美國西岸開會、釐清需求、事先推演技術問題，中午再轉達給印度。台灣對印度時差 2.5 小時，印度若有問題，我可以一路回答到印度下午三點半左右，也可以做 code review，效率和 code quality 都有改善！

跟外包公司的合作模式有所不同

有別於一般公司專案，跟外包公司的合作模式應該要有很明確的 spec 和日期，而不是試試這樣、試試那樣，如果一直 try and error，雙方都無法達到對方的期待：美國覺得印度做得慢，印度忙得像無頭蒼蠅，做得委屈、還不一定做得對。

從另一個角度來說，美國在開需求時，不會太去解釋後面的原因。由於是與外包商合作，有時是礙於敏感不想分享、有時是懶得解釋。印度在實作時，若因為時差求助無門又有時程壓力的話，就可能會加入自己的臆測去實作，一個沒盯緊就可能會走歪（寫錯）了。

我加入之後，即便對 Framework 還不熟，我依然能用我的經驗判斷輕重緩急，提案先做哪些事情，或是擋掉一些事情，讓印度團隊可以比較有方向地做事，整體的進度也不會比原先慢。

態度決定很多事情

印度團隊有三個人，就算從未見到彼此，從電話會議中也很明顯感受到，A 和 B 是來討口飯吃、C 對程式和專案比較有熱情。
在職場打滾久了，漸漸體會到，人們的工作動機本來就各式各樣，討口飯吃或是盡力做事，只要事情有做完，都是可以的。
但是人對工作的主動態度，也會間接影響到他人對你的態度。
我是屬於看到別人有心想學，就會盡力給予的類型。我感受到 C 的有心，所以閒暇之餘，也會跟他多講幾句怎麼寫比較好，稍微在 Technical 上帶他一下。
照理說由於跟外包公司的契約關係會持續多久並不知道，又不是自己公司的「自己人」，對他們不用那麼「好」。是 C 的人格特質和工作態度，讓我願意稍微多幫他一點忙。

以下是偏前端技術面的感想：

選 Framework 絕非用最潮的就好

選 Framework 、 Library 這事，要看團隊組成和產品特徵，只看當下流行什麼、或工程師自己想寫什麼就選什麼，是有點危險又不太負責任的。在我加入之前，團隊已選定用 Angular 開發。
雖然現在前端世界最流行 React，但我帶了一陣子的感想是「不用 React 的確比較好」。原因是，此開發團隊原本是寫後端居多，對前端經驗不足，整個案子又是產出導向。
選 React 意味著，要自行決定要用哪套 SSR、state management、CSS solution 等等。沒什麼經驗的 team，不一定選得出來，還可能糾結於：做到一半覺得選得不好打掉重練、或是看到華麗新玩意兒也打掉重練的惡性循環。
相較之下，Angular 是一個完整的 framework，DI、template、cache、testing、i13n、A13y、SSR 等等、團隊想得到和想不到的都先考慮好了。
對於一開始是從 Client side 、UI rendering 角度學習的前端工程師來說，Angular 許多概念的確是比較難的。相反地，對後端工程師來說，文件讀一讀就可以開始寫 Angular 了，不用花太多時間去嘗試各種前端華麗的 solution。所以以這個團隊來說，選 Angular 更優於 React。

Logging、CI/CD 是必要的基本功

在我加入前，有個問題是「有 bug 卻無法重現」。常常美國發 bug，當下沒有送 logs 記錄下來到底發生了什麼事情，印度憑 bug description 又無法重現，就無法修復、浪費時間。
我加入之後，發現這件事情越早做越好，於是花了幾天的時間，統整了一個 logger，做了做 Dashboard、把 logs 串接到 Slack，事後溝通就順暢一些。有 logs 也能知道哪樣子的 bug 的出現頻率比較高，也便於決定優先順序。
CI/CD 則是原本就有個陽春版，但也沒什麼測試和優化，我就整了 unit test 和 asset publish 進 pipeline，瞬間把 Google PageSpeed 跑分改善將近一倍。

以上就是我帶印度外包商的經驗。短短幾個月，學到蠻多東西，最深的體認應該是：溝通順了一切就順了。很多時候，寫程式本身並不是最困難或最關鍵的。但是這些體認，也都要自己親身經歷過了才知道…