來自天災的遠距發展經驗談/葉光釗

最近的「武漢肺炎」與軟體業的「遠距發展」這兩件事,看起來好像風馬牛不相及;不過只要回頭看過去的歷史、並且看得夠多夠久,就可以瞭解一件事:許多的技術與程序都來自緊急事件的發生。

很多標準程序(SOP)的訂定,都是因為像過去的SARS、或是現在的武漢肺炎這類情況發生,才一口氣將醞釀很久的想法轉成實踐。

這裡就來聊一下筆者在微軟服務時,曾經遇到的經歷。

921地震

進公司沒幾年,就遇到了921大地震;當時經驗還不夠,所以在地震發生之後,心中只惦記著要讓總部的同事們知道台灣發生了甚麼事。

當初還沒有成熟的網際網路,所以我顧不得餘震不斷,冒險跑回公司大樓,徒步爬了10層樓回到辦公室,地板一邊搖、一邊用筆電將email發出去;之後還和同事將研發用的伺服器一一關機,最後才帶著笨重的筆電逃了出來。

當時自以為處置得很專業,事後卻被老闆罵了一頓。

理由很簡單:

人身安全的價值遠高於機器設備。

當非常事件發生的時候,第一時間應該要確定的,是團隊成員是否平安、並且可以聯絡得上,而不是跑去照顧設備,那根本就是本末倒置了。

那時候雖然手機之類的隨身通訊裝置還不發達,但我們還是按照「老鼠會」的模式,設計了一套能在最短時間找到所有成員的聯絡方式;那時候每個人都有一張小卡片,我到現在還留著。

SARS事件

接下來就是有名的2003年SARS事件了。現在的年輕人可能聽過,但一定不容易想像當時的混亂程度。

由於這在之前完全沒有先例,在不知道可能被傳染的模式、或是機率高低的情況下,研發部門必須決定要不要把同仁找來辦公室上班。

以當時的技術,還沒有辦法完全以遙控的方式完成工作,所以一開始還是必須有一半的人要來辦公室;後來大家想盡辦法,七拼八湊使用各種還不成熟的新技術(像是RDP、SSH、VPN等等),才把必須使用公司內網(Intranet)的電腦數量壓到最低。

此外,我們也使用MSN(正式的名字應該是「MSN Messenger」)和各種不同的即時通訊工具(聽過「ICQ」嗎?)進行遠距通話和會議。最後總算宣布所有人都可以在家工作(Work from Home),一直到疫情結束為止。

這樣演練一陣子下來,反而獲得了意外的收穫:團隊對於人不在辦公室時的研發運轉模式和技術運用,都有不錯的心得;之後在很多的突發狀況下,應對就更有效率了。

日本311地震

相對接近的一次,則是日本的311大地震。

雖然災難發生在日本,但當時的研發範疇橫跨了西雅圖、東京、北京三個區域;日本團隊是否能維持運作會有「蝴蝶效應」,影響範圍很難預測。

由於日本採取分區供電,而位在東京調布的研發公司位置也在停電區域內,所以我們必須做最壞的打算,也就是假設日本方面的研發無法在原來的辦公室進行。

我們做的第一件事,就是將預計的交付時程往後移一個月,之後則是盡量將原來日本團隊的工作盡量分散給北京和美國;同時,東京團隊也積極尋找並選定備用的辦公室位置。

計畫訂好之後,團隊吃了定心丸、陣腳也穩了下來;而日本同事也夠硬氣,還是在原來的時程內把工作做完,整體進度沒有受到太大的影響。

結語

現在回顧起來,這些非常事件的經歷,其實對遠距發展(Remote Development)的實踐有很多幫助。藉由以上的經驗,我們訂下了三個核心原則:

  1. 對人員的溝通網路要及時、而且有效:除了緊急時期的人身保障之外,還可以隨時瞭解每個人的工作量,並在必要時做動態調整。

  2. 善用各種技術工具,降低通訊成本:這一點在現在這個雲端時代,應該是相對容易做到的;重點倒不是要執著在特定的工具上,而是「有甚麼用甚麼」,能有效溝通才是重點。

  3. 對「最糟情境」(worst-case scenarios)要有計畫:設定計畫並不是對前景悲觀的反應,而是在這種非常事件之下知道該怎麼做。這對穩定軍心會有很大的作用;老外說的「未雨綢繆,有備無患」(Expect the worst and hope for the best)就是這個意思。

以上就是筆者個人的一些經驗;雖然簡單,但確實有用,希望對軟體開發、或是其他不同行業的團隊能有些幫助。