來自天災的遠距發展經驗談

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

很多標準程序（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）就是這個意思。

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

原文網址：tuna.press/