【導讀】：Jeff Atwood 是一名程式設計師、Coding Horror 的博主和企業家（創辦了 Stack Overflow 和 Discourse）。
作為一名創業者，你最常聽到的建議是什麼？
永遠只招最優秀的人。無論公司規模多大，永遠不要在你的招聘標準上妥協。
確實如此。優秀的團隊能萌發好的創意，並將其轉化成不可思議的，舉世無雙的產品。
但是有些事總困擾著我，讓我對此建議深感迷惑。有個事情雖然沒人說出來但是大家都心知肚明：永遠只招最好的人……可是誰願意住在舊金山啊。
不僅是舊金山，山景城、紐約、波士頓、芝加哥或其他城市面臨的問題都一樣。我們嘴裡說著招聘世界上最好的人才，但事實上我們只是在招聘碰巧住附近的最好人才。
你可以說我瘋了，但如果我們真的想吸引更多的優秀人才為我們工作，那麼我們就必須要真的把他們“僱”來。也就是說，（至少在 IT 行業）不要再死板地認為人們只有親身前來上班才能產生有意義的工作。因為還有更好的方式。
2008 年我與聯合創始人 Joel Spolsky 著手創立 Stack Overflow（現在的 Stack Exchange）時，我所在的公司辦公點在加州的伯克利，Joel Spolsky 在紐約，一東一西，我們每週保持一次電話溝通。然後團隊擴充套件了，北卡羅萊納州有一名開發人員，其他人都在俄勒岡和德克薩斯州。後來一個住在佛羅里達州的社群經理加入了。接著團隊又簽了兩個分別在英國和德國的開發者。雖然我現在已經不在 Stack Overflow工作了，但記得我最後一次統計員工人數時，公司已經有高達約 150 名了。
（Stack Overflow 的兩位創始人，左 Joel Spolsky，右 Jeff Atwood）
從 Stack Overflow 的經歷中，我學到的最有價值的經驗是，許多傑出的軟體開發者其實沒有住在矽谷附近。真正的招聘應該是全球範圍的，而不是侷限在人才擁擠的灣區，那些打算從灣區搬家的人也在招聘範圍之內。你說你只招聘最好最傑出的人，只有做到這樣才能讓這句話有意義。
Discourse 是我目前的創業公司/產品，致力於讓使用者、粉絲和熱衷於某一特定話題的聽眾之間能夠對話，無論他們住在世界的哪個角落。我相信公司內部的結構應該反映聽眾的訴求。如果想讓全球社群使用你的軟體，那麼做這個軟體的人才也應該來自於全世界。
實踐
把遠端工作者整合到你的公司，這想法看似太超前，難以持續。也許是這樣。但正如 William Gibson 曾經所說，未來已經在這裡了，只是沒有均勻分佈。想想 GitHub，至少三分之二是遠端工作者。看看 WordPress，目前 225 多位的員工中，絕大多數是遠端工作。這些公司已經改變了網路的格局，我認為遠端工作很大程度上成為這些公司 DNA 的一部分。
理想情況下，你開始把遠端工作視為公司的核心哲學。即便如此，要形成遠端工作的文化還是具有挑戰性的。不過有幾個重要的方法你可以嘗試一下：
“展示你的工作” VS. “僅僅是露面”
有的人每天準時上下班，但著不意味著他們的工作也很到位。在企業上班不是在高中上體育課，光靠完美的出勤率是沒法及格的。
通過產出來評判工作更加合理：
- 員工這周實現了多少個功能？
- 他們修復了多少個 bug
- 他們與客戶進行了多少次交流？
- 程式碼速度提高多少？精簡了多少？可維護性提高多少？
在 Discourse，我們一般把 GitHub 上的提交日誌作為工作好壞的證據。當然這不是說員工提交的日誌數量有指標或者其他什麼的，而僅僅作為員工出色工作的一種可追溯的依據。不管是公共專案或是私人專案，都算數。
也許你用 Asana 或 Basecamp （或同類產品）來進行管理。我本身不太在乎進度管理工具。重點是這些工具：
讓人們能夠記錄下他們所做的有用的事。不是“待辦”列表，而是“已完成”列表。
我不關心員工何時來上班，或者他們的時間表。不關心他們住在世界上的哪個地方（前提是他們網路暢通）。不關心他們怎麼工作。我也不打算微管理。如果你確實招聘到了最好的人，他們應該用產出來證明這點，然後展示他們的工作。
怎麼知道這有效呢？當你招來的人發現了什麼問題（或者局面完全崩潰了），他們會主動自己調整。你很放心地給他們許可權，無論是改變策略，甚至是犯錯誤，都是靠他們自己來負責，這時事情就能走上正軌了。
通過試用專案招聘
假設一位求職者輕鬆通過基本測試，有出色的履歷，文化高度契合，也順利通過電話視訊。是時候面試了，對嗎？
我見過很多求職者，上面說的所有環節面試都很棒，但是加入公司後，一旦到崗後卻完全無法勝任。即使你親自見過一個人，要評判他的職業道德和能力也是非常難的。
如果你想擺脫對面試的質疑，確定一個人到底能不能勝任，那就給他們一個試用專案（audition project）吧！在他們與你團隊中其他員工交談之前就讓他們做。我不是在說那種寬泛抽象的測試專案。而是現實世界中，今天在你實際產品中馬上要做的真實工作。這些測試專案就是你在平時要分給正式員工做的工作，這樣做也能減輕正式員工的壓力。
理想情況下，試用專案的評估應該是一個很小的臨時諮詢任務，最多耗時個把小時，並具有明確的任務說明。選擇一個幾天內能完成的小專案，或者最多一兩週。讓求職者選擇來辦公地點還是遠端工作。
我知道不是每個業務都可以分成小塊的工作單元，來分配給公司外面的人。但如果你不這麼做的話：
如果你沒法給厲害的求職者找到一個小型試用專案，也許你也沒有為現有員工合理規劃工作。
在 Stack Overflow，有我們的一些開源元件，我們經常給求職者機會，讓他們基於這些元件做開發，以實現我們預先想好的很多功能。那些能夠獨立工作，與我們清晰交流，並非常及時地釋出所需功能的人，顯然就是我們要找的人才。
如果試用專案進展良好，非常棒，那你現在有了一位高度符合條件的候選人，他明顯有能力完成任務，也完成了需要做的事。到目前為止，我見過的能勝任試用專案的求職者，全部都能勝任工作。我非常看重試用專案中的表現；這是求職者拿到 offer 之前接觸到的最接近現實的工作。如果誰都無法搞定試用專案，那麼僅僅會造成這個很小的諮詢工作失敗，相比於讓四五個人蔘與的全套面試流程付出的成本，孰優孰劣就非常明顯了。再不濟，你可以把這個專案傳給下一位厲害的求職者去做。
從你的社群中招聘
通過多次的經驗我發現，文化契合度比技能更能預示著成功。但是當團隊都不在同一個地方辦公，你如何才能建立這種文化呢？（注意這裡還遠遠談不上加深文化）
我意識到，並不是每個企業都有相應的社群，但如果你有更廣泛的使用者圈、開發群體或粉絲，無論何時，你應該拼命從這些群體中招聘。他們自然地傾向你這邊，由於與公司文化契合，完全拉到你公司的重力井。這些候選人與公司文化契合的機率出奇的高，這正是你想要的。
你的一些使用者為你的遊戲做過令人驚歎的改造嗎？在你們論壇中，有資深使用者每天回答別人的問題嗎？有工程師發現隱晦的安全漏洞並提醒你注意嗎？這些就是你應該致力去招聘的人。為了增加機會，你們可以早早開始培養新起之星，比如增加交流，提供特殊 offer，在他們當中培養名聲。
在 Discourse，我們的首位工程師就是按著招聘計劃，根據他在 GitHub 上面強大的開源貢獻。在 Stack Overflow，我們有一個長條的“受歡迎人”列表，這些人高度活躍在我們管理的站群。
如果你的創業公司很小，或者產品和市場契合，你仍然有選擇。有很多社群，就人們的型別和他們的交流方式而言，與你希望構建的相似。追隨他們吧。來一次令人信服的討論，關於你是如何開展工作的，他們如何能夠有機會幫助你塑造它。
有點反其道而行之，也可以嘗試看看你的領域或行業中，那些熱衷於吐槽現狀的社群。這可能有點難以說明你的情況，但如果你接觸到合適的人，你可以解釋，你的產品正是他們在市場中期待的。他們會立馬來幫助你讓產品做到極致。
每天使用公共通訊工具
當你有遠端工作者，溝通工具不該是僅僅他們參與的時候你才用，而應該一直使用，作為工作中很自然的部分。
不要在茶水間或者走廊會議中談重要資訊，除了現場偶爾聽到的人，沒人會受益。
每個擁有遠端工作者的公司會需要滿足這些基本要素：
實時通話
當你的團隊成員住在南美洲，你不可能走到他桌前，問他一個快速問題，或者在他最近的 checkin 中發現錯誤。 你需要一種方式能隨時聯絡到遠端團隊成員，可以很快得到回覆。對於所有的遠端開發者一直保持這樣，可能會有點衝突，Hipchat、 Slack、IM、IRC、一些基於 Web 的工具。重要的是每個人都持續使用，作為領導者你可能需要不斷地強化這個意識。
在 Discourse，目前我們是用 Slack 試驗，大家都很喜歡，但它發揮作用是因為我們全天都在 Slack 上面，交流想法，開創新的對話途徑，讀他人的評論等等。當人們遠端工作時，聊天是最重要的無處不在的溝通方式，所以在進一步合作前，你需要非常確定它運作順暢。
線上公告板
當然，你的遠端團隊可能知道專案細節，但所有其他的工作呢？他們如何找到這些東西，甚至知道它擺在第一位？你需要一個虛擬公告板，它不像對話那麼短暫：可以顯示公告、團隊週報和會議總結的地方。Discourse 正好提供這個服務，其他很多網站也擁有類似的功能。
你想要一些事能佔據郵件列表和線上討論區之間的空區。你應該能夠訂閱每個帖子到來時的郵件通知，或者通過 Web 檢視線上對話。每個人應該能獲得每週或每日的自動摘要。
有句話要注意：每次你收到類似這樣的郵件，最好發自內心地相信它包含著有用的資訊。一旦那些郵件僅僅淪為另一個“我有時間再讀那些東西”……你讓他人謊發警報多次，也毀了它。所以這裡請謹慎行事。在公共討論區分享的東西，應該是大家需要知道的。
它可以看起來像這樣：
語音和視訊通話
正如我喜歡 ASCII 一樣，有時見不著面的字元不足以捕捉文字背後人們的專注和感覺。當你發現自己來來回回傳送數 KB 的文字，仍然不滿意交流的清晰度，這時就應該灌輸一種“投靠語音”的反射性習慣。
永遠不要低估與其他人實際交談的作用。我知道，我知道，很多人投身程式設計的原因完全是想避免與其他人交談，但是忍受下我。沒有六小時以上的飛行，你壓根見不到你的遠端團隊，並且誰有那個時間呢？我現在有工作馬上要完成！
另一件比跳上飛機更好的事是使用 Skype 或者谷歌 Hangout 或同類產品，這樣能夠看到對方的肢體語言和臉部表情。如果你計劃定期語音和視訊通話，電話或郵件丟失的那些細微差別會蜂擁而來。我建議至少一週一次，這是最低限制；不一定要冗長的會議，但能幫助理解那些 checkin 背後的人們。
沒人比我還討厭會議和流程場面話，但你需要保持一定量的流程，同步維續著一幫鬆散連線的遠端團隊。看到人們實時互動是讓這成為可能的關鍵。
週一團隊狀態報告
每週一，你公司的每個團隊（即使只有一個）應該產生出一份簡明，總結性的概要：
上週我們做了什麼。
這周我們計劃做什麼。
阻塞我們的事情，或者我們所關注的事情。
這不一定非要是一份冗長的報告，事實上也不應該是。越簡明越好，但儘量列出所有關鍵點。每週一雷打不動地釋出在電子公告板上。現在，你有多少個“團隊”取決於你；我不認為這需要每個開發者去完成，但如果公司還很小，你可以這樣。
漸漸地，隨著機構擴大，人們斷開聯絡了。大家不知道其他人從事的工作，或他們的工作細節。
一份非常簡潔，高水準的關於上週團隊工作的概要讓問題迎刃而解。週一狀態報告對於小團隊充其量是一個 issue，然而這有助於非常簡練地覆蓋上週工作的點，即使只是五人團隊口頭上的報告。
會議記錄
任何時候你主導的可以認為是與他人的一次“會議”，做記錄！也就是說，以公告點的形式記錄下發生的事，那些不在場的遠端團隊成員就能從中受益 – 或至少了解到 – 接下來會發生的事。
再次強調，那些記錄不需要很長，如果你發現做會議記錄很累，那八成做錯了。幾句簡單的列項就足夠了。不需要記錄每個小細節，僅是大概的輪廓：誰參與？討論的話題？做的決定？下一步和工作項？
上述的都應該，當然，發帖到你的討論區，這樣每個人都會收到郵件自動通知。
除了這些，我見過一些特殊情景，讓遠端工作變得沒那麼理想：
頭腦風暴
這是大頭。如果你正在進行天馬行空的即興會議，很難實現遠端。人們實際到場，見到面，聽到聲音，看到他們的肢體語言，這更有利於快速反彈的想法，並找出廣泛的點子。你需要頻寬非常高、延遲非常低的個人連線，才能有效進行頭腦風暴。
好訊息是，至少以我在 Stack Overflow 和 Discourse 的經驗看，這種會議相當少見。你需要他們的時候，會在每年一度的線下活動，每個人為著來年更大的夢想，飛聚一起。
例如，在 Stack Overflow 的年會上，我們偏重投票多的公司價值，並建立我們稱之為“艱苦卓絕的目標”，即2010年成為世界前 50 網站。自那之後，目標實現了。讓每個人與團隊齊頭並進實現目標。
導師制
導師制需要一系列快速的來來回回的互動，經常性的被打斷，因為年輕工程師會詢問高階工程師對於工作的反饋。這對於遠端工作連線鬆散的溝通模式，不太匹配。
我們對此的“解決方法”是避免招聘需要大量指導的人。在 Stack Overflow 和 Discourse 的時候，我們傾向招聘經驗豐富的人，並非不相信年輕有才華的開發者（我們是相信的），而是因為遠端指導他們不太現實。從招聘人用於遠端工作的角度看，你或者能勝任……或者不能。我發現遠端工作良好的人，但如果在技術層面上存在很大的不對稱，會拖慢生產率。
如果你有意將年輕開發者培養成高階開發者，就需要規劃時間，使得他們能緊密合作。結對程式設計在這種情況就能受益了。
考慮到所有的利弊，想象未來的 20、40 或 60 年，數字工作是怎樣的，你覺得人們每天還會繼續花一兩個小時在上下班的路上嗎？
你認為招聘策略應該基於十年前的工作狀況，而不是十年後可能的工作狀況嗎？
以我們在 Discourse 和 Stack Overflow 的情況看，從全球招聘有著很大的戰略優勢。我相信遠端開發代表著工作的未來前景。如果我們得花少量時間弄明白如何召集遠端工作者，也許途中會犯一些錯，但這值得。未來近在眼前，何須等待？