前言
嗨，大家好，我是 Hank，很高興這次有機會可以代表 LINE 台灣 QA Team 來跟各位分享一些在 LINE GIFTSHOP 中的跨國團隊合作心法。以下就讓我透過文章的方式和大家分享當天 Test Corner 的內容吧！
此次簡報： https://speakerdeck.com/line_developers_tw/cross-countries-mindset-for-testing-proect
活動影片：
介紹
LINE 禮物(LINE GIFTSHOP) Introduction
LINE GIFTSHOP 是一個替您傳達完整心意的服務，絕對是個稱職的送禮小幫手。在朋友生日的前一刻，提醒您記得為好友準備一份小禮物，除了生日提醒以外，還能夠做 7 天前的送禮預約，讓您的心意準時的送到好友手上。
若您對於應該送好友什麼禮物沒有頭緒的話，也能夠透過服務提供的各項查找功能 (禮物分類、禮物篩選、送禮排行、禮物品牌、禮物搜尋) 或是查看好友公開的願望清單品項給你一些靈感，讓您的禮物能夠送進好友的心坎裡。
禮物挑好後，也不需要知道好友確切的收件地址，只要用心地把送禮小卡上面寫上你滿滿的祝福，就能夠將禮物送到好友的禮物盒裡面囉～ 是不是非常方便呢！
Team Map
GIFTSHOP 團隊是由主要兩大區域的團隊來合作，分別是
- 韓國的 Dev team 也就是開發團隊，其中包含了企劃，設計，開發以及測試團隊
- 台灣這邊則是主掌台灣區市場的業務團隊，其中包含 Biz，設計，客服以及行銷團隊。
在前年以前的禮物是由這兩大團隊中的台灣 Biz 和韓國的企劃團隊直接對口運行專案，不過其中就產生了以下痛點
- Biz 的同事們無法專心處理業務，替公司衝業績，必須要撥一些人手來執行專案管理運作相關的事物，以便能夠順利和韓國企劃團隊溝通。
- 韓國企劃團隊為了讓這樣的合作模式順暢，必須招募定量懂韓文和中文的人力來應付雙方頻繁大量的溝通。因為業務繁多，在沒有單一窗口，懂韓中雙語的人力又有限的情況下，這些雙語同事的 loading 無形加重。
- 一旦遭遇問題時，韓國開發團隊直接對上台灣 Biz 團隊，或是其他團隊時，開發團隊必須自行主導議題追蹤，分析，回應等動作，這讓開發團隊花非常多的時間和這些團隊溝通，甚至應對問題之外所延伸出來的議題。
- 承上，讓開發團隊溝通非常吃力的主因還有其二，通常業務或其他非技術性質的團隊並沒有技術相關的知識背景，使得韓國開發團隊給了台灣團隊一些答復後，台灣團隊無法第一時間理解其中的意思。無論是直接對口台灣業務團隊，或是請韓國企劃團隊從中協助溝通，開發團隊都必須花超量的時間去簡化整理回應，才能夠讓其他團隊理解。
於是在去年台灣端為了協助 Biz 團隊能夠順利把人力抽回專心處理本業，替 GIFTSHOP 創造亮眼的營收，又希望能夠協助雙方團隊營運順暢，將台灣區的 FAS 和 QA 團隊編制到禮物服務中。希望如上圖所示，藉由這兩個團隊居中協調運作下，來解決前面提到的痛點。
Mission
LINE GIFTSHOP 台灣 QA 團隊的日常任務分別如下
Knack of Cross-country Project
核心理念
讓所有團隊成員隨時 "on the same page"
思考心法
- 權責清楚，建立流程
- 明確定義每個團隊的職掌與責任，並且羅列所有專案會處理到的事項，針對每個事項邀請相關的團隊進行討論，將其中的處理流程規劃出來，規劃重點須符合 "簡單直覺" 的重點，簡單讓大家容易理解記憶，直覺則是符合大家的本能反應。一旦規劃完成後，就需要把規劃出來的流程透過文件方式記錄下來，方便日後流程檢視優化，以及當團隊中有新的成員加入時，能夠有文件可以參考熟悉。如此一來，整體團隊無論在處理任何事項上，大家總能朝同一方向前進。
- 4W1H 資訊處理邏輯
- 簡單透過英文問句的 4W1H 下去確認每當接收和處理資訊時，應該要思考顧慮的層面，說明如下
- 接收資訊
- 每則訊息其背後應當都會有，是誰發出/訊息裡面提到哪些人 (Who)
- 訊息的來龍去脈 (How)
- 什麼時間點發生 (When)
- 在哪邊發生 (Where)
- 這個訊息背後真正的目的是什麼 (What)
- 一旦你搞清楚訊息內容後，再來就是要開始處理資訊
- 所以誰或是哪個團隊可以協助你處理這件事 (Who)
- 處理這件事涉及到哪些部位 (Where)
- 如何處理比較有效率 (How)
- 要完成這件事有哪些代辦事項 (What)
- 最後應該要在什麼時間點以前把這件事完成 (When)
實戰手法
Information IN
- 分門別類，直搗黃龍 (聽)
- 把專案內的溝通頻道依照不同目的類別進行分類，如此可以把不相關的人士剔除，省去無關人等不斷接收到訊息，導致訊息疲勞。透過不同目的的頻道也可以快速順利的將議題迅速導入正確的流程中，配合 Tag 正確的團隊或窗口，讓下位接棒者能夠快速接棒處理。
- 來自元宇宙的神隊友 (聽)
- 把通訊平台提供的附加功能發揮出來，以 Slack 為例，透過整合 CI/CD 中的每個重要節點，讓 Bot 將各節點傳回相應頻道，如此相關人員就能夠輕鬆了解事項進度。另外也可以透過 Workflow 的功能和 JIRA 的串接，只要是通過審核在該頻道的團隊同仁，都不需要費事去申請 JIRA 的權限，只要透過頻道提供的 Workflow 就可以輕鬆的依照訂定的流程表單，把 Issue 開進 JIRA 管理系統中。
- 避免聞道有先後，統一揭露 (聽)
- 為了避免各團隊有資訊落差的狀況，建立共編文件以及 Dashboard 看板都是不可獲缺的。透過權限管理讓各窗口統一彙整資訊到同一文件上，才能有效讓大家即刻處於資訊同步的狀態上。另外，將團隊所需的相關數據，專案進度，透過 Dashboard 看板同步揭露給大家。
- 術業有專攻，外文看得懂 (讀)
- 不要只使用單一翻譯平台，應該要針對合作的國外團隊所使用的語言，找到專門翻譯該語言的翻譯工具。這邊以韓文舉例(如下)，透過 Google 翻譯和韓國 PAPAGO 翻譯平台的比較，了解使用專業精準翻譯平台的重要性喔！
Information OUT
- 九彎十八拐，反客為主 (說)
- 跨國團隊合作基本上都是透過文字在進行溝通，如此就會缺乏語氣情緒的傳達，反之接收訊息的對方很容易會帶入當下自己的情緒去解讀你的文字。為了避免這樣的情況發生，各位在使用英文表述時，請注意以下幾點
- 選擇適當主詞，避開質問語氣，將 You/Your 換成 We/our ，能夠讓對方避開被當面質問的感覺
- 修飾問句開頭，例如將 What ... 調整為 May I/we know ... 或是 I/We would like to know ...
- 配合各種禮貌用語軟化句子，例如: 早午晚安，Hi/Hello，請，對不起，謝謝，抱歉打擾 ...
- 善用適當的 Emoji 來彰顯自己的語氣態度 (如下)
- 跨國團隊合作基本上都是透過文字在進行溝通，如此就會缺乏語氣情緒的傳達，反之接收訊息的對方很容易會帶入當下自己的情緒去解讀你的文字。為了避免這樣的情況發生，各位在使用英文表述時，請注意以下幾點
- 時間寶貴，神機妙算 (說)
- 表達提問的時候，內容格式務必清楚明瞭，一次把所有問題羅列，節省 Dev 團隊中斷開發的次數，例如
- 透過經驗法則，搜集相關單位總是關心的議題來訂定問題走向，例如每當有問題產生後，業務團隊最關心的事項不外乎以下五點。因此，我們可以預先針對這些事項羅列相關問題點，一次向 Dev 團隊發出請求。
- 影響時間時長
- 影響範圍 (用戶數，訂單類型，頁面 ... 等)
- Root cause
- Solution
- 改進預防措施
- 公私併濟，釜底抽薪 (說)
- 通常我們討論事項都是透過公頻道來和各方團隊成員進行討論回報，有時候一件事要順利圓滿的解決，不是單單僅靠一個單位的努力回應就能夠完整，很多時候是要相關單位都要反饋結論意見後，才能把問題順利收尾。這時候你就需要與相關窗口方向一致，若窗口間在同一戰線上，問題將不斷發散，如此就會沒完沒了。一旦這樣的情形發生了，就需要事先啟動私頻道的對焦，先在雙方取得共識後，再轉到公頻道討論，如此事情才能順利往正確的方向前進。
- 切記！請小心研判情勢，除了上述情形外，專案的討論務必都在公頻道進行，若習慣事事都想私下解決，很多時候會引發反效果，導致一件事明明在公頻道輕鬆可以討論解決的，因為私下不對稱的討論，反而無法收斂，節奏大亂。
- 留下美味麵包屑 (寫)
- 請仔細留下記錄，其中務必完整關聯所有相關的討論串 (Slack thread Link, Screenshot of chatroom...)，JIRA No.，郵件，文件位置 ... 等資訊。以便在溯及既往的過程中，有足夠的資訊讓大家能夠拼湊還原出事情原貌，才能有效的以古鑑今。
- 鉅細彌遺，條列分明 (寫)
- 既然都想留下線索了，就鉅細彌遺，清楚明瞭的呈現你的紀錄吧！避免你以為的麵包屑，在別人的眼中是石頭。因此，當你完成文件後，可以分享給大家看看，並嘗試取得反饋，才能讓這些線索能夠更有效地留存下來。
- 圖文並茂，賞心悅目 (寫)
- 如何讓麵包屑變得更美味呢？就是除了文字以外，還有圖片或影片的調味，讓讀取線索的人能夠更清晰的了解事件原貌，以及紀錄者的原意。
Q&A
在這次活動中有朋友詢問以下的問題，在這分享給大家
Q1: 請問是否和 Dev 團隊相處不和睦，導致 Dev 團隊抱怨 QA 團隊問太多問題浪費 Dev 寶貴的開發時間
A: 首先我們團隊希望大家只要有困擾，都能夠積極主動地提出，讓大家一起面對問題，一起思考解決問題。而例子中提到 Dev 團隊主要痛點是 QA 團隊在追蹤問題的過程中，提出問題查找的時段太過分散，變相成為打擾 Dev 團隊次數太多的情形。因此，QA 團隊在了解到 Dev 團隊的痛點後，討論歸納出相應的解決辦法，透過以往的經驗，在每次的提問中都嘗試精闢完整的提出關鍵必要的問題，如此有效降低問題發散的機會，以及打擾 Dev 團隊的次數，進而保持 Dev 團隊順暢的開發節奏。
Q2: 請問線上回報的問題如果 QA 這邊無法重現的時候，應會如何處理？
A: 盡量將完整的用戶資訊，用戶環境，操作行為細節，發生的時間點 (年月日時分秒)，完整紀錄。並先將問題提報到 KR QA 團隊去做初步分析確認，借重 KR QA 的經驗確認雙邊 QA 都無法重現問題後，再將完整的資訊(包含說明 QA 端無法重驗該問題的資訊)，問題以及希望 Dev 處理的 action item 一併提給 Dev 團隊讓他們能夠一次理解要準備回應處理的項目，如此呼應到上述分享中的 "時間寶貴，神機妙算" 手法減少干擾 Dev 團隊的次數和時間。
結論
在這次 Test Corner 中很高興可以分享在 LINE 台灣工作中的一些經驗，希望透過這些經驗分享可以讓各位可以了解一些在 LINE 裡面專案處理上的手法以及細節，讓這些內容可以實質幫助到各位工作上的內容，一同在 QA 的領域中進步。非常慶幸有機會可以在社群分享，那我們就下次社群見啦！
最後，如果對於加入 LINE 大家庭有興趣的各位，歡迎參考以下：
活動小結
立即加入「LINE 開發者官方社群」官方帳號，就能收到第一手 Meetup 活動，或與開發者計畫有關的最新消息的推播通知。▼
「LINE 開發者官方社群」官方帳號 ID：@line_tw_dev
關於「LINE 開發社群計畫」
LINE 2019年開始在台灣啟動「LINE 開發社群計畫」，將長期投入人力與資源在台灣舉辦對內對外、線上線下的開發者社群聚會、徵才日、開發者大會等，已經舉辦 30 場以上的活動。歡迎讀者們能夠持續回來察看最新的狀況。詳情請看: