荐书《台版Remote：我们办公室没有人》_最新动态_新闻资讯_程序员俱乐部

　　文/郑伊廷

　　推荐权自强的这本新书。台版 Remote：「我们办公室没有人！管理大解放，自由工作团队如何创造更高绩效」

　　先自我揭露一下，权自强有说要送我试阅，喜欢的再帮忙推荐给朋友。但是因为我想先看，在书还没寄到之前就先跑去诚品买了 XD 所以我是在没收到赠书的前提写的。写这篇推荐纯粹是我喜欢所以我推荐。

　　如果你想要创业雇用 Remote 的人，或者是你想要应聘 Remote 工作。我建议你入手这本书然后画重点。这本书用很平实的手法，叙述了他创业之始如何用 Remote 的招募方式，在台湾建立了一个二三十人的工作团队，并运行顺利。

　　这本书相当值得一看的是，很多人都觉得 Remote 不可高攀。而 37signals 出那本 Remote 的书有写等于没写。因为 37signals 很屌是黄金圣队（37signals 是 Ruby on Rails 这套 Framework 的发明者），每天 A 咖履历都收到手软不想再收，所以他们才做得到。(Remote 的关键在于「能不能 Hire 到负责任且有创造性的天才 A 咖」，而 37signals 根本不用放广告大家就抢破头了。所以讲 Remote 一点说服力都没有。）

　　这本书让你见识到一般台湾小公司也可以做到。而且他们还不是写 code 的技术公司，而是网路行销公司。

　　我觉得书中不脱几个重点。但是作者让你能够相信，把握住重点你也做得到，这本书反复了强调几点雇人的重要原则：

1. 只雇用你能够信任的人
2. 尽量信任他们能够完成工作
3. 被动只等老板指派且无法完成交派工作，更别说举一反三的员工，千万不要碰。只雇用有责任感，能够主动发掘问题解决问题主动回报进度的人。

　　其实我觉得还是回到那句老话。如果你要参与 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 缺乏这样的环境、成员、心态，带来的不会是高生产力，而是灾难。