PingCAP 的 5 年遠程辦公實踐

做者：黃東旭，PingCAP 聯合創始人兼 CTO。

前言

2020 年的春節註定是一個不平凡的春節，全國都在抗擊新型冠狀病毒肺炎。除了不出門，勤洗手，戴口罩之類的常規操做，咱們就在想，在這個大背景下，咱們還可以作哪些事情？考慮到春節假期臨近結束，返程的旅途中可能會加大傳染的機率，延長隔離時間、遠程在家辦公也許是普通羣衆能給國家在這場戰役中作的最大貢獻。然而在咱們國家，暫且不論別的行業，至少咱們所在的高科技行業尚未普及遠程辦公的文化，因此咱們在此將 PingCAP 實踐了近五年的工程師遠程辦公經驗介紹給你們。本文將盡可能少描述理念，而更多的從實踐方面講述咱們的落地經驗，以期在這樣的一個特殊的時刻幫助更多的朋友和公司儘快行動起來，爲國家爲社會貢獻一份咱們微薄的力量。

咱們已經經過實踐證實，在這個時代，至少對於相似軟件工程這樣的主要以腦力和創意爲主的工做，已經有足夠的方法論和基礎設施，讓遠程工做的效率不比傳統模式差，有時候甚至能有更好的產出（相信已經有同窗想起了早上擁擠的交通對心情和思惟的反作用）。下面咱們聊聊一些具體落地的經驗。

01 遠程辦公的管理哲學

遠程辦公在國外並非一件新鮮的事情。在硅谷，尤爲是新一代的科技公司幾乎都有遠程工做的基因，這背後有不少緣由在這篇文章中就不展開了，若是感興趣的朋友能夠看看來自 37 Signals 的 David Heinemeier Hansson 的《Remote》一書。對於咱們來講，PingCAP 從公司創建之初就開始踐行這個文化，主要出於這幾點緣由：一方面包括我在內的幾位聯合創始人都是工程師出身，自己對於效率比較有追求，自由的工做形式可以提升咱們的工做效率，同時咱們痛恨低效形式主義；另外一方面，對於一個初創的公司來講，咱們不但願人才由於地域的限制而不能加入咱們。

一個很好的例子是咱們的首席架構師 siddontang，也是咱們招聘的第一位員工，由於家庭緣由不但願來北京，過去的幾年一直都在珠海的家裏遠程工做（這篇 blog 詳細描述了他的親身經歷）。另一個很是重要的緣由是咱們的員工是全球分佈，基於開源的開發模式，因此一開始就注入了遠程工做的基因。

軟件工程是一項以腦力爲主要資源開展的工做，在現在高度發達的互聯網技術支撐下，實際上是自然適合遠程工做的，可是咱們爲何大多數時候以爲遠程工做不如集中工做效率高？除了遠程帶來的溝通協做障礙外，咱們認爲其實最根本的差別仍是在管理哲學上，是傾向於傳統監管的管理思惟仍是自驅的管理思惟，在 PingCAP，咱們在企業文化上一直倡導的是後者。爲此，咱們須要創建一個強大的願景驅動力，並落實在咱們的各類細節中，同時儘量爲同事們營造自由、開放、分享的工做氛圍。

幸運的是，這也和咱們從事的開源領域的工做方向完美契合。舉個例子，在 PingCAP 咱們歷來不進行任何形式的打卡，每週五咱們都有例行可是議題不限的員工 TGIF 分享 ，任何一位同事都有機會站在臺上分享本身的工做成果和心得，甚至咱們發給你們的周邊產品都是在設計、選材上一遍一遍的精挑細選，且限量供應，以期讓每個小夥伴感覺到溫暖和尊重。這一切的工做看似和咱們的遠程辦公沒有直接關係，可是實際上讓咱們一點一點地變成了一個脫離形式、高於形式而存在的強大的遠程組織。

02 目標和計劃管理*

若是問一個問題，對於工程師團隊來講，何時須要溝通最多？我想是制定計劃和目標的時候。

