这就是为何创业公司找不到最优秀员工的原因

创业公司经常会听到这样一条建议：一定要招聘那些最出色的员工，无论你的公司有多大，都不能降低招聘员工的标准。这条建议没错，因为只有由出色员工组成的优秀团队才能够将一个好的想法转化成伟大的产品。

有关这条建议，思来想去，总感觉哪里不对。我们总是口口声声说要招聘全世界最出色的员工，事实上，我们做的仅仅是雇到我们周围那些还不错的员工，而非全世界最出色的员工。如果我们真想做到雇到全世界最出色的员工的话，我们应该真正的努力那样去做，而不是仅仅说说而已。为此，我们就必须摒弃这个想法：招聘的员工必须能够来公司上班。

当我和另外一位联合创始人 Joel Spolsky 在 2008 年联合创立问答网站 Stack Overflow（现在的 Stack Exchange）时，我当时的办公地点在伯克利，而 Spolsky 的办公地点在纽约，当时我们每周主要通过电话沟通工作方面的事宜。后来又陆陆续续加入了来自北卡罗来纳、德克萨斯和俄勒冈州、英国和德国等地的开发者，加入公司后他们依然在原先所在的地方办公。我现在已经不在这家公司了，据我了解，现在这家公司的员工近 150 位，分别在全世界的不同地方办公。

从在 Stack Overflow 的经历中，我学到的最宝贵的经验之一便是：很多出色的软件工程师其实并非来自硅谷，只有在全球范围内进行招聘，而非仅局限于旧金山湾区，才能让你真正有资格说你只招聘最出色的员工，并且说到做到。

Discourse 是我新创立的公司，它是一个能够让全球的客户、粉丝和观众围绕某一个大家共同感兴趣的话题进行讨论交流的论坛平台。我认为，公司内部的架构应该能够反映自己的用户情况。如果你想让全世界的用户都来使用你的软件，你应该让全世界都来帮助你开发这个软件。

实践时间

以 GitHub 为例，它的至少三分之二的员工都在全世界的不同地方办公。再看看 WordPress，它的大部分员工也都是异地办公。这些都是深深影响了互联网的成功公司的典型，它们为何能取得如此大的成功，我认为让异地办公成为公司 DNA 的一部分在其中起到了至关重要的作用。

最理想的情况是，公司最初就是在异地办公这种理念模式下创立起来的，异地办公已成为公司的内在文化基因。

展示你的工作成果 VS. 仅仅是人出席露面

一个员工按时上班并不能说明他在有效地开展工作。这是在公司，不是在学校。在公司看重的不是出勤，而是工作成果。

以工作成果来考核员工更为科学：

（1） 一位员工本周开发出了几项功能？

（2） 他一周修复了几个 bug？

（3）他一周和客户进行了多少次有效的交流？

（4）他的编程速度有多快？

在 Discourse，我们通常依据员工提交的工作日志来判定他工作做的是好是坏，这样你就能对员工的工作有准确的了解。在这个过程中，你可以使用一些工具，如 Asana 和 Basecamp。总之一点：

“让员工记录下自己已经完成的工作。记录的不是‘待办事项’，而是‘完成事项’”。

我不在乎员工何时来上班，不在乎他们的工作安排是怎样的，不在乎他们在地球的哪个角落里办公（前提是网络畅通），也不在乎他们是如何开展工作的。如果你招聘的真的是最出色的员工，那么这些员工是能够以自己的工作成果来证明自己的。

你怎么知道这是否行得通呢？当你雇的员工发现产品有个问题，并自己主动将问题解决的时候；当你能够放心地充分授权员工让他们自行对产品做出改变，虽然你知道过程中他们可能会犯一些错误的时候。在这些时候，你就知道这是行得通的。

通过实战的方式进行面试

你肯定遇到过这样的情况：应聘者通过了基本的测试，和公司文化也比较契合，也顺利通过了电话面试以及面对面的面试了，最后顺利加入了公司。然而当真正开展工作的时候，却发现他们很难胜任自己的工作。我自己也曾碰到过这种情况。我的经验是，要想知道一个应聘者能否真正胜任所应聘的工作，最好的办法就是通过实战的方式进行面试。选择一个你在现实的工作中的确需要解决的一个产品问题，这个问题在正常情况下应该能在大约一周内得到解决。将这个问题作为一个实战考核项目来对应聘者进行考核，看他是否真正有能力在相应的时间内将问题解决。这解决问题的过程中，应聘者可以选择来公司办公，也可以选择异地办公。

我也知道，很多管理者或许一时找不到能在规定时间内得到解决的考核项目。“如果你找不到能够用于考核应聘者的小工作量的考核项目，你在平时的工作中可能也没能很好地给员工分配工作任务。”

在 Stack Overflow 不存在找不到用于实战面试的考核任务的问题，因为我们有一些开源组建，我们经常以此作为考核项目对应聘者进行实战面试和考核。如果应聘者能在规定时间内独立完成考核任务，那么恭喜你，你已经找到了一位出色的员工。到目前为止，我还没有碰到过能通过实战面试考核却无法胜任自己工作的面试者。

从自己的产品社区中招聘

我发现，对公司而言，员工与公司的文化契合度比员工所掌握的技能更为重要。在员工普遍异地办公的情况下，如何创建公司文化呢？

