薦書《臺版Remote：我們辦公室沒有人》
文/鄭伊廷
推薦權自強的這本新書。臺版 Remote：「我們辦公室沒有人！管理大解放，自由工作團隊如何創造更高績效」
先自我揭露一下，權自強有說要送我試閱，喜歡的再幫忙推薦給朋友。但是因為我想先看，在書還沒寄到之前就先跑去誠品買了 XD 所以我是在沒收到贈書的前提寫的。寫這篇推薦純粹是我喜歡所以我推薦。
如果你想要創業雇用 Remote 的人，或者是你想要應聘 Remote 工作。我建議你入手這本書然后畫重點。這本書用很平實的手法，敘述了他創業之始如何用 Remote 的招募方式，在臺灣建立了一個二三十人的工作團隊，并運行順利。
這本書相當值得一看的是，很多人都覺得 Remote 不可高攀。而 37signals 出那本 Remote 的書有寫等于沒寫。因為 37signals 很屌是黃金圣隊（37signals 是 Ruby on Rails 這套 Framework 的發明者），每天 A 咖履歷都收到手軟不想再收，所以他們才做得到。(Remote 的關鍵在于「能不能 Hire 到負責任且有創造性的天才 A 咖」，而 37signals 根本不用放廣告大家就搶破頭了。所以講 Remote 一點說服力都沒有。）
這本書讓你見識到一般臺灣小公司也可以做到。而且他們還不是寫 code 的技術公司，而是網路行銷公司。
我覺得書中不脫幾個重點。但是作者讓你能夠相信，把握住重點你也做得到，這本書反復了強調幾點雇人的重要原則：
- 只雇用你能夠信任的人
- 盡量信任他們能夠完成工作
- 被動只等老板指派且無法完成交派工作，更別說舉一反三的員工，千萬不要碰。只雇用有責任感，能夠主動發掘問題解決問題主動回報進度的人。
其實我覺得還是回到那句老話。如果你要參與 Remote 或者想要雇用 Remote。能打交道的還是只有 Senior 工作者而已。
因為 Remote 有幾點關鍵：
- 工作者要非常有責任感
- 工作者有責任心時時去掌握團隊工作動態，去幫助隊友。而不是給隊友製造大便還不自知。
- 遇到問題有足夠的能力自救，或提前向發出求救信號。
- 限于 Remote 因素，可能公司很難好好的傳承經驗或者給教育訓練。所以新入職者要有能力可以迅速 pickup。
這些都是 junior 很難達到的境界。
在寫這篇文章時，我依稀記得以前也在我的部落格稍微聊過這些話題，隨手附上：
剛看完 Remote。大致上有幾個心得。書 50% 以后才是重點。
（如果你需要被說服 Remote 是好的，前面可以看。如果你已經相信 Remote 應該是很好的。前面 50% 可以不用看）
Remote 其實是可行的，不過在幾個前提之下:
1. Remote 的 worker 必須是一個 100% 你會信任的員工。
如何 hire 一個你 100% 信任的人？很簡單，hire 非常厲害的人。后面所有的好事會自己發生
如果你無法相信一個員工，不如直接請他回家，才會是對大家最好的方式。不要認為 hire 一個能力不夠的人，還能玩 Remote，0% chance。
為什么需要緊盯一個員工？說穿了...就是他能力不足，你不相信他。
2. 如何辨認誰是厲害的員工。還是老話一句，看他的 Copy Writing...
3. 找到疑似可以 hire 的員工，如何作最后決定把他捕獲進來？
先花點小錢外包，把一部分的工作外包給他。無業的人給 1 week。正在上班的人給 2week ...
從外包的部份你可以完全看到他的能力足不足夠。
4. 除了信任之外，公司應該內部要有自己的 remote rules 和 workflow
( 書中沒有明指，但是透露出 37signals 應該有很多這種東西...）
5. hire Ace in cheap way
不一定要 hire local 或者是覺得 remote 很貴。你可以去別的薪資比較低的地方去找 Ace player .... 應該也是可行...
禮拜三跟 Teahour 的主持人玎玎和這期的嘉賓 Tinyfool 聊創業（會前會）。 中間岔題講到 Tinyfool 開始想把自己的創業公司轉換成 Remote 工作環境。有過 Remote 經驗的我和玎玎就七嘴八舌的給 Tinyfool 了非常多意見。十幾分鐘講下來，原來大家的經驗看法幾乎都是一樣的。趁還有熱情寫這個題目，順便在 blog 把重點整理一下...
- 參與成員必須都要是 Senior 等級的開發者
- 根據所有人的經驗，Junior 是絕對不能參加 Remote 的。原因有幾個，
- Junior 不管在專業上或者是做事方法與態度上，都有很大的磨練空間。如果 Remote 反而會因為無法近距離與同事交流，學習的速度變得緩慢。
- 在 Remote 的環境中，時刻與同伴保持若即若離的非同步方式合作的技巧難度非常高，如果沒有成熟的技巧，反而會造成效率低落和合作上的挫折。
- 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 缺乏這樣的環境、成員、心態，帶來的不會是高生產力，而是災難。