转载

荐书《台版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 读书笔记

刚看完 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 .... 应该也是可行...

如何打造一个 Remote 工作的环境

礼拜三跟 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 缺乏这样的环境、成员、心态，带来的不会是高生产力，而是灾难。