我知道，并非每个公司都有一个大规模的由开发者、用户和粉丝等组成的社区，如果你的公司有这样一个社区，你应该从这个社区里进行招聘，为什么呢？因为如果是自己所在社区里的人，他们肯定也认同你的公司及公司的产品，那么他们与你的公司的文化契合度就会更高，而这也正是你需要的。

是否有一些高级用户每天都在你的论坛上帮助回答其他用户的问题？是否有一位工程师发现了你的产品的漏洞并及时提醒你？这样的人正是你应该努力招聘的。要想增加成功招聘这些人的砝码，你平时应该加强与他们的交流，为他们提供一些特别的优惠，以加深他们对你的公司的认同感。在 Discourse 和 Stack Overflow，我们就是这样做的。

如果你的公司现在规模还太小，还没有形成一个自己的初具规模的社区，你还有其它选择。肯定有其它一些已经形成规模的社区，这些社区和你希望建立的社区类似。到这些社区里去找那些能与你形成共鸣的人，并竭力说服对方，如果方式得当，将他们纳入麾下将不成问题。

每天都使用大众传播工具

如果你的公司的很多员工都异地办公，那么大众传播工具就扮演着至关重要的作用，要时刻都要使用，要让它成为工作的重要组成部分。对那些存在异地办公现象的公司而言，下面这些要素必不可少：

实时聊天

如果你的团队的很多人都是异地办公，他们分布在天南海北，当你需要问其中一位一个需要及时回复的问题时，你需要相应的即时通讯工具帮助你，现在这样的工具有很多，包括 Hipchat、Slack、IM 等。这里特别重要的一点是，要确保使用这项通讯工具能随时联系到团队中的每一个人。

在线公告栏

很多时候，异地办公的团队成员能够了解一个项目的详细进展，但却无法了解很多其它项目的进展情况。在这种情况下，你就需要一个在线虚拟公告栏，很多内容都可以在这个公告栏上公告，包括团队工作周志、会议纪要和一些其它需要公告的事项。现在提供在线公告栏服务的商家已有很多，Discourse 本身就提供这种服务。

语音视频聊天

很多时候，光靠语音交流是不够的，因为很多信息是难以通过纯语音交流获得的。对于异地办公现象普遍的公司而言，要真正面对面交流也并非易事，因为人与人之间可能相隔十万八千里。在这种情况下，语音视频聊天工具就派上用场了。

在网速足够快的情况下，视频聊天的效果是很接近真实的面对面的聊天效果的，你能够实时捕获对方任何的肢体语言和面部表情，这些都是邮件交流或是纯语音交流所无法比拟的。我建议团队中的所有成员每周至少视频交流一次。这里所说的交流不必是冗长的视频会议，我比任何人都讨厌那些冗长无实质内容的会议。在一个异地办公现象普遍存在的公司里，要想保持异地团队的凝聚力和工作的高效性，定期的视频交流会议仍是必不可少的。

每周一的团队工作汇报

每周一，你公司的所有团队都应该提交一份工作汇报，内容包括：

（1） 我们上周做了哪些工作？

（2） 下周我们打算开展哪些工作？

（3） 工作中遇到了哪些困难或是担心的问题？

这份工作汇报不用太长，在保证能够包含主要的有用信息的前提下，工作汇报越简洁越好。每周一都将工作汇报放到在线公告栏上，这样一来，很多异地办公的员工都能很好地了解其他人的工作动态。

会议纪要

一旦需要开会解决一个问题时，一定要做会议纪要, 并将会议纪要也放到在线公告栏上，这样那些没参加会议的员工也能从中选择性地获取对自己有用的信息。

同样，会议纪要不必太长。如果你觉得做会议纪要的工作太繁重，只能说明你记的方法不对。其实你只需要将那些关键信息点记录下来即可，不需要什么都记。需要记录的内容包括：参会人员、讨论的议题、会议结论、下一步如何开展工作等。

对于某些特定的情形，异地办公也有它的弊端

头脑风暴

在某些特定的场合，当你需要团队进行头脑风暴来碰撞出火花时，异地办公的弊端就显现出来了。如果需要进行头脑风暴，最好是大家都在一个房间里，这样大家的肢体语言、面部表情等都能一目了然，相互间观点的碰撞也才更容易碰撞出火花。不过在 Stack Overflow 和 Discourse，需要这样的头脑风暴的场合是非常少的。就算真正需要，我们也可以在每年的公司年会上进行，那时，公司的员工会齐聚一堂，共同畅想来年的规划和梦想。

员工辅导

对员工进行辅导需要师徒间反复的交流和提问。对于一个异地办公现象普遍存在的公司而言，对新员工的辅导就显得力不从心了。对此，我们的解决方法就是避免招聘那些需要辅导的员工。无论在 Stack Overflow 还是在 Discourse，在招聘员工的标准上我们一直保持较高的标准，这并不是因为我们不相信有潜力的开发者的存在，而是因为对于我们这种异地办公普遍存在的公司而言，对新员工进行辅导培训有点不切实际。如果你想通过帮助初级开发者成长为资深开发者来实现公司发展的话，那么你必须保证师徒间有足够的时间在一起。

对利与弊都进行充分考量后，想象一下 20 年后、40 年后甚至 60 年后开发者的工作情形是怎样的？还是每天都要苦逼地坐 2 小时车上下班吗？

“在你看来，招聘政策是应该基于10年前的工作模式来定，还是应该基于10年后的工作模式来定呢？”答案不言而喻。