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

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

前因後果是,我的前公司在美國的 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 跑分改善將近一倍。

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

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *