Project 🚩談跨國專案中的軟體開發：我在 Yahoo 與樂天市場的經驗 (一)
筆者任職 Yahoo ，《軟體需求溝通 ─ 從外商公司學跨部門協作開發》線上課程講師，紛絲團《程式猿吃香蕉🍌》
『有些知識學校不會教你，而是需要從工作中一點一滴累積。』
跨國軟體開發就是這樣的事。
Hi 大家好，我是 Jayden ，我很幸運在外商待了很多年，遇到很多很好的前輩和主管，經年累月下來，教會了我很多事。這幾天寫完季度報告 (Q2)，我的團隊狀況算是很不錯，提早完成了許多目標，照例整理工作筆記，盤點自己團隊有哪些做得好與做不好的地方。
在整理筆記的過程中，我覺得如果這些知識能夠讓多年前的我就提早知道，可以少走很多冤枉路。因此決定寫這篇文章，作為經驗的總結，希望能幫助到有需要的人，也算是對我自己的心得回顧。
所以我決定撰寫系列文，分享跨國軟體開發在「準備期間」 、「執行期間」 、「日常準備」這三個時期的重要原則。與其他專案相比，跨國軟體開發多了時區與語言文化的隔閡，但我相信部分原則是有普世性的，同樣可以參考用於其他軟體開發專案。
▍準備期間
以下將會列出在專案開始前的準備期間所需要注意的重要原則。
1. 報表很重要 — 談「如何衡量產品的成功」
這是我剛進公司，第一次去矽谷出差時受到的震撼教育，當時我們剛完成一個案子，希望能夠向國外的團隊展現我們團隊的開發實力，以此得到更多專案機會，我洋洋灑灑地對美國 Manager 做完簡報後，卻被問到：
How do you measure the success of this product ?
他認為我提到的成功，都是技術上的成功，如果要證明在商業上有成功，應該要增加更多因子 (factor) 來衡量 (measure) 產品是否成功。在開發上，代表我們團隊其實還有很多工作需要做，例如：
🔖 目前的報表不足，需要設計更多報表類型，來檢視產品是否有達成商業目標。
🔖 產品頁面要加上更多追蹤(tracking) 來查看使用者行為，驗證商業成果。唯有如此，我們才算真正有能力「衡量 (measure) 產品是否成功」。
這次的震撼教育讓我明白，雖然美國團隊的產品開發速度很快，但對於報表的設計也是不含糊的，也讓我體認到敏捷開發精神所說的：
Validated learning over working software.
— Kent Beck
不愧是矽谷的團隊，他們的作法更是從「團隊配置」時就處理這個問題，在專案一開始便是同時配置有前端(Frontend)、後端(Backend)、以及報表 (Reporting) 團隊，如下圖範例：
在這樣的配置之下，對於軟體設計有以下好處：
✅ 可先規劃會有哪些資料要收集，設計資料的維度 (Dimension) 與指標 (Metrics)
✅ 可先規劃上游資料的預處理 (Preprocess) 或是聚合 (Aggregate)
✅ 可先規劃容量 (Capacity) 以及制定數據保留策略(Data Retention Policy)如此一來，在整體的系統設計和開發上會更加完善。從此之後，我做的專案都會將「報表」也納入重要考量，因為：
有了報表才有能力「衡量產品是否成功」 ，而有能力「衡量產品是否成功」的產品，才有機會做改善。
我認為這個思維很重要，並且在非跨國專案中也是適用的。雖然一般專案在人力配置上不一定有獨立的報表團隊，但將「如何衡量產品的成功？」這個問題和 PM 討論透徹，可以省下後續很多麻煩，例如：報表該收集的資料沒有收集，造成加班趕工補資料。
曾聽過朋友抱怨，國內有些公司做專案會習慣「先射箭，再畫靶」，做出「必定會成功」的產品。但涉及到跨國專案時，通常茲事體大，即使靶畫得太漂亮，也騙不過商業現實，因此，在準備期間最好還是先問清楚「如何衡量產品的成功？」才能做完善的系統設計。
2. 確認權限申請
你是否曾經聽過工程師報進度時說：「因為我沒有權限做 OOO，所以我沒有辦法完成 OOO」若是平時還可以，如果是在專案火燒眉毛的時候，真的是會急死人。
一個系統通常是由多個元件組成的，元件與元件之間要有「權限」才能互相溝通，就像牢房一樣，每個房間都門禁森嚴 (如上圖所示)，在系統開發的時候，工程師就像獄警，需要有各個房間的權限來能夠方便操作整座系統，或是進行除錯 (Debug)，以下為幾個在開發時常見的權限申請，可以參考列為清單：
✅ 測試主機讀寫權限
✅ 正式主機唯讀權限
✅ 日誌 (Log) 系統權限
✅ 測試資料庫讀寫權限
✅ 正式資料庫唯讀權限此外，若是有牽涉到大數據 (Big Data) 相關的專案，有關於 HDFS/ Hive /Hue/ Jupiter 等等權限，在專案正式開始前也需要先開通。如果身為 Tech Lead 帶團隊的話，更是要能從系統架構圖中事先洞察到這些權限的存在，在準備階段事先幫團隊成員都申請好，以節省時間。
以我自己的經驗來說，權限申請很容易有遺漏，因為通常跟你聯繫的窗口團隊，他們原本就有在系統的「房間們」自由行走的權限，每個房間都像自家廚房一樣，根本不會意識到漏給了你的團隊什麼權限。在專案時程的緊要關頭，才發現少了權限是很痛苦的，尤其在跨國專案中又有時區問題，申請後對方也不一定馬上回，一旦錯過了又會虛耗一天，要特別注意。
3. 技術棧 (Tech Stack) 確認
技術棧 (Tech Stack) 指的是這個專案使用到的技術，從程式語言、資料庫、到框架 (Framework) 等等都是，舉例來說，yahoo.com 這個網站有用到 JavaScript 這個程式語言製作，那麼 JavaScript 就是 yahoo.com 網站的技術棧之一。以樂高積木來譬喻 (如上圖)，技術棧 (Tech Stack) 就是指你的系統是用了哪些形狀的積木所堆疊起來的。
如果你好奇其他網站是用哪些技術棧做的，可以使用 Builtwith 這個線上工具查看，下圖是查看 yahoo.com 出來的結果，也就是說，如果你的新專案是要做 yahoo.com 這個網站，那你就會用到下圖中列出的技術，技術棧 (Tech Stack) 的內容都要在準備期間就做好確認，讓工程師可以提早準備。
以跨國專案來說，較有可能接觸到的是歷史悠久的系統，它們所使用的程式語言或框架通常不會是現在最流行的框架或做法，因此，在準備期間需要安排團隊事先研讀這些技術棧的組合。舉例來說，在前端框架 React 與 Angular 大行其道的今天，你可能還會遇到使用 Ember.js 開發的專案。
當然，與國外合作也是有機會遇到新的技術，以我自己的例子來說，我在樂天市場有機會在 React 剛出來的時候就使用在正式專案，在 Yahoo 也因為專案的關係，我們成為 Apache Druid 這項技術的早期使用者。
無論技術棧是新的還是舊的，在準備期間確認技術棧 (Tech Stack) 十分重要，因為事前把技術練熟，就像先把刀劍磨利一樣，可以確保團隊成員在上戰場前有萬全的準備。
4. 建立「統一且可搜尋」的「溝通群組」和「檔案群組」
以我的經驗來說，統一專案資料的存放地點非常重要。因為專案結束後可能會有許多「衍生品」，需要參照舊的資料來產出，例如：
(1) 技術分享會 (Tech Talk): 用於分享這次專案所使用的技術與做法，讓整個團隊更精進。
(2) 操作手冊 (Runbook): 用於記錄這次專案上線後的系統操作，例如：啟動/排查問題/關閉等等。
(3) 新功能的系統設計：新功能添加會需要參照舊的資料來產出系統設計，這時候變需要參考舊的文件，可以知道當初在設計上有做哪些決定，可能會成為系統限制。
而這些內容在開發過程中，可能會出現在即時訊息的討論、會議記錄、檔案分享，或是 email 往來中，因此專案開始的時候，我通常會建立共同即時通訊群組 (例如：Slack 或是 Skype 的群組)，以及 Email 群組，也會建立共用的檔案夾 (例如：共同 Wiki 頁面或是共用 Google Drive)。
注意！這些檔案的存放地點必須要是「可搜尋的」，以方便未來查找，我帶的專案都會採用這種模式，這樣的整理方式也讓我在交接專案時獲得不錯的恭維。我相信這是一個有價值且有效率的做法，尤其在跨國專案中，參與的人數眾多，統一「溝通群組」和「檔案群組」可以有效地幫助溝通。
▍小結
原本條列式的筆記內容，整理成文章竟不知不覺寫了那麼多 (笑) 。過程中為了更好地闡述這些原則，我加入了更多細節以及這幾年下來的思考，也算是很棒的體驗。當然跨國專案包含很多面向，這個系列文主要討論「軟體開發」的部分，分享的內容都是我實際上帶團隊用的方法。
我一直相信魔鬼藏在細節裡，沒有什麼抓大放小，而是點點滴滴做好每一件小事，才能把專案做好，以下總結我在準備期間一定要做的事：
- (1) 報表很重要：事先規劃，讓產品有能力愈做愈好
- (2) 確認權限申請：先申請好，專案少煩腦
- (3) 技術棧 (Tech Stack) 確認：讓工程師先做好準備再上戰場
- (4) 建立統一且可搜尋的「溝通群組」和「檔案群組」:讓溝通更順暢
下一篇是「執行期間」 與「日常準備」的重要原則 ，希望對大家會喜歡這些內容，當然最重要的是，希望能對大家工作上能有所助益。
—
最近受邀在 Hahow 開設《軟體需求溝通 ─ 從外商公司學跨部門協作開發》線上課程，談怎麼將將商業需求與技術規格對齊，並轉換成工程師可以實作的規格，目前七折優惠中，如果對課程有興趣的話，可以參考。
課程連結：https://hahow.in/cr/rqmt-intro
