导语：有一个显而易见的问题：你能雇佣的最多是那些愿意在你所在城市工作的最好的人才。那么，招收最好的人才是不是变成了一句空话呢?

作为一家创业公司，你最应该听取的建议是什么?当然是：永远只雇佣最好的人才。无论你的公司规模成长到了多大，永远不要对这一雇人标准作出妥协。

　　没错，一支伟大的团队可以把一个不错的点子变成引领世界潮流、令人难以置信的伟大产品。但是左思右想之后，我总觉得有些地方不太对劲儿。因为有一个明显的前提被人们故意视而不见了：你能雇佣的最多是那些愿意在你所在城市工作的最好的人才。无论你的公司是在旧金山、山景市、纽约、波士顿还是芝加哥。你所面临的问题都是一样的。要说吸引世界范围内的优秀人才这件事，谁都能动动嘴皮子吹吹牛。但实际情况是，我们只能就近找到这个范围里最优秀的人才。

　　那么，创业公司招收最好的人才是不是变成了一句空话呢?连续创业者Jeff Atwood写下了他的看法：

　　要想真正实现招到全球范围内最佳人选的话，我认为公司们应该摒弃必须来办公室上班的做法。尽管听上去有点疯狂，但至少，IT公司是可以做到的。

　　2008年，我和合作伙伴共同创立了Stack Overflow公司。这家公司位于加州伯克利，我和在纽约生活的Joel Spolsky每周进行电话沟通。后来，我们的团队又纳入了在北卡罗来纳生活的开发者以及在俄勒冈州和德州生活的成员。随后，一位在佛罗里达生活的社区经理加入了我们。两个分别位于英国和德国的程序员也进入了我们的团队。尽管我已经离开了这家公司，但我上一次查看时发现，团队规模已经扩展到了150人左右。

　　我在这次经历中最大的收获在于我意识到了硅谷以外的地方还生活着那么多非常优异的程序员。当你的选人范围从加州湾区扩大到全球之后，你的公司才可能从真正意义上招到最合适、最聪明的员工。他们不必到你的公司所在的区域来生活工作。

　　目前，我的初创企业Discourse为客户、粉丝和观众就特定话题的讨论提纲了交流平台，他们身处何处都不是问题。我认为，公司的内部结构应该和其目标用户的需求是一个镜像的关系。如果你软件的服务目标是面向全球社区的，那么你的软件设计团队就应该是来自世界各地的。

　　•一直在线

　　看上去，把身在异乡的人纳入公司团队的想法有点过分超前了。但是未来已经到来了。请想一下GitHub，它有2/3的员工都是远程工作的。 WordPress公司225名左右员工中的大部分都是远程作业的。这些公司都改变了网络的形态，我认为，它们之所以能做到这些很大程度上都应该归因于其远程工作模式的DNA。

　　理想情况下，远程工作在你公司的创立之初就应该成为你公司运营的基本形态。要想建立一个远程工作的公司文化并非易事。这里我有几个建议供你参考。

　　•“拿出成果” vs. “人来上班”

　　人来到公司上班并不代表他真的做了工作。你运营的是公司而不是高中体育课。出勤率并不能保证他获得高分。

　　基于产出的评价将会是一个更加健康的模式：某个员工本周完成了多少功能的开发?他修复了几个bug?他们和客户完成了几次交易?他的程序运行速度有多快?占用内存有多小?维护难度有多大?

　　在Discourse，我们通常会根据员工的GitHub日志来评定其工作质量的优劣。或许你还可以借助Asana或者Basecamp等流程分析工具进行分析。

　　对于我而言，最重要的是：

　　让员工把他们所做的有用的部分展示出来。我需要看到的是done的部分，而非to do的部分。

　　我不在乎员工何时进行工作或者他们自己的日程安排情况。我不在乎他们生活在哪个国家。我不在乎他们特有的工作方式。我不是一个微观的管理者。如果你真的招到了最好的员工，他们就应该通过自己的工作成果向你验证你的判断。

　　你怎么确定哪些人更加合适呢?当你的员工主动指出产品的问题并独力给出解决方案时你就能确认这一点了。这时，你就能够更加放心的把产品的改动权(以及犯错权)交完全交给这些员工了。

　　•以实战演习来招人

