因為第一天開始就是遠端，雖然沒有加蓋，但隔了一整個太平洋的距離，時區也完全不一樣，團隊與工作的設計就必須跟一般公司團隊有點不一樣。
這樣的設定，犧牲的是溝通的質與量，但是得到的是團隊成員不受干擾，可以專心致力難題上的時間。只是犧牲的溝通，要想辦法補回來。
必須像是 Daniel Craig 版本 007 中的 Q
你在台灣的天字第一號成員，必須像是 Daniel Craig 版本 007 中的 Q ，專長後勤，運作獨立，還必須要讓人又愛又恨。
（而你，是故事推展團隊的其中一員，在這個設定中，是 007 的身份。記得，你是 007，上圖後面那一個 ，不要假高去做 Q 要做的事情。）
既然設定是 Q ，這位成員可以相當年輕，卻必須有相當程度的領域歷練，要能夠在沒有多少外援的狀態下獨自完成作業，做事時不能左等右等，依賴很多方向上的調整，或是額外專業上的訓練，畢竟良好的溝通在遠端的前提下是稀缺資源。
在這樣的前提下，完全沒有領域歷練的剛畢業生，或是 bootcamp 出來沒多久的新鮮人不是你要找的對象，要在履歷或是面試中篩掉，不然管理成本會很高。
然而，倒也不用一個勁地去追求領域中的『大神』們，你需要的是一個可以完成任務的團隊，不是玩明星三缺一。再者『大神』們有時還有些傳聞中的麻煩，會增加管理成本。
至於『讓人又愛又恨』的部份有兩層意義：
（一）在該領域浸淫久了，會有很多自己的意見與想法，跟你的想法與經驗有時候會相左，碰撞起來會讓你又愛又恨地。
（二）要經營好團隊的文化，能夠不受處罰地表達自己的意見非常重要。你找一群小白應聲蟲，眾星拱月很爽沒錯，但是絕對沒有辦法完成任何有意義的工作。要營造鼓勵討論與想法的文化，一開始就要找那種有強烈表達欲望的成員，讓你又愛又恨地。
定義好任務，提供 context info
既然你找到的成員都是 Q ，都可以毫無問題地獨自完成任務，你只需要定義好任務，理論上事情就要能自動完成，就是這麼簡單。
於是你的主要工作就成了『定義任務』的那個人，這不是件簡單的事情。你認為理所當然的資訊，差一個時區，再差一個太平洋後，都有非常程度的落差與變化，如下圖：
所幸過去 30 年來的軟體專案管理研究有給出解法，我認為跨洋跨時軟體專案管理上，最需要補足也最好用的是 USER STORY，user story 這個框架迫使定義任務的人給出足夠的 context info 。
為什麼會有這個任務呢？這個任務一開始就是必要的嗎？有沒有其他的任務比這個還要重要呢？這個功能的情境是什麼？ … 都能藉由 user story 回答出來，而身為任務的定義者，你必須要鼓勵成員討論這些問題，確定成員都有足夠的 context info 獨立完成作業。
要知道，遠端團隊的弱點就是隨時隨地的恣意溝通，你必須從工作系統設計上補足這方便的需要。
最理想境界，就是像是早期虎膽妙算（mission impossible）中哪些燒掉的錄音帶，交待好任務，錄音帶自動銷毀，然後團隊就會完成任務。
（我覺得近期 mission impossible 都沒有好好地處理燒掉任務資訊的鏡頭，切心！）
建立工作的 pipeline ，注意 blocker
既然你在遠端，沒有辦法就近坐鎮，像隻高傲的公雞一樣頤指氣使，當老大，無時不刻要團隊成員聆聽你的高見。你只能倚靠團遠端團隊成員管理自己的時間與進度。這時掌握團隊前進的速度與節奏就是最重要的事情。
每個團隊成員的工作不同，熟悉的工具與風格也不同，因此每個人的速度都是不一樣的。如果強加要求該成員一味加時或是抄捷徑，短期偶一為之可以，長期而言整個產品的技術債與管理債會多到無以復加，整個自暴。
既然無法灌頂加速，最簡單的加速方式就是建立成員的工作 pipeline 與減少每位成員工作上的 blocker 。
理想的狀況是：團隊成員每天開始之前，就知道今天他最重要的，需要完成的工作是什麼，並且在處理完該工作後，出去騎車，喝咖啡，看漫畫，打電動，甚至約砲休息一下。回來後，立刻著手次重要的任務，然後處理完任務後再次循環，沒有等待指示，沒有遲疑優先權，也沒有技術問題。建立好成員工作的 pipeline ，就能夠最大程度地接近這裡想境界，你也不會半夜睡覺睡到一半還要上 slack 回答成員問題。
這時候，除了上列等待，遲疑，與技術問題所產生的浪費（waste）以外，最大的問題就是些莫名其妙的 blocker ，比如說放在美國辦公室的 build server 措賽了，大半夜的你也沒有辦法離開哭得亂七八糟的小孩去修，導致台灣團隊所有人都 hang 在那邊數手指頭，或者是需要測試用的機器晚好幾天到，除了每天隔靴搔癢，想像測試的結果以外，你的測試團隊閒到每天幫大家定便當解悶。
避免掉，或處理掉（如果避免不掉）這種層出不窮，卻又超會脫慢速度的 blocker 就是你的最重要工作了。
第二號以後，關注團隊間的浪費
在這篇文章變成市面上的管理學長篇大論之前，還有件事情是遠端團隊要非常在意的：如果不是你逼迫，他們不會自己找彼此解決問題。
假設今天你有三位成員各自處理不同任務，後來需要彼此整合工作的時候，儘管知道最終產品的模樣，他們的第一反應仍然是回報給身在美國的你，跟你索討整合資源。而不是找在同一時區，但可能是不同地點的同事。
這樣彼此一等，如果你沒有問，往往會等上好幾天！速度大慢！
這我很可以理解，身為內向阿宅的我，如果沒有必要，是不會找我原來不熟的人聊天的，不僅消耗我儲值本來就不高的社交能量，還要耗費腦力想說要如何不冷場，這是一件多累人的事情阿？不如回報給那個認識所有傢伙的傢伙，讓他去煩惱，問題不就解決了嗎？
要解決這種你等我，我等你的問題，最簡單的方式就是從工作與組織的設計上著手。比如說每項作業非常清楚地指定一個負責整合的夥伴，當他明白知道整合是完成作業的必要條件，他就會自己尋找所需資源完成。
組織大一點後，另一種方式是讓擅長整合的夥伴專門負責整合與協調，他漸漸地就會成為你在台灣辦時區的對口，當上貴公司在台灣的里長伯。
最後，既然大家都是遠端，有沒有必要在台灣放個實體辦公室呢？我認為有必要。
既然遠端就得犧牲溝通，任何可以增加溝通或是合作的方式就要大力投資。雖然不規定所有人都得進公司，有個地方讓在地員工可以見面，開會，或是 party 都能大大提供士氣與工作效率。在趕 project 的時候，相關的同事可以進辦公室，把辦公室當作是 war room 使用，或者是每週大家一起進去一兩次，一起吃飯，就算吃完就各自回家也沒有關係。
這種辦公室的型態，在地的 co-working space 就完全夠用了，有人幫忙管水電，打掃，茶水，與零食…
你要縮小成 context info 的提供者
遠端團隊在台灣，犧牲的是溝通的質與量，你必須要在工作設計與團隊設計上盡量補足犧牲的溝通。
為了讓作業成員能夠一次有足夠的訊息完成工作，你要盡量將每個 ticket 切得互不隸屬，並提供用戶的使用情境，讓團隊成員能夠身歷其境，了解，質疑，或完成這個 ticket ，就像是早期虎膽妙算（mission impossible）中哪些燒掉的錄音帶一樣。
另外，遠端團隊成員的彼此溝通是讓效率提昇數倍的不二法門，如果所有團隊間的問題或是整合工作都是你來做，你就是最大的 bottleneck ，你會覺得你是英雄，超級忙，超厲害，但事實上你只是那隻擋在路上的馬路三寶罷了。要從團隊合作模式與工作設計上解決這個問題。
最後，如果你找團隊的目的是完成工作，不是自我感覺良好的話，找團隊成員要找 007 中的 Q，專長後勤，運作獨立，還必須要讓人又愛又恨。
歡迎有興趣的朋友 fo 我： _wingchen ，或是關注我的 fb 粉絲頁喔：winston.chen.sv，揪咪
太陽拳的萬人敵之術 