前言
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。
這裏通過一個小例子介紹一下我們研發的工作流：
-
假設我們需要做一個新功能，從構思開始，可能第一個會使用的工具是在線文檔，負責的同事會草擬一個文檔，將大致的想法在其中描述，然後通過 Share 的功能，分享給相關的同事，大多數時候這些設計文檔都會 share 到所有的工程師都會在的郵件組裏，任何人都可以上去評論或者編輯。
-
文檔經過溝通討論定稿之後（溝通環節我會在下面一節重點介紹），會同步到 Confluence 和 GitHub 中（如果可以公開的話，英文版會發到 GitHub 上）。
-
接着該項目將被拆分成多個子項目，通過 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-recorder/) ；siddontang 同學自己寫了個小工具 github-cli (https://github.com/siddontang/github-cli) 來高效的追蹤關注的 Github 項目的動態；我用 Python 寫了一個小腳本，每日收集 Trello 上指定 Board 內的卡片的更新，並給我彙總發郵件……這樣的例子數不勝數，有時候真是很佩服大家想象力和動手能力，我們非常堅定地鼓勵大家做這些事情。
介紹了這麼多好玩的東西，其實我想表達的是：對於遠程工作來說，能交給機器做的，儘量不要人來做，自動化是至關重要的。尤其對於線上的協作來說，多一個人的參與就意味着多一份溝通成本。我對於工程師團隊選擇開發相關的效率工具，有幾個建議：
-
選擇有開放 API 的工具，方便寫 bot，形成協同效應。
-
切忌諱過多過雜，選擇幾個好用的，將其用透。
-
使用 Slack 之類的 IM 作爲各種工具的 Message Hub，儘可能做到在一個地方就能一目瞭然事情的狀態。
另外就像上面提到的，由於我們也有一些海外的同事、客戶以及海外社區溝通的需求，所以主要選用的工具基本都是國際上比較通用的，如果你們公司的業務都在國內的話，這些工具基本都可以找到國內的或者私有部署的替代方案，例如 ONES，Tower，Gitlab 等。
04 對遠程友好的溝通和協作機制
如果說上面聊的工具只是基礎的話，那麼遠程工作最大的挑戰就是溝通了。對於一個成熟的團隊來說良好的溝通一定是必不可少的，甚至溝通的品質決定了做事情的品質。並不是說因爲遠程工作因爲條件約束，就少溝通甚至不溝通了，相反的，在這種環境下我們的溝通可能會更多更細緻，只是形式並不僅僅限於面對面的會議這種形式而已。
在聊我們的溝通實踐之前，我想先聊聊溝通的意義，首先我認爲溝通最重要的意義在於：信息拉平。對於一個遠程的團隊來說，用大白話來說也就是：大家需要互相都知道自己該幹嘛，團隊正在幹嘛以及該幹嘛。這件事情在很多公司是通過大大小小的會議，或者甚至吼一嗓子完成的。但是在一個遠程的團隊中，溝通這件事情需要做得更加的透明。
即使是遠程，大部分時候會議仍然是最高效的信息拉平方式，類似 Zoom 這樣的視頻會議工具已經提供了很好的平臺，而且智能手機和移動互聯網的普及也讓會議的參與變得更加的便捷。這裏多提一句，PingCAP 是 Zoom 的重度用戶（也是企業客戶），Zoom 的用戶體驗真的非常棒，我們即使是全公司級別的會議，也都是通過 Zoom 完成的（昨天剛得知一個令人振奮的消息，也給 Zoom 做個友情廣告，目前國內用戶訪問 zoom.com.cn 可以免費不限時長使用，直到疫情得到有效控制之日）。
在 PingCAP 從形式上來說，因爲會議基本都會有遠程的同學參與，所以默認都是線上會議。
從內容上來說，大概有兩種會議，一種是例會，一種是具體業務的溝通會。相信和別的公司也沒什麼不一樣，我這裏聊聊我們覺得比較好的一些實踐：
在 PingCAP 各個團隊（包括虛擬團隊）大大小小一定都會有例會，通常以周爲單位，有些比較重要且緊急的項目會以天爲單位，會議的時間和長度也不一定。週會是一個很好的機會能讓團隊成員互相瞭解大家在幹嘛，對於 Manager 也能很好的知道方向有沒有歪，進度是否正常。
另外一點，分享一些關於會議的實踐：
-
對於類似例會這種偏信息拉平的會議，Manager 最好不要直接在這類會議上做決策。因爲很多信息可能是剛接收到馬上做決策不一定是經過深刻的思考，另一方面信息可能不全面，還需要進一步的跨團隊溝通。
-
善用 Calendar。我建議研發團隊內部將 Calendar 可以別人可見（這點上財務，商務，高管團隊需要酌情考慮），通過訂閱和你相關的同事的 Calendar 是一個也是一個很好的信息拉平渠道。
-
會議前發 Agenda，會議後形成 Meeting notes 發給參會的人，並記錄在 Wiki 中。
-
儘量少開大會長會。Amazon 的「兩個 Pizza 原則」也同樣適應於開會（這點說起來簡單，其實做起來很困難，尤其在跨團隊協作上，我們也在努力）。
這裏說幾個我們親身經歷的坑。因爲遠程的關係，在 PingCAP 我們一直以來要求儘可能的使用文檔進行溝通，我們確實在早期很嚴格的踐行了，但是那個時候我們重度依賴在線文檔，於是陷入了一個問題：協同功能很棒， 但是索引功能很弱。於是很多時候就出現了，可能記錄某件事情的文檔找不到了，或者有多個文檔（很多甚至只是討論稿）在描述同一個事情。
爲了解決這個問題，我們後來引入了 Confluence，用做團隊 Wiki，主要起到信息索引和搜索的功能，我們非常依賴 Confluence，並且玩出了很多花樣，這裏我只舉幾個最佳實踐的例子：
-
給每個團隊創建團隊的 Page（類似前面提到的「地圖」的概念）索引一切和這個團隊相關的內容，讓新人能夠一目瞭然。例如下面是來自 TiKV 團隊的例子：
![]()
-
團隊週報和個人週報，每個團隊的週報會一層層的彙總和歸納，在每週的高管例會前發出。所有的週報都在 Confluence 裏被索引。
-
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，或者反過來，每一個分公司都可能會有不同職能、不同團隊的同學。
這樣是有好處的：
-
作爲一個 toB 公司，我們國內的客戶也主要分佈在幾個主要城市，在客戶當地有分公司能更方便的開展客戶支持和市場活動。
-
在同一個城市的辦公室內有不同部門的同事，有助與構建更多樣化且健康的文化，也能更順暢的進行跨團隊合作。
辦公室的 Manager 更偏向於當地辦公室具體事務和活動的管理和組織，另外每個 Office 都會有一個行政來處理日常的事務。所以，通常我們的 Team building 會有幾種：
-
當地 Office 自己會有 TB 的經費，可以自己組織活動。
-
每當團隊出差到同一個地方的時候，組織團隊的 TB（當然，我們大多數是程序員，基本就是吃吃吃）。
這裏提到了出差，順便介紹一下，我們建議遠程研發團隊的 Managers 大概一個月需要儘量和團隊的大多數成員 Face to Face 的見一次面，這些行程通常可以和客戶拜訪安排在一起。線下的溝通可以讓線上的交流更加順暢。
總得來說，遠程辦公並非十全十美，像我們這樣的科技公司具備天然的文化和規制土壤，但仍然有很多地方有繼續改進的空間，歡迎大家給我們多提建議。很高興在國內遠程辦公文化尚未普及之時，能夠用這麼長的篇幅爲大家分享一點落地經驗。在這個特殊時期，我們在家不動的同時勞動創造價值，也算是爲社會做了點微小的貢獻 !
