禮拜三跟 Teahour 的主持人玎玎和這期的嘉賓 Tinyfool 聊創業（會前會）。中間岔題講到 Tinyfool 開始想把自己的創業公司轉換成 Remote 工作環境。有過 Remote 經驗的我和玎玎就七嘴八舌的給 Tinyfool 了非常多意見。十幾分鐘講下來，原來大家的經驗看法幾乎都是一樣的。趁還有熱情寫這個題目，順便在 blog 把重點整理一下...
參與成員必須都要是 Senior 等級的開發者
根據所有人的經驗，Junior 是絕對不能參加 Remote 的。原因有幾個，
(1) Junior 不管在專業上或者是做事方法與態度上，都有很大的磨練空間。如果 Remote 反而會因為無法近距離與同事交流，學習的速度變得緩慢。
(2) 在 Remote 的環境中，時刻與同伴保持若即若離的非同步方式合作的技巧難度非常高，如果沒有成熟的技巧，反而會造成效率低落和合作上的挫折。 (3) Remote 其實是比較辛苦的，因為工作者反而要依靠一些遠端輔助工具，補足同步節奏的問題。但是 Junior 的做事模式和認知是「有完成交辦任務」就好。所以在 Remote 時，反而會覺得比較爽，因為沒有人管，只要「做好手頭上的事」。能完成的事品質反而比較差，打亂大家的節奏...同時也會因為「有做完就好」，變得高興什麼時候作就什麼時候作（不顧團隊節奏），晨昏顛倒（因為精神較差所以只能 deliver 出次等的程式碼）。團隊內有很好的協作與自動化工具
- Issue Tracking ( 如 Redmine, )
- 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 缺乏這樣的環境、成員、心態，帶來的不會是高生產力，而是災難。