　　假定某个背景不错的候选人已经通过了初期的筛选。现在，要进入面对面的对话时间了吧?

　　我曾经不止一次的看到过通过了以上流程筛选的候选人在入职之后完全无法完成职务的职责需求。即便是你曾经和一个人面对面的对谈过，要想最他的职业道德和专注度做出判断仍然是一个及其困难的事情。

　　如果你真的想看看某位候选人的真实水准，在他和你团队中的其他成员接触之前就给他一个项目测测他。我所说的不是那种一般性、抽象性的问题。我说的是你正在处理的项目中所遇到的真正问题。你应该把这个问题抛给他，看他的反应和做法。这是一个本应由现有员工解决的问题。

　　理想中，你的演习项目应该是那种有着明确目标完成定义和完成截止时间的咨询项目。给候选人一个可以在几天内完成的小型项目。是来公司还是在家远程工作则由他自行决定。

　　我知道并非所有的公司都能从整体流程中随时拿出一个小型的项目供外界解决。但是如果你做不到这一点，你的公司在现有结构下在运营流程上可能是缺乏结构性的。

　　在Stack Overflow，我们有一些开源组件，在招聘时，我们会让候选人针对这些组件独立开发我们想要但还没做的一些功能元素。如果候选人能够独立工作，能够与我们清晰沟通并且按时提交要求中的作品，那么他就是一个合适的入职者。

　　如果演习项目能够成功完成，你不但收获了一位通过了验证的能做事者，还完成了一项之前没有完成的任务。到目前为止，但凡通过了演习测试的员工在实际工作中还没有一个人无法胜任自己的岗位。

　　对于招聘中的演习测试，我非常看重。因为除了没有签订劳动合同以外，其他因素和正式员工的实际工作是没有本质差别的。即便演习测试未能通过，与成本颇高的面试流程相比，这种模式的成本简直不值一提。在最坏的情形下，你只需要把这个演习项目交给下一个潜在的候选人来完成。

　　•从你的产品社区招人

　　我越来越发现，人们对于公司文化的认同要比技能本身为公司带来更大的成功概率。但是对于这些不在一起办公的人们，你应该如何增强他们对公司文化的认同感呢?

　　我意识到，并非每个行业都建立了围绕着自身业务的社区。但是，如果你的公司确实拥有一个由用户、开发者和粉丝组成的更加宽广的生态系统的话，从这些人里面找的合适的员工将会是一份及其美妙的事情。这些人是天生买你帐的人，他们的价值观和你的观念自然吻合。自然的，这些人对公司价值观的认同感会异乎寻常的高。你要找的正是这样的人。

　　是否有一小部分用户为你的游戏开发了一个很棒的组模?是否有铁杆粉丝在你的论坛上每天回答其他用户的问题?是否有工程师提醒你他发现了产品的安全隐患?这些人都是你应该在招聘时特别留意的对象。为了增加你成功的机会，你在平时就应该加强和他们的互动，向他们提供特别产品等等。在 Discourse和Stack Overflow，我们都采取了类似的做法。

　　如果你的公司规模尚小或者还处于产品规模化前期，你仍然可以到社区去找人。在你的产品方向上，很可能已经有了类似的社区存在。你应该到这些社区里去看他们交流的内容和方式。之后，你应该和他们对自己的工作方向和他们能够获得的机会进行沟通。

　　另外，你也应该到那些对于你所在领域目前状况抱怨颇多的社区去交流。尽管会有些困难，但一旦你的产品和理念被这些人所接受，他们就会迅速的转向你的公司社区去。因为这些人是很在乎这一领域产品形态的人。

　　•每天使用公众通信工具

　　当你的员工采用远程办公时，通信工具就不应该局限于实时交流工具。通信工具应该随时都能使用，这是远程工作的自然组成部分。不要把重要信息的交流形式放在本地的会议上。

　　远程办公，你的员工需要这些工具：

　　- 实时聊天工具

　　你无法走到远程工作员工面前和他交流问题，那么实时碎片式的沟通就是不可缺少的。重要的一点在于，每个人都应该经常性的使用同一个实时聊天工具。作为领导者，你应该不断强调这一点。

　　聊天是远程合作团队在工作时最为核心和普遍的沟通方式。因此，你必须绝对确保在任何情形下能够和每一个人实现联系。