軟件工程遠程辦公咱們首先要解決的是咱們要創建遠程可操做的更加清晰、高效的目標和計劃管理。從宏觀層面說，在 PingCAP 咱們依賴的是 OKR 這個工具進行公司以及團隊的目標管理，OKR 是硅谷以及國內的不少互聯網公司愈來愈流行的目標管理工具。 通過探索，咱們認爲 OKR 是一個比較適合遠程工做團隊的目標管理工具，由於 OKR 相比 KPI 來講，首先更增強調由團隊成員共同制定團隊目標，這樣帶來的好處是易於讓整個團隊就目標和關鍵結果達成共識，始終保持團隊的目標導向一致。其次可以讓團隊成員更加明白作手頭上的事情對於團隊以及對於公司的意義，這一點對於遠程團隊尤其重要，極大的有利於促進部門與部門、人與人的協做，讓團隊更加具備總體性，最後，OKR 還有一個很重要的特色：透明，在咱們的實踐中，每一個團隊均可以看到別的團隊的 OKRs，你們在制定完各自團隊的 OKR 後，還須要在公司級別宣佈，確保你們都能瞭解。

從微觀層面說，例如一個具體的項目計劃制定和執行跟蹤，也須要同樣的透明。 咱們的實踐是項目的負責人爲每個大的項目創建一個全局的項目「地圖」，力求作到即便是半路加入的同窗，看到這個地圖後，就可以清楚的知道如今是什麼狀況，須要的資源的連接在哪，負責人是誰，風險點在哪。這個對於遠程工程團隊的管理者來講更是相當重要。下面是一個例子：

某個項目事項追蹤表

當咱們把咱們的目標和計劃可以清晰、高效、透明的在整個公司內部制定、發佈和管理起來，遠程辦公已經具有了初步的可操做性。

03 工欲善其事，必先利其器

既然咱們這裏更多的是討論實操，咱們接下來重點講一講軟件工程遠程辦公環境咱們所使用的工具。企業文化、目標管理咱們須要相對長時間的工做去逐漸創建，工具的引入則相對快速見效，也就是俗話說的，工欲善其事，必先利其器，使用良好的工具會讓事情事半功倍。

PingCAP 的主要產品 TiDB 是一個開源的數據庫，咱們研發的主要工做流都是構建在 Github 上面，徹底對社區公開。因此咱們的工具鏈也是以 Github 爲中心，串聯其它的工具，下面是完整的工具列表（這些工具不少都有國內的替代工具，若是公司不像 PingCAP 這種員工全球分佈的，能夠根據實際需求選擇）：

• GitHub：代碼託管，公開的 RFC，社區 Issue 反饋，產品發佈，Code Review 等。
• Zoom：在線會議。
• Slack：即時通信，機器人消息中樞。
• 微信、企業微信：即時通信（沒錯，咱們兩個都用，但以企業微信爲主）。
• 在線文檔：文檔協做，幻燈片，表格。
• 郵件，日曆。
• Confluence：內部的文檔，包括已成型的設計文檔（如內部的 RFC 文檔），Wiki 等。
• Jira：Bug 和 Milestone 跟蹤。
• Trello：看板，記錄一些重要客戶和事件的備忘。
• Jenkins：持續集成，daily build。

這裏經過一個小例子介紹一下咱們研發的工做流：

1. 假設咱們須要作一個新功能，從構思開始，可能第一個會使用的工具是在線文檔，負責的同事會草擬一個文檔，將大體的想法在其中描述，而後經過 Share 的功能，分享給相關的同事，大多數時候這些設計文檔都會 share 到全部的工程師都會在的郵件組裏，任何人均可以上去評論或者編輯。
2. 文檔通過溝通討論定稿以後（溝通環節我會在下面一節重點介紹），會同步到 Confluence 和 GitHub 中（若是能夠公開的話，英文版會發到 GitHub 上）。
3. 接着該項目將被拆分紅多個子項目，經過 JIRA 分配到具體的人，完成後直接提交到 GitHub 上，項目的該模塊的 Reviewer（也包括 Maintainer）會參與 Code Review，收集到兩個 LGTM（Looks good to me） 並經過各類持續集成工具的測試後，最終合併到主幹。

