
因為第一天開始就是遠端,雖然沒有加蓋,但隔了一整個太平洋的距離,時區也完全不一樣,團隊與工作的設計就必須跟一般公司團隊有點不一樣。
這樣的設定,犧牲的是溝通的質與量,但是得到的是團隊成員不受干擾,可以專心致力難題上的時間。只是犧牲的溝通,要想辦法補回來。
必須像是 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,揪咪
One thought on “矽谷新創在台灣之術,遠端(二)”