公司如何招到最好的人才？ – Easy Marketing

作為一家創業公司，你最應該聽取的建議是什麼？
當然是：永遠只僱傭最好的人才。
無論你的公司規模成長到了多大，永遠不要對這一僱人標準作出妥協。

沒錯，一支偉大的團隊可以把一個不錯的點子變成引領世界潮流、令人難以置信的偉大產品。但是左思右想之後，我總覺得有些地方不太對勁兒。因為有一個明顯的前提被人們故意視而不見了：你能僱傭的最多是那些願意在你所在城市工作的最好的人才。無論你的公司是在舊金山、山景市、紐約、波士頓還是芝加哥。你所面臨的問題都是一樣的。要說吸引世界範圍內的優秀人才這件事，誰都能動動嘴皮子吹吹牛。但實際情況是，我們只能就近找到這個範圍裡最優秀的人才。

那麼，創業公司招收最好的人才是不是變成了一句空話呢？連續創業者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進行招聘時，我們找的都是資深的從業人士。這不代表我們對於年輕新手的能力不認同，而是說我們的組織無法對他們進行有效的遠端輔導。從遠端工作的角度看，你行就是行，不行就算不行。我們的生產率不會被新手拖累，新手也不會在我們這碰到挫折。所以，這種做法對大家都有好處。

如果你的策略需要依賴於新手的成長，那麼你需要給他們制定出一段一起在同一空間內緊密合作的時間安排。成對的進行寫程式可以是一個備選專案。