修 Bug 的流程也相似，值得一提的是咱們開發了一個 bot，用於同步 GitHub 中來自社區的 Issue 到內部的 JIRA 中。

優秀工程師的創造力是無窮的，尤爲在遠程工做的背景下，咱們很是鼓勵工程師經過自制工具來提高工做的效率。

除了上面提到的 Issue 機器人，咱們的Chaos 測試（最近已經開源，CI/CD，甚至包括社交網絡上簡單的動態輿情監測，都有自動化的工具在作。還有小夥伴們經過自動化的手段優化本身工做中的一些流程，舉幾個好玩的例子：disksing 同窗使用 App Script 自動生成本身的週報(http://disksing.com/review-re... ；siddontang 同窗本身寫了個小工具 github-cli (https://github.com/siddontang... 來高效的追蹤關注的 Github 項目的動態；我用 Python 寫了一個小腳本，每日收集 Trello 上指定 Board 內的卡片的更新，並給我彙總發郵件……這樣的例子數不勝數，有時候真是很佩服你們想象力和動手能力，咱們很是堅決地鼓勵你們作這些事情。

咱們的 IFTTT 機器人在收集說起 TiDB、PingCAP 的推文

由咱們的 bot 同步的 Github Issue

天天下班以前自動生成的當天動態報告

每週週會以前自動生成的 Weekly Report

提早根據模版生成出來的我的週報

提醒你們準備週報的企業微信機器人

SRE 機器人自動 Merge PR 並 Cherry-pick 到 Release 分支

介紹了這麼多好玩的東西，其實我想表達的是：對於遠程工做來講，能交給機器作的，儘可能不要人來作，自動化是相當重要的。尤爲對於線上的協做來講，多一我的的參與就意味着多一份溝通成本。我對於工程師團隊選擇開發相關的效率工具，有幾個建議：

1. 選擇有開放 API 的工具，方便寫 bot，造成協同效應。
2. 切忌諱過多過雜，選擇幾個好用的，將其用透。
3. 使用 Slack 之類的 IM 做爲各類工具的 Message Hub，儘量作到在一個地方就能一目瞭然事情的狀態。

另外就像上面提到的，因爲咱們也有一些海外的同事、客戶以及海外社區溝通的需求，因此主要選用的工具基本都是國際上比較通用的，若是大家公司的業務都在國內的話，這些工具基本均可以找到國內的或者私有部署的替代方案，例如 ONES，Tower，Gitlab 等。

04 對遠程友好的溝通和協做機制

若是說上面聊的工具只是基礎的話，那麼遠程工做最大的挑戰就是溝通了。對於一個成熟的團隊來講良好的溝通必定是必不可少的，甚至溝通的品質決定了作事情的品質。並非說由於遠程工做由於條件約束，就少溝通甚至不溝通了，相反的，在這種環境下咱們的溝通可能會更多更細緻，只是形式並不只僅限於面對面的會議這種形式而已。

在聊咱們的溝通實踐以前，我想先聊聊溝通的意義，首先我認爲溝通最重要的意義在於：信息拉平。對於一個遠程的團隊來講，用大白話來講也就是：你們須要互相都知道本身該幹嗎，團隊正在幹嗎以及該幹嗎。這件事情在不少公司是經過大大小小的會議，或者甚至吼一嗓子完成的。可是在一個遠程的團隊中，溝通這件事情須要作得更加的透明。

即便是遠程，大部分時候會議仍然是最高效的信息拉平方式，相似 Zoom 這樣的視頻會議工具已經提供了很好的平臺，並且智能手機和移動互聯網的普及也讓會議的參與變得更加的便捷。這裏多提一句，PingCAP 是 Zoom 的重度用戶（也是企業客戶），Zoom 的用戶體驗真的很是棒，咱們即便是全公司級別的會議，也都是經過 Zoom 完成的（昨天剛得知一個使人振奮的消息，也給 Zoom 作個友情廣告，目前國內用戶訪問 zoom.com.cn 能夠免費不限時長使用，直到疫情獲得有效控制之日）。

在 PingCAP 從形式上來講，由於會議基本都會有遠程的同窗參與，因此默認都是線上會議。

從內容上來講，大概有兩種會議，一種是例會，一種是具體業務的溝通會。相信和別的公司也沒什麼不同，我這裏聊聊咱們以爲比較好的一些實踐：

在 PingCAP 各個團隊（包括虛擬團隊）大大小小必定都會有例會，一般以周爲單位，有些比較重要且緊急的項目會以天爲單位，會議的時間和長度也不必定。週會是一個很好的機會能讓團隊成員互相瞭解你們在幹嗎，對於 Manager 也能很好的知道方向有沒有歪，進度是否正常。

另一點，分享一些關於會議的實踐：

1. 對於相似例會這種偏信息拉平的會議，Manager 最好不要直接在這類會議上作決策。由於不少信息多是剛接收到立刻作決策不必定是通過深入的思考，另外一方面信息可能不全面，還須要進一步的跨團隊溝通。
2. 善用 Calendar。我建議研發團隊內部將 Calendar 能夠別人可見（這點上財務，商務，高管團隊須要酌情考慮），經過訂閱和你相關的同事的 Calendar 是一個也是一個很好的信息拉平渠道。
3. 會議前發 Agenda，會議後造成 Meeting notes 發給參會的人，並記錄在 Wiki 中。
4. 儘可能少開大會長會。Amazon 的「兩個 Pizza 原則」也一樣適應於開會（這點提及來簡單，其實作起來很困難，尤爲在跨團隊協做上，咱們也在努力）。

這裏說幾個咱們親身經歷的坑。由於遠程的關係，在 PingCAP 咱們一直以來要求儘量的使用文檔進行溝通，咱們確實在早期很嚴格的踐行了，可是那個時候咱們重度依賴在線文檔，因而陷入了一個問題：協同功能很棒， 可是索引功能很弱。因而不少時候就出現了，可能記錄某件事情的文檔找不到了，或者有多個文檔（不少甚至只是討論稿）在描述同一個事情。

爲了解決這個問題，咱們後來引入了 Confluence，用作團隊 Wiki，主要起到信息索引和搜索的功能，咱們很是依賴 Confluence，而且玩出了不少花樣，這裏我只舉幾個最佳實踐的例子：

1. 給每一個團隊建立團隊的 Page（相似前面提到的「地圖」的概念）索引一切和這個團隊相關的內容，讓新人可以一目瞭然。例以下面是來自 TiKV 團隊的例子：

1. 團隊週報和我的週報，每一個團隊的週報會一層層的彙總和概括，在每週的高管例會前發出。全部的週報都在 Confluence 裏被索引。
2. Logbook，這個是咱們比較有意思的東西，對於一些帶有探索性質的工做，例如一些小實驗，性能測試，一些特殊場景的優化等等。咱們也會詳細的記錄下來，造成一個個實驗 logbook，這些 logbooks 能夠經過關鍵字被 Confluence 的檢索到，一是做爲將來實現或者輸出成文章的素材，二是防止未來作重複的工做。

在內部協做全面引入 Confluence 後，咱們的文檔信息碎片的問題獲得了比較大的緩解，惟一美中不足的是 Confluence 的移動端作得實在不盡如人意，但願 Atlassian 團隊將來能改進。 

另外一個坑來自於 IM 工具的選擇。這個可能也不是坑，更多的是因爲微信平臺自己不是爲了辦公場景設計的帶來的問題。因爲咱們多數的國內客戶都傾向於使用微信做爲溝通的渠道，做爲一個 toB 企業，咱們必須去適應這個現實（好比我手機上有幾千個微信羣），這個問題致使了咱們 IM 溝通的碎片化，而遠程工做的環境會進一步放大這個問題。可能同一件事情，有些同窗看着微信，有些同窗看着 Slack，這就致使了消息不對稱。再者微信是一個封閉系統，沒有 Open API，很難經過技術的手段同步到一個平臺。另外一個問題是，微信這種用法，工做和生活很難分開，有時候很使人苦惱。這個問題經過引入企業微信獲得了必定的緩解，可是由於企業微信又是一個新的 IM，也是一個封閉系統，信息碎片化的問題和海外同事使用習慣上的問題仍然存在。在這個方面，咱們仍然在探索。

05 遠程辦公環境下的自我管理

遠程辦公還有一個很重要的方面是我的的心理建設和自我管理。這點因人而異，其實不少人不太適合長期 work from home，例如我遠程工做的時候必定要從家走出來，去個咖啡廳或者 WeWork 之類的地方纔能進入工做狀態，可是咱們的首席架構師就能夠五年如一日將他家的書房當成辦公室。人無疑是最重要的一環，不過在這篇文章中，我並不想展開太多，有機會再詳細聊聊，這篇文章我但願儘可能關注比較普適的方法。

在遠程環境下，須要工做者可以克服孤獨感，而且因爲沒有同事在身邊，須要比較強大的自律精神克服倦怠感。在這點上，我推薦使用一些我的時間管理工具，例如番茄鍾，日曆等工具。可是和公司選用工具同樣，切忌貪多，選擇一個用透最好。另外在生活中也保持一個規律的做息習慣也會頗有幫助，這點在上面引用的 siddontang 那篇博客 中有很好的闡述。

另一點比較重要的是，不少工程師多是一個比較內向的性格，遇到困難的時候，尤爲是在遠程的環境下，容易鑽牛角尖。這種狀況下，必定切記要主動的求助和溝通，甚至可能須要比面對面的環境下更加頻繁的溝通。

對於管理者來講，要作到這點，須要將任務拆解得足夠細，在前期溝通須要反覆確認是否和遠程工做的同窗達成一致，這個環節須要很是的重視。

06 Online and Offline（線上與線下）

PingCAP 並非一個完全的每一個人都遠程辦公的公司，咱們仍然在各個大城市有咱們的辦公室（北京、上海、廣州、深圳、成都、杭州、硅谷）。就像上一節說的，遠程工做看起來很美，可是可能也並不適合每個人。人是社會化動物，不少時候咱們仍然須要從線上走到線下，和同事一塊兒吃頓飯，聊個天。由於這點，咱們的解法是：PingCAP 使用遠程的工做方式和文化，可是仍然保留着各地的辦公室，因此咱們有一個不成文的慣例，當每一個城市的員工超過 4 我的的時候，就能夠找個辦公室了。

在各地 Office 的運營上，也是比較有 PingCAP 的特點的。不少傳統公司的各地子公司一般是定位特殊的辦事處，例如銷售，測試，研發等。可是因爲咱們的遠程辦公文化，咱們各地的 Office 其實更像是一個虛擬的組織，也就是說可能同一個團隊的同窗會隸屬於不一樣的 Office，或者反過來，每個分公司均可能會有不一樣職能、不一樣團隊的同窗。

這樣是有好處的：

1. 做爲一個 toB 公司，咱們國內的客戶也主要分佈在幾個主要城市，在客戶當地有分公司能更方便的開展客戶支持和市場活動。
2. 在同一個城市的辦公室內有不一樣部門的同事，有助與構建更多樣化且健康的文化，也能更順暢的進行跨團隊合做。

辦公室的 Manager 更偏向於當地辦公室具體事務和活動的管理和組織，另外每一個 Office 都會有一個行政來處理平常的事務。因此，一般咱們的 Team building 會有幾種：

1. 當地 Office 本身會有 TB 的經費，能夠本身組織活動。
2. 每當團隊出差到同一個地方的時候，組織團隊的 TB（固然，咱們大多數是程序員，基本就是吃吃吃）。

這裏提到了出差，順便介紹一下，咱們建議遠程研發團隊的 Managers 大概一個月須要儘可能和團隊的大多數成員 Face to Face 的見一次面，這些行程一般能夠和客戶拜訪安排在一塊兒。線下的溝通可讓線上的交流更加順暢。

總得來講，遠程辦公並不是十全十美，像咱們這樣的科技公司具有自然的文化和規制土壤，但仍然有不少地方有繼續改進的空間，歡迎你們給咱們多提建議。很高興在國內遠程辦公文化還沒有普及之時，可以用這麼長的篇幅爲你們分享一點落地經驗。在這個特殊時期，咱們在家不動的同時勞動創造價值，也算是爲社會作了點微小的貢獻 !