Project 🚩談跨國專案中的軟體開發:我在 Yahoo 與樂天市場的經驗 (二)

Jayden Lin
Jul 12 · 12 min read

筆者任職於 Yahoo ,粉絲團:《程式猿吃香蕉🍌》

(圖片來源:https://global.rakuten.com/corp/sustainability/employees/diversity/)

Hi 大家好,我是 Jayden ,前一篇文章,提到了我寫這個系列文的由來,也說明了在跨國軟體開發中,「準備期間」有哪些重要原則必須留意,如果有興趣的話,可以先從第一篇開始閱讀:

本篇將討論在跨國軟體開發中「執行期間」以及「日常準備」中有什麼眉眉角角,當然,我相信部分原則是有普世性的,同樣可以參考用於其他軟體開發專案,一起來看看吧!

▍執行期間

以下將列出在專案正式開始後,「執行期間」有哪些重要原則。

1. 例會 (Regular Meeting) 雖討厭,但很有用

(例會示意圖)

我知道許多人不喜歡開會,會覺得被打擾,尤其在跨國開發中有時區因素,與國外的開會時間可能會特別的早 (如上圖所示) 。

但在跨國開發中,我認為例會 (Regular Meeting) 是非常重要的,甚至在專案初期,我會安排做到每日會議 (Daily Meeting) 的程度,每天花 15–20 分鐘與國外團隊確認進度,等到進度穩定下來才會改為兩天一次或是一週一次的會議。

在語言與文化隔閡的情況之下,甚至工作模式 (Working Model) 都還未彼此熟悉時,就貿然取消與國外團隊的例會是很危險的,你尚且都很難做到在「不溝通」的情況下讀懂男/女朋友的心,更何況是國外的團隊。沒有例會溝通的團隊就像「背對背擁抱」(如下圖),各做各的任務,不知道彼此的心意 ,最終可能會導致產品難以整合。

(示意圖:團隊各做各的任務)

如果真的很討厭開會,可以跟國外團隊商定 Office Hour 的時間,有遇到問題時可以馬上問得到人,這些都是我在實務上做過的方式,提供給大家參考。

2. 從「共同設計」建立信任感

(示意圖:團隊需要建立信任)

團隊合作需要以「信任」為基礎,跨國軟體開發當然也是。在專案執行期間,我們交付的是程式碼,建立信任感會有助於我們交付任務。尤其,跨國專案通常是較有規模的開發方式,程式碼提交 (Pull Request) 需要嚴格把關。根據實際專案情況,一個程式碼提交,來來回回修改長達一兩週都是有可能的。

用譬喻的方式來談「信任感」,以學校教授批改論文為例,你覺得教授會喜歡最後關頭才一口氣交論文上來的學生?還是在過程中跟教授有許多討論,在教授眼皮底下一點一滴寫,最後完成論文的學生?我相信大部分的人會選擇後者,我也相信以論文批改的順利程度,也是後者會比較順利,因為信任感。

跨國專案也是一樣的道理,我自己在信任感問題的處理方式為「共同設計」:意即讓國外團隊預先知道你想要怎麼做(How),甚至一起參與設計,以下為一些實際的作法:

✅ 牽涉較大的設計,預先給架構師審核背書,審核會議盡量邀請對方團隊一起參與。
✅ 牽涉較小的設計,讓程式碼審核的核心成員預先知道你的作法。
✅ 透過即時訊息、例會和 Office Hour 讓對方團隊知道你下一步要做什麼。

等待信任感建立後,那麼你的團隊在被審核程式碼時就會快速許多,整個開發速度就能快起來了。

3. 實作前先確認「可測試性 (Testability)」

(示意圖:工程師動手執行任務)

任務不是用「聽」的,是要動手「做」的。

想像一下,你與國外團隊確認完需求和架構、回到電腦前開啟程式編輯器準備動工,此時才發現程式啟動後跳出很多錯誤訊息,有好多設定的細節要確認。這是很常見的情況,因為任務從「聽懂」到實際「動手做」,還有大一段距離。要記得,真正上手(Hands on)實作的人,是你與你的團隊,所以不會有別人主動幫你補上其中的差距,所有細節都要自己確認。

就像上料理教室一樣, 老師教完廚具使用與操作步驟後,還要學生自己實際操作,才會知道各種「小細節」,那麽問題來了,細節那麼多,到底要確認多少小細節?

依我的經驗,我會擒賊先擒王,從「結果」來回推我要確認的細節,以料理教室的例子來說,當你要用炒鍋,你需要回頭先確認使用炒鍋的細節,回到開發的例子,程式碼交付後需要做「測試」,開發前我會需要先確認要怎麼做「測試」的細節,因此我會以「可測試性」為原則,來檢視開發項目,有以下主要幾點:

(1) 可控制性 (Controllability) : 我能不能控制開發對象的執行階段?以下為範例:

✅ 嘗試執行除錯模式 (Debug Mode),以中斷點(Break Point)控制執行階段
✅ 嘗試執行端到端(E2E)操作,來控制執行步驟,例如:從介面操作某個功能看執行狀況
✅ 確認程式碼的進入點以及最後輸出,並實際執行和確認每個執行階段
(程式中斷點 Break Point 示意圖)

(2) 可觀察性 (Observability): 我能不能觀察到開發對象的執行結果?以下為範例:

✅ 確認日誌 (Log) 怎麼看,例如:Splunk 的常用搜尋條件、日誌資料夾位置
✅ 確認日誌 (Log) 的層級調整怎麼做?可以調整日誌呈現的精細度
✅ 確認日誌 (Log) 在不同請求 (Request) 或是不同執行緒 (Thread) 的執行結果

(3) 可隔離性 (Isolateability): 我能不能把開發對象從其他系統元件中隔離出來?以下為範例:

✅ 如何模擬(Mock)依賴的服務?例如:模擬Amazon S3服務,讓它從開發對象中隔離出去
✅ 嘗試執行開發對象的單元測試(Unit Test),確認開發對象與其他元件可以隔離

雖然根據專案複雜度,要確認的細節很多,但只要把握重要原則,優先確認你的開發對像是可控制 (Controllability)、可觀察 (Observability)、可隔離 (Isolateability)的,在真正動工時,就可以減少很多問題。

有一點要特別注意,這些內容並不是「一次性」的工作,而是在每次開發的週期 (Iteration) 都需要提醒自己做,因為每次接觸的開發對象不一定相同,上次的設定檔不一定適用這一次的任務。跨國專案的溝通因為時區的關係,一旦今天沒有問到答案,只能明天請早,所以儘早花個一個小時的時間把東西都先自行確認完,以「清單」的方式在和國外團隊開會時一口氣把答案都取得,可以減少很多溝通成本。這項原則非常實用,我相信不僅僅可以用在跨國專案,在一般的軟體專案也是同樣適用。

4. 追劇心態:幫助你提早知道更多事情

執行專案就像演一部熱血長劇,不要錯過這齣劇周圍發生的支線劇情,因為支線劇情可能會影響你目前的主線劇情。

(示意圖:即時通訊群組)

舉例來說,除了專案本身的即時通訊群組之外,還可以加入國外團隊他們自己的即時通訊群組 (如上圖所示),把自己當成劇迷,用追劇心態看他們團隊發生的事情,並且注意他們發生的事情會不會影響到你的專案,例如,你可能會看到以下的討論:

😭 同事:最新版的程式碼有問題,要先把OO改掉才能執行OO
😭 同事:某個外部服務現在掛了,目前端到端(E2E)測試都會壞掉
😭 同事:目前有一台測試機的程式是舊的,你測試時可能會遇到問題

這些看似雞毛蒜皮的小事,對方不一定會主動通知你,但因為你有「追劇」,你就可以提早提醒團隊成員,目前有哪些東西本來就壞了,如果你今天遇到某些程式錯誤,不是你的錯。當然,除了負面的消息,你也可能看到以下的討論,知道一些正面的消息:

😆 同事:我建議程式啟動時可以做OO設定,排除掉OO模組,本機啟動速度會更快
😆 同事:我發現公司有買OO的軟體,大家可以去申請

除了加入合作團隊的即時通訊群組之外,「追劇」的來源還有以下幾種可以參考:

✅ 程式碼提交清單,例如:Github 的提交頁面,可以知道目前有哪些功能在做/或是在修
✅ 周邊服務團隊的群組,例如:金流服務的團隊的群組

依我自己的經驗,因為有了「追劇」的心態,可以提早知道很多事情,做出更好的安排。魔鬼藏在細節裡,在跨國專案中,人員眾多且規模較大,更是要主動出擊,主動地去接收周遭發生的事情,才不會在事件發生時措手不及。

▍日常準備

如果說「準備期間」 、「執行期間」為專案的戰鬥時期,那麼「日常準備」就是每天都要注意的事情,因為我們要在日常就做好準備,等到專案的戰鬥時期才能得心應手,以下說明在跨國專案中的日常準備,要注意哪些原則:

1. 見面三分情

跨國專案的執行,團隊間通常見不到幾次面,更多時候你之於對方團隊而言,可能只是一張冰冷冷的頭像照片,或是一串慘白的電子郵件名稱。

但我相信「人」都是有感情的,「見面三分情」這也是主管在我們執行跨國專案時最常叮嚀大家的話。一開始我也不太相信,覺得「見個面真的有差嗎?」但不得不說,幾年下來的親身體驗,真的覺得見面非常有用。以科學的方式來說,人腦處理「物化」的事務跟「人格化」的事務很不相同,見了面可以幫助對方更能把你人格化當作成一個人,進而產生同理心,也更容易達成夥伴關係。

以下分享幾個可以增加見面機會的方法:

(1) 技術分享會 (Tech Talk)

在外商,主管們都非常鼓勵我們參與技術分享會,向國外團隊展示我們的成果。除了技術能夠精進之外,也可以跟國外的夥伴們有更深層交流的機會。這類的分享會有大有小,有每周辦一次的、每個月辦一次的、也有一年一度全公司級別的技術研討會(如下圖所示)。我建議可以鼓起勇氣從小的分享會開始報名,增加與國外團隊交流的機會。

(Yahoo Tech Pulse 2012 資料照片之一)
(Yahoo Tech Pulse 2012 資料照片之二)

(2) 出差

當然,最直接的見面方式就是出差了,無論是出差討論下一季的計畫,或是直接與國外的團隊一起工作幾個月來確認工作模式 (Working Model),都是很好的辦法。

(3) 視訊會議

(遠端會議示意圖)

現在因為疫情的關係,沒有辦法出差,只能透過遠端會議 (如上圖所示) 的方式來討論專案,我發現美國同事與印度同事通常都會很大方地開啟視訊,可以有效地幫助溝通,因此,我認為開啟視訊與對方溝通也是幫助消弭隔閡的一種方式。

2. 展現你的想法

可能傳統的教育讓我們比較「溫良恭儉讓」也比較「逆來順受」,但面對跨國專案的時候,尤其是面對西方文化,需要勇敢地表現自己的想法。

想像一下,如果你只是被動地接受軟體需求,規格開什麼就做什麼,那麼其實你的團隊是很容易被取代的。如果你有能力指出對方的設計錯誤,看到對方法沒有發現的事情,那麼你的團隊才會更有價值。幾年下來,經歷了許多跨國專案開發,我完全不覺得國內團隊的技術能力會比國外團隊差,欠缺的反而是「適時表達想法」的能力,我們需要在日常時期就做好這一點,讓對方團隊有印象並有信任感,在後續的合作上也能更加順利。

之後我會再撰寫一篇文章分享「與外國同事開會常用的句型」,敬請期待 😀😀😀

▍小結

總算將過去幾年的筆記內容完整地記錄下來 (笑)。當然,跨國專案包含很多面向,這個系列文主要討論「軟體開發」的部分,分享的內容都是我實際上帶團隊用的方法。以下總結這篇的內容:

♦ 「執行期間」的重要原則

  • (1) 例會雖討厭,但很有用
  • (2) 從「共同設計」建立信任感
  • (3) 實作前先確認「可測試性 (Testability)」
  • (4) 追劇心態:幫助你提早知道更多事情

♦ 「日常準備」的重要原則

  • (1) 見面三分情:讓對方產生同理心也更容易達成夥伴關係
  • (2) 展現你的想法:讓對方團隊有印象並有信任感

▍寫在最後

撰寫這個系列文的同時,也回顧了自己的職涯,其實感受滿特別的,覺得自己真的非常幸運,在外商這幾年遇到很多很棒的前輩與主管,我並不是一個特別聰明的人,還好一路上有貴人相伴,同事也好、主管也好,都是一生的福份。也謝謝老天爺讓我遇見這些美麗的靈魂,讓我得以完成許多美麗的事。

希望大家會喜歡這些內容,也希望透過我的一點努力,能讓這些經驗幫助到所有需要的人。

若是喜歡我分享的內容,歡迎幫我按個拍手,可拍 50下,給我一點鼓勵,或是加入我的粉絲團《程式猿吃香蕉🍌》,一起分享軟體知識與心得!

程式猿吃香蕉

喜歡將軟體知識以簡單生動的方式講給你聽

程式猿吃香蕉

『來點更營養的軟體知識,吃香蕉吧!』我們是一群軟體開發愛好者,喜歡將軟體知識以簡單生動的方式講給你聽,順口好消化,營養又健康!

Jayden Lin

Written by

Yahoo 擔任 Lead Engineer,負責廣告系統,帶團隊做跨國開發。也是《程式猿吃香蕉》團隊創辦人,喜歡將實用的軟體知識以簡單生動的方式講給大家聽 😄😄😄

程式猿吃香蕉

『來點更營養的軟體知識,吃香蕉吧!』我們是一群軟體開發愛好者,喜歡將軟體知識以簡單生動的方式講給你聽,順口好消化,營養又健康!