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

如何打造一個 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 能夠提供的是

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

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

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