相信越來越多的人聽過“分佈式團隊”的說法，在當下 Freelancer 逐漸流行的情況下，“分佈式團隊”也正成為一種趨勢——一群人分佈在不同的國家或地區，員工也可以在任何地方進行工作。
而相較之下，近期因為新冠疫情蔓延而倒逼形成的無數個短期“遠程協作團隊”中，一些團隊 Leader 或感不適，不適的原因有很多，員工自驅力、遠程期間的目標如何統一、每日如何 Check 大家的工作成效……這些問題中，有的已被較為成熟的“分佈式團隊”經歷並驗證過，他們已摸索出一套行之有效的方法論來解決。
PingCAP 在工程師遠程辦公經驗上實踐了快五年，對於 CTO 黃東旭來說，PingCAP 和他自己都積累了一套“遠程辦公管理哲學”。為了將這套哲學思考及經驗分享給大家，特別是遠程新手團隊，幫助大家更快更高效地落地“遠程協作”，TGO 鯤鵬會對黃東旭在《鯤鵬說》直播欄目中分享的內容進行了全文梳理（有部分內容刪減），供大家學習、參考。
作者 | 黃東旭
整理 | Cherry Cao
獲取完整版分享 PPT，請關注本公眾號回覆“遠程辦公”查收下載鏈接。
下方為 B 站指路鏈接，想在 B 站觀看的朋友千萬別錯過「極客時間 B 站官方賬號」：https://www.bilibili.com/video/av87391984
我們為什麼擁抱“遠程辦公”？
PingCAP 從公司建立之初，就是一家 Remote（遠程）的公司。我們三位創始人（劉奇、崔秋、我），都是程序員出身，都對“打卡”等循規蹈矩的形式主義有些痛恨。即使我們現在在北京、上海、杭州等各大城市都有辦公室，但依然有很多小夥伴是遠程在家辦公。在我看來，在哪上班沒有什麼區別，一個牛的程序員可以頂幾十個普通程序員，但牛的人不一定只在北京、上海這種大城市。因此，PingCAP 本身其實是一家“分佈式公司”。
曾經就有一個例子發生在我們的面試環節：PingCAP 的首席架構師唐劉非常厲害，在面試結束時，他提到他的老家在珠海，因此就特別問我說，是不是一定要搬來北京上班。我當時說，“你在哪裡上班這都不算什麼，在哪上班不都一樣嗎！”所以，他後來加入了 PingCAP，這件事情後來也成為了一段佳話。
那總的來說，我們為什麼擁抱“遠程辦公”呢？
1、人才。遠程辦公這個事情，如果你把放在公司招聘的條件裡，它其實是對人才的一個特別吸引點。當然，因為我今天的整個分享僅限於研發團隊，偏運營或偏向外拓展的一些崗位或團隊可能不太適用這個背景條件。
2、提升效率。“遠程辦公”能讓員工更專注於任務，減少中斷。從 PingCAP 的實踐經驗來看，遠程辦公團隊的效率其實高於在線下辦公室裡的協作效率，因為大家會更方便地專注於手頭上的工作。
3、節省隱形成本。至少節約了通勤、辦公室成本和擴張新市場的成本，所以其實對我們來說，遠程辦公其實是非常正確的一個選擇。然後這裡有個問題，就是什麼樣的公司適合和什麼樣的公司不適合遠程？我個人覺得，如果你的公司完全是腦力勞動者為主，或者說是基於創意的如設計師、研發這樣的團隊，其實是我覺得是更適合遠程的。
大家如果對美國的公司比較熟悉會發現，基本上美國現在絕大多數的公司（尤其科技公司），其實全都是遠程辦公了。不遠程的話，一是招不到人，二是在應聘者看來，你的公司一點都不酷，別人不會去的。
所以，今天我會更多的從團隊的管理者、創始人或者高管團隊的角度跟大家介紹。如果你想要在未來打造一個長期的遠程團隊、遠程文化的公司，或者說一個更敏捷的公司，或者說你的研發團隊，想去模仿像我們這樣的模式的話，你應該從哪些方面去思考，去重點看哪些東西，而不是簡單地就教你 Slide 或者某些工具該怎麼用。
工具這種東西都很簡單，但關鍵是內功心法。
或者說，當你遠程的時候，你該怎麼去跟進這些事情的進度、如何去溝通開會、重要的流程應該怎樣去管理……我認為這些東西是更重要的。所以，我們在最早期的時候就思考了一個問題（包括大家也可以思考一下），我們自己的團隊、我們的公司、我們的產品最核心的競爭力是什麼？
構建遠程友好的企業文化
後來我們思來想去，核心競爭力並不是我們數據庫技術有多牛。其實大家競爭的就是人才，一切事情都是人做的。
所以，當你的公司把人放在最高的位置的時候，公司的制度怎麼設計，做事情的某些方式是不是符合人的直覺甚至是不是反人類……這很重要。PingCAP 目前整個公司的規模近 300 人，研發團隊超過總人數的 2/3，我不確定規模更大公司的適用度，但至少當前 PingCAP 用這套“遠程管理”方法論 work 得很好。
另外在招聘上我們也有一個原則——我寧可用花兩個人的錢去招一個特別牛的人才，因為牛的人可能能迅速 cover 住原本三個人的工作。 我寧可招不到，也不太喜歡降低招聘的標準，也不希望招一個與我們文化、思考問題的方式、氣質不太一樣的人。
在招聘這一關上，有很多公司總說為什麼招不到特別好的人才。其實很多時候，每個人口中都說重視，重視招聘或重視人才。但你可以去看看 CEO 或者 CTO 的時間表，你一天中有多少時間花在面試上的？
遠程環境下的
組織結構與制度原則
同時，只有人才是不足夠的，還必須將他放到一個好的組織架構下，才能很好地發揮他的才華。PingCAP 從公司創立開始，我和劉奇就在想，我們應該做一個什麼樣的公司？
既然是程序員，我們就應該做一家“分佈式系統公司”。然後我們就開始思考，分佈式系統有什麼特點，例如如何”避免單點“，哪些分層測試能調，什麼樣的系統能 scale，什麼樣系統不能 scale……我們最後的思考是，一切依賴人的系統都是不能 scale 的。比如，做一件關鍵的事情，做一家牛的公司或一個牛的產品，如果依賴的是一個特別牛的程序員或特別牛的 CEO，這個事情就是不能 scale 的。
這個背後的邏輯是，你在做任何組織架構調整時，一定儘量避免成為單點。換句話說，一個人要升級成 Manager 或團隊 leader，他最重要的能力，是要把自己的能力賦予別人。我不希望作為 Manager 或團隊 leader，他只有個人能力特別強，組織能力特別好，或者說他把團隊管得特別好。這些在我們 OKR 裡其實都不是最重要的，
最重要的能力之一是賦能。所以，我們去做員工個人考核的時候，對於團隊 Manager 的考核標準是，有沒有培養出優秀的後輩。或者說，在每個人工作時，一個很高優先級的後臺任務，應該是想著如何培養接班人。其實這是很特殊的文化，至少是我們自己摸索出來的。
PingCAP 的組織架構更傾向於建立比較機動的小團隊，使用小團隊協作。
當然，我們會有比較大的虛擬團隊，比如說 TiDB 的 SQL 層、存儲引擎層等等，每個團隊 30-50 人，但每天協作的小夥伴可能也就三五個人。因此，對於這種大的虛擬團隊，我們內部其實還會再做一次二級劃分，就是儘可能讓每一個小夥伴不做太多跨團隊的工作，並且儘可能減少每人之間跨團隊的工作。
另外，組織架構要儘可能扁平。在 PingCAP 內部，從一線 Engineer 到我，一般就兩層職級關係，中間會有一些 Manager 或 TechLead。所以，我們的目標管理和績效考核其實是是分開的。
在目標管理和績效考核中，我一直認為，OKR 不是 KPI，不能用來考核。有些同學會（在彈幕裡）說，公司在提交考核中寫了 OKR，但每次落地時候都感覺和 KPI 差不多。這就是明顯把 OKR 用錯的例子。很多時候你會發現，KR（Key Results）和 O（Objections）並不完全對等，比如 KR 完成但 O 沒達成，或者 O 完成了但 KR 沒實現。
那麼，推 KPI 的“劣勢”和推 OKR 的“優勢”各是什麼呢？
從我的經驗來看，第一，如果團隊每個人對自己的 KPI 拆解的不太好，就有可能會發生跨團隊“打架”的情況。當 KPI 出現“打架”情況的時候，一定是員工各掃門前雪，就會有各種各樣的內耗。第二，在推行 KPI 的時候，一線的員工其實對 KPI 為什麼是這個樣子很難理解，然後大家的目標可能就變成了，我要完成 KPI。
所以對比之下，OKR 的好處之一就是 OKR 的制定過程和背後的邏輯關係，包括每項大的 OKR 拆成小的 OKR，這背後一定是全員參與的。
整體來說，不管是 OKR 還是 KPI，尤其對於一個遠程團隊或像 PingCAP 這樣的敏捷團隊來說，在目標管理這件事上，“開放透明、讓每個人都能理解目標背後拆解的原因是什麼”，每天做事的時候，整個公司的大目標是不是往前推進的，這個其實是我覺得特別重要的。
千萬不要把考核或者升職加薪和 KPI、OKR 綁在一起。我們整個考核體系其實是另外一套完全的不同的考核體系。也就是說，可能你團隊的 OKR 完成一塌糊塗，但這個人照樣升職加薪。我分享了一篇特別好的對工程師團隊績效考核的文章，當時看到的時候特別有感觸，推薦大家也看看（文章鏈接：https://blog.pragmaticengineer.com/performance-reviews-for-software-engineers/）。
遠程工作企業制度
像我們這樣的組織，在做規則制定的時候有兩個原則，
- 一是基於「信任」而不是「監督」的角度做規則的設定；
- 二是一定要公平，規則設定以後，不管你是 CEO 還是創始人，還是一線員工，都要遵守。
以 PingCAP 為例，PingCAP 的分公司（各地 Office）其實是作為虛擬組織存在，Office Manager 的職責更偏行政（office manager 本身可能也負責管理其他職能團隊，也屬於其他團隊的 TechLead）。
在遠程協作中，如果工程師對任務拆解得不夠好，或者中層管理對任務的 Trace（跟蹤）能力不強，任務拆解粒度不夠細或不科學，就很容易發生崩盤，團隊一下就散了。
所以，我們對腰部力量的管理或者說能力的要求非常高。我覺得在一個實行遠程辦公的公司裡，中層腰部力量很重要。
去年對我影響最深的一個思維方式是“抓重點”。把一個事情的重點抓對了，你就會發現有的時候其實能事半功倍，所以你想的時間比較長，做預測的時間就會短很多。
我教大家兩個鍛鍊“抓重點”能力的方法：
- 你直接思考手頭上的事情，如果你只挑一件事情做，會選哪件？
- 其他事都不做了又會怎麼樣？
你把這些利弊想清楚，就會發現很多動作不會“走形”了。
很多時候，不挖到最下面是挖不出水的，但很多公司都是左一鏟右一鏟，這也是有些公司為什麼會死掉的一個原因。所以大家可以去看，一個公司快死的徵兆，可能就是它開始去做 10 條（虛擬數詞）產品線了。
第二，有很多管理者比較喜歡關注細節，但我個人不太關注特別的細節。你只要告訴我，對於這件事情你覺得最大的風險點是什麼？ 你把風險能夠跟你的老闆說清楚，或者說你作為老闆考核員工的時候，他能把這個事情的風險 ABC 能說清楚的時候，就夠了。一件事情，最重要的重點是風險。
第三，遠程團隊因為線上聯絡多於線下，所以信息傳達可能會存在失真的情況。特別是在制定戰略的時候，隨著層級之間下達而產生的信息降級，可能很容易產生事情執行過程中，走著走著就走偏了。這裡，我也提供一個很接地氣的經驗，叫“抓頭抓尾”。
所謂“抓頭抓尾”，就是指傳達事情的時候，第一步是跟第一級高管說清楚要這麼做，三天以後找一個一線的小夥伴也聊一聊，你覺得這個事情你怎麼看？如果他的說法和高管傳達的不一樣，說明中間肯定有地方脫節了。然後你再去反向遞歸哪一層出現了失真。
這個方法很適用，前幾年 PingCAP 會因為信息失真發生很多問題，原因就是很多中層在“信息拉平”上的能力還沒有提升上來，後來當把信息拉平對齊的時候，會發現大家真的能一條心，執行效率和方向就都對了。
第四，Be a coach。這一點其實是對管理者的，我剛剛也說了，你最重要的能力是去教會下屬。但如何評估學和教的效果？比如今天你聽了這堂課，那麼我建議你回去是不是可以開一個分享會，專門分享今天我們講的遠程辦公實踐，如果你分享的東西你的小夥伴聽懂了，那麼我覺得你是真聽懂了。
遠程環境下的溝通實踐
第一，透明。第二，結論文檔化。第三，「飽和式」溝通。
透明這個詞有時候很難量化，或者用一個具體事情評估公司的透明度。比如你的產品說明文檔沒有組織也沒人維護，其實這樣的透明是沒有意義的。
所以我覺得：
- 一是所有結論性的內容最後都要落成文檔；
- 二是要求文檔必須能在類似 Confulence（專業的企業知識管理與協同軟件，也可以用於構建企業 wiki）的系統裡能索引到；
- 三是每一個項目，尤其是一級項目，都必須有一個巨大的“作戰地圖”，在這個地圖中，你能看到所有的主任務、每項主任務對應的負責人、事情完成的進度、這個項目對公司整體的影響到底有多少……所有的負責人每天都會更新這個“作戰地圖”或“文檔”，項目成員可以直接在文檔中修改內容，或者可以直接做一些 Comments。 以項目來驅動時，最重要的一點就是構建“作戰地圖”。
另外一個工具層面的 Tips 就是工作日曆。
我一般會訂閱一線管理團隊的日曆，我會看到大家這幾天的事項，然後查看哪些會議是我需要參加。這也是透明的一部分。特別是在工程師團隊，作為 Leader，有些事情和信息你是要去推送的，但有些事情應該是用“拉取“的方式，有效做到“推拉平衡”。
同時，遠程團隊的遠程會議禮儀也很重要。
第一，我建議大家會前發 Agenda，會後發 Meeting Notes。特別是在線上做頭腦風暴的話，我們一般會用 Google 或石墨這類在線共享文檔工具，將提前需要討論的內容先報一輪。
第二，忌開大會和長會。我們內部有一個要求，一件事情一句話能說明白，或能用大白話講出來的是最好的，不要講一大堆理論。當然，有時候冗餘的會議也有必要，因為在遠程的時候，信息拉平很重要，你要確保別人跟你想的是一樣的。
團隊至少以周為單位進行例會，每個人同步各自的進展，但切記不要在這類會議上做重要決策。有時候有些 Manager 會犯這個錯誤，就是在會議上直接對某些事情下結論。這裡想說的是，做技術側的管理層一定不要憑感覺做決策，區分好 Fact 和 Feeling，接到信息之後，回去想清楚了再做決策通報。不要一拍腦袋說幹，一拍腦袋說不幹，這樣對公司對工作都不太負責。
另外，我們每月都有一個公司層面的全員大會（All-hands），在這個會上，會由一個人或一個團隊給大家介紹他們做了一件什麼有意思的事情。我們比較 Open 的一個實踐是，高管團隊和創始人也會對匿名系統中收集上來的員工提問進行答疑，我們一般會挑選匿名系統中員工“點贊”（或頂上去）數排名前 5 的問題來回答。如果你的問題排在第 5 名之後，也可以在會議現場“非匿名”的舉手提問。
工具選⽤
PingCAP 主要會用到這樣一些工具：
- GitHub：代碼託管，公開的 RFC，社區 Issue 反饋，產品發佈，Code Review 等。
- Zoom：在線會議。
- Slack：即時通訊，機器人消息中樞。
- 微信、企業微信：即時通訊（沒錯，我們兩個都用，但以企業微信為主）。
- 在線文檔：文檔協作，幻燈片，表格。
- 郵件，日曆。
- Confluence：內部的文檔，包括已成型的設計文檔（如內部的 RFC 文檔），Wiki 等。
- Jira：Bug 和 Milestone 跟蹤。
- Trello：看板，記錄一些重要客戶和事件的備忘。
- Jenkins：持續集成，daily build。
在遠程辦公環境下，規章制度一定不是靠人去 Follow 和 Trace，所以我覺得，我們至少在研發上是非常依賴一些自動化的工具，在很多的流程上都用“機器人”來解決。因為遠程的時候還需要很多時候藉助人和人溝通的話，效率是非常低的。我們有非常多的“機器人”，比如“測試機器人”、“合併代碼機器人”等等，以後有機會可以專門就工具的問題再和大家做一個分享。
對遠程工作者的
一些建議和“坑”
最後，是一些小 Tips 讓大家在這幾天的遠程辦公中能夠更快的適應。
一、保持規律的作息，有儀式感的工作。一定不要躺著開會，這也是一種會議禮儀。
二、善用日曆來管理自己的時間。我覺得儘可能地用日曆把你的時間規劃好，每一個小時你要專注在什麼事情上。
三、最好能有獨立的辦公場所。
同時，遠程工作中還會有⼀些常見的“坑”：
一、信息碎片化的問題，各種通訊工具上的信息冗餘問題。
二、過勞，遠程工作情況下，工作和生活沒辦法分的太開，所以一個普遍的感受，是感覺在家比在辦公室辦公更累，過勞大家也需要注意。
三、孤獨感，為什麼 PingCAP 在各個地方要有辦公室？因為至少讓大家在精神上有見面的機會，能定期吃個飯，減少孤獨感。
四、線上文字溝通時的情緒管理，線上文字溝通的時候，最大的問題就是“沒有感情”。比如說你再打出一個呵呵一個這樣的這種詞的時候，對方會揣測你的。所以有時候要多注意文字細節，多站在多方的角度上想話應該怎麼說。
閱讀更多 TGO鯤鵬會 的文章
