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

Published on:

禮拜三跟 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 缺乏這樣的環境、成員、心態,帶來的不會是高生產力,而是災難。