如何打造一個 Remote 工作的環境

禮拜三跟 Teahour 的主持人玎玎和這期的嘉賓 Tinyfool 聊創業（會前會）。中間岔題講到 Tinyfool 開始想把自己的創業公司轉換成 Remote 工作環境。有過 Remote 經驗的我和玎玎就七嘴八舌的給 Tinyfool 了非常多意見。十幾分鐘講下來，原來大家的經驗看法幾乎都是一樣的。趁還有熱情寫這個題目，順便在 blog 把重點整理一下... 參與成員必須都要是 Senior 等級的開發者

根據所有人的經驗，Junior 是絕對不能參加 Remote 的。原因有幾個，

(1) Junior 不管在專業上或者是做事方法與態度上，都有很大的磨練空間。如果 Remote 反而會因為無法近距離與同事交流，學習的速度變得緩慢。 (2) 在 Remote 的環境中，時刻與同伴保持若即若離的非同步方式合作的技巧難度非常高，如果沒有成熟的技巧，反而會造成效率低落和合作上的挫折。 (3) Remote 其實是比較辛苦的，因為工作者反而要依靠一些遠端輔助工具，補足同步節奏的問題。但是 Junior 的做事模式和認知是「有完成交辦任務」就好。所以在 Remote 時，反而會覺得比較爽，因為沒有人管，只要「做好手頭上的事」。能完成的事品質反而比較差，打亂大家的節奏...同時也會因為「有做完就好」，變得高興什麼時候作就什麼時候作（不顧團隊節奏），晨昏顛倒（因為精神較差所以只能 deliver 出次等的程式碼）。 團隊內有很好的協作與自動化工具

Issue Tracking ( 如 Redmine, Pragmatic.ly )
Chatroom ( 如 Hipchat, Skype)
Code Version Control ( 如: Git or Github )
Log Channel ( 如 Redmine issue, Github commit log 結合 Hipchat )
Screenshot Tool ( 如 droplr.com ）

團隊合作處理的都是比較大等級的專案，「比較大」通常意味著這個專案會有非常多 Task。在很多 Task 的狀態時，必須要有一個工具可以很好的將 Task 依序列出，有優先等級管理，有歷史紀錄，有應答功能。讓大家不至於互踩到手腳，使用版本控制管理系統也是相同的道理。

Chatroom 則補足無法面對面交流的狀況，若文字與圖片示意還是不夠，則直接使用語音交聊。

Log Channel 則是一種交流型輔助，因為 Issue Tracking 和 Code Version Control 往往都還是使用 Email 寄信輔助（有等於沒用），團隊需要一個可以一目了然今天專案即時動態的地方。Log Channel 是很好的 Dashboard。 團隊內要有 Coding Policy

除了外在的輔助工具外，內部的規矩也是很重要的。Code 要怎麼設計才能讓同事快速接手？什麼樣的設計與命名絕對不能出現，以免同事一進來就踩中地雷陣亡。或者是花上太多不必要時間的時間除雷...

團隊必須要有一致的工具默契與設計默契。如果沒有，那就必須設計一套，強迫大家遵守。 對事不對人的默契

因為大家都不是面對面，用文字和聲音交流，很容易因為一個差錯，就擦槍走火變成糾紛。團隊成員要有高度對事不對人的默契，相信大家出發點都是為了把產品做好，而不是在爭功諉過。否則團隊反而很容易 Remote 造成的誤會分崩離析。 定期的 Standup 與 On-site meeting

Remote 時很容易因為都在埋頭做事，很容易不小心做著做著就偏離原先的航道或者是原先的 schedule。每天至少還是需要一次的 Standup，確保在正確的航道上。每週一次的 on-site，把需要高度合作的項目解決掉。 了解為什麼要 Remote

有很多人誤以為 Remote 是一種輕鬆的工作型態，或者誤以為 Remote 還可以順便省房租。事實上這都是錯誤的觀念，Remote 的成本其實相當高昂，若無法有效的團隊的協作的話，掉的生產效率折算成工錢可能還會是房租的好幾倍。

Remote 能夠提供的是

讓工作夥伴省下舟車通勤勞頓之苦，把節省下來的精力與時間，效益轉到在工作的成果上
在更適合自己的設備與環境下，高速專注的做事。
在更適合自己生理作息（非朝九晚五）的時間下，產出更好品質的成果。

這三件事的共通點，以一句話來總結，Remote 是為了把事情做得更好，產出能做出好成果的心裡的爽。而不是為了不做事，能夠當時間小偷竊喜的爽。

若是 Remote 缺乏這樣的環境、成員、心態，帶來的不會是高生產力，而是災難。