　　- 在线BBS

　　为了让团队对于成员和项目的情况都有整体的了解，你需要一个发布公告、团队周报和会议纪要的BBS平台。这是在线聊天很难实现的。

　　在这个平台上，团队之间会用以发布除了邮件和在线聊天以外的信息。你的电邮应该订阅BBS平台新帖子或讨论的发布消息。每个成员也应该自动获得每周/每日BBS的内容摘要。团队成员绝对不能忽视这些消息，最好尽快阅读。

　　- 语音和视频聊天

　　有时候，文字的交流无法把真实的问题描述清楚。这时候，你就需要能够和网络对面的同事实现语音或者视频对话。请不要低估用语音和另一个人类对话所蕴含的能量。尽管程序员里很多都是不愿意用嘴说话的死宅，但是我们得把工作干完不是吗?难不成我还得花六个小时飞到你家里嘛?

　　在视频和语音对话过程中，人类的语气和表情对那些冷冰冰的字符构成了很好的补充。我建议，远程工作的人们每周至少要有一次进行语音或视频的对话连接。时间可以不是很长，但可以把他设计成一种公司的check in制度，以确保屏幕背后的同事确实也是一个人类。请记得，即便是远程工作的模式，你还是人类的一员。

　　•周一团队情况汇报

　　每周一，公司的每个项目团队都应该提交一份简要的情况汇报：

　　-上周完成了什么

　　-本周工作计划

　　-工作中的困难或者考虑到的其他因素

　　这份报告越简短越好，但应该涵盖了所有的重要信息。每周一都把这份报告发布在公司的BBS上。团队规模式具体情况而定，如果你的公司非常小，每个人就可以是一个团队。

　　•会议纪要

　　对于任何你认为是“会议”的会面务必都要保留下会谈的纪要。请把纪要发布在公司的BBS上，这样那些在远方工作的团队成员将会从这些信息里获得益处。

　　需要指出的是，你的会议纪要务必在完整的前提下保持简短。你无需写下每个细节，把大画面展现出来就够了：参会人是谁?讨论了什么话题?达成了何种决定?下一步的动作是什么?

　　*** 在谈完了远程工作的好处和方法之后，我不得不指出这一模式的一些缺陷：

　　•头脑风暴

　　当你的团队需要经常性的通过头脑风暴来推进项目时，远程工作的弊端就显现出来了。在头脑风暴的进程中，共处一室的团队成员能够看到、听到、感受到彼此的动作、呼吸和存在。这些感知对于主意的迅速产生有着非常重要的影响力。如果在远程工作的环境下进行头脑风暴的话，你需要极端高速的贷款、低延时率以及人与人之间的直接沟通。好信息是，我们在Stack Overflow和Discourse工作时，这种类型的会议非常少。当你需要进行头脑风暴时，你可以把它安排在公司每年一度碰面的年会上举行。

　　•导师辅导

　　员工辅导需要资深员工在新进员工身后不是的照看并对其工作成果给予及时的反馈。在采用松散连接结构的远程工作机构里，这种来自导师的员工辅导变得非常的困难。

　　我们的做法是，避免那些需要辅导的人进入团队。在Stack Overflow和Discourse进行招聘时，我们找的都是资深的从业人士。这不代表我们对于年轻新手的能力不认同，而是说我们的组织无法对他们进行有效的远程辅导。从远程工作的角度看，你行就是行，不行就算不行。我们的生产率不会被新手拖累，新手也不会在我们这碰到挫折。所以，这种做法对大家都有好处。

　　如果你的策略需要依赖于新手的成长，那么你需要给他们制定出一段一起在同一空间内紧密合作的时间安排。成对的进行编程可以是一个备选方案。

　　•后记

　　在考虑了远程工作的优缺点之后，当你想象在20、40、60年之后从事数字产业人们的工作状态时，是否还会认为人们将会把他们的时间花费在每天一两个小时的通勤交通上?

　　你认为初创企业的招聘流程在十年以后还是会和现在的同行做法一样吗?

　　从我们自己的Discourse和Stack Overflow两家公司的经历来看，从全球范围里招人给我们带来了战略性的优势。我相信，远程开发模式代表了未来的工作模式。如果我们能够开始进行一些这方面的思考和尝试，一定会物超所值的。你还在等什么?