Categories
程式開發

左耳朵耗子:疫情下的遠程辦公,聊聊我的經驗和實踐


左耳朵耗子:疫情下的遠程辦公,聊聊我的經驗和實踐 1

我於 2016 年成立 MegaEase,從早期 8 個人,直到今天有 20 來個人,我們從一開始到今天都是在遠程工作。因為我很喜歡《Rework》這本書,寫這本書的公司叫37signal(現名basecamp),這家公司在發《Rework》這本書的時候,整個公司只有16 個人,分佈在全世界8個城市,這種Geek 的公司文化很吸引我,所以在我決定創業的時候,我就止不住地想成立這樣一家能夠遠程工作的公司。於是遠程工作的公司文化就成為了 MegaEase 的基因。

下面我分享一下我們公司遠程工作的文化和其中的一些問題,最後還會分享一個我們的遠程工作協議。

我們在早期的時候,8 個員工來自 5 個城市,現在的 20 來個員工來自 8 個城市 2 個國家。雖然我們現在使用“共享辦公室”,但是本質上,我們的整個文化是遠程工作的文化。

在 2017-2018 年度,我們公司產品商業化以來,公司早期的 8 個工程師在遠程工作的狀態下成功支持了得到老羅的跨年演講活動,以及其它幾個客戶。一方面驗證了用戶願意付費購買我們的產品和服務,另一方面也有一些不錯的收入,客單價都在百萬左右。還記得當時有幾個投資人並不相信我們是一家連辦公室都沒有的公司,而且 8 個人還分佈在 5 個城市,覺得我們是個騙子公司(哈哈)。

在過去的一年,我們通過我們的產品和服務幫助銀行、電信、互聯網等公司進行了他們系統架構的改造和升級,讓複雜和高門檻的分佈式技術和架構可以被更多企業所掌握。這說明,遠程工作是沒有什麼問題的。實際上遠程團隊、遠程工作真的不新鮮,Github 上有個 Repo 維護著一個支持遠程工作的公司列表,還有一個跟遠程工作相關的 Awesome 索引

當然,自從我創業以來,我身邊就一直有好多不同的聲音質疑遠程工作。聽過他們的理由後,我能夠理解他們的疑慮和困惑,管理的確是一件很複雜的事,因為要面對的是極為複雜的人,所以,有這些疑慮也是正常的。下面是我的一些經驗和分享。先說宏觀管理,再說微觀實踐。

宏觀管理

我發現很多人比較質疑遠程工作的原因,更多是對宏觀的管理上有疑問。所以,我還是想先說一下宏觀管理,這其實並不分遠程辦公還是集中式辦公,如果能夠解決好些這管理上的根本問題,遠程不遠程也就都無所謂了。只不過,這些問題在“遠程辦公”的場景下更突顯罷了。

努力找到好的人

團隊管理的頭等大事是找人,沒有之一。很多人都會跟我說,你的這種遠程團隊需要很好的人。是的,沒錯,人很關鍵。遠程團隊需要的人的一般需要有這些特質:

能獨擋一面的人。這樣交給他的事能獨立完成,沒有路能自己找路,這樣可以節省很多管理成本。

溝通能力很強的人。一方面,他能把模糊的事變清楚,另一方面,他能有效地說服他人。不然就會非常扯皮和消耗時間。

能自管理和自驅動的人。不能自管理和自驅的人,會增加大量的管理和教育成本。能自驅動的人,都是對所負責的事情有認同的人。

如果你仔細思考一下,你會發現,這樣的人是任何一家公司所渴望的人,和遠不遠程無關。只不過,如果是遠程團隊的話,你會被逼著要招到這樣的人。

招到這樣的人,你團隊的執行力會非常的強悍。招不到這樣的人,你只能為他們不能自管理和自驅而招“經理”;不能寫出好代碼而招“測試”;不能很好溝通而招“項目經理”;不能獨檔一面,而要把好的人安排給他們當“教練”,而好的人則會被累死……

這個時候,你就需要計算一下了,是花時間精力在教育不好的人,還是花時間精力找好的人?無論遠不遠程,聰明的管理者都會選擇後者。這也就是為什麼 Amazon 的 Bezos 會說:“我寧願面試 50 個人一個人都招不到,我也不願意降低我的面試標準”。

設定共同的目標和使命

對於遠程團隊來說因為見不到面,所以缺乏交流和溝通。所以,需要團隊裡所有人能夠對要做的事有一個統一標準的認識。也就是共同的目標和使命的認知。知道要什麼、不要什麼,知道取捨,知道 trade-off。這些東西都是需要團隊一起達成共識的。如果沒有這樣“Same Picture”的目標和使命,就會出現很多不必要的誤解和衝突。另外,因為團隊和業務也在迅速發展中,所以,也需要不斷地調整和溝通。這都需要領導者花費時間統一目標和使命。

老實說,無論遠程不遠程,一個團隊都需要有共同的目標和使命。沒有共同的目標,就算是集中在一起辦公,也一樣沒有效率。

傾向使用小團隊

因為溝通成本的問題,遠程團隊更傾向使用小團隊,但並不是說小團隊會限制整個公司的規模。 《人月神話》說過,只有小團隊才能駕馭複雜的系統。 Amazon 的 Two Pizza Team 文化(團隊只能是兩張披薩就能餵飽的規模),就是把整個系統拆成“微服務”架構,這樣可以導致整體效率的巨大提升。表現在,可以並行開發,專注於一個功能更利於解決複雜問題,可以更容易的運維,可以更容易的規模化……

我工作的這 20 多年來經歷過很多家公司,尤其是創業的這幾年來,看過的公司更多了(50+ 以上)。我發現,人數越多的團隊,基本上來說就更偏勞動密集型。勞動密集型的一個特徵就是,大家整天在想,得整點什麼事給這麼多人,好讓他們忙起來。而人數少的團隊,因為人不夠,所以每天都在想,什麼樣的事更重要,什麼樣的事可以自動化,怎麼做更有效率……小團隊和大團隊的關注點就這麼不一樣了,所以做出來的事也就不一樣了……

當然,並不是說勞動密集型有什麼問題,就像《軟件團隊的兩種管理方式》一文所說的一樣,遠程團隊更傾向於“電影工作組”式的每個人都是leader 的知識密集型的團隊。

微觀實踐

在遠程工作中,我們需要有很多的微觀操作來讓大家能夠更好地進行遠程工作。因為遠程工作也有一些問題(但是方法總比問題多,不是嗎?)

文檔驅動

首先,遠程的問題就是溝通不方便。集中辦公的話,一群人可以在白板上進行討論,然而遠程工作這個事就變成很複雜了。所以,當要討論什麼事的時候,需要發起人先寫一個文檔,然後大家在這個文檔上進行討論(我們通常使用 GitHub 的 issue,Pull Request 或 Google Doc)。另外,寫文檔的好外太多了,除了給後人有一個可以追溯的東西,更重要的是,寫作是一種深度思考,當你把你腦子裡想的東西寫下來的時候,你就會發現你的思考更多了。所以,文檔驅動是我們團隊非常重要的事。

自動化和簡化

自動化和簡化是我平時追得最多的東西了,從軟件的 Unit Test, Functional Test, Performance Test 一直到用 Kubernetes 進行自動化部署,我要求的就是從一提交完代碼後就自動化的上線。我們玩的是 Amazon 的“單分支”代碼管理的玩法,一旦代碼 merge 上 master,就會直接上線(當然需要通過灰度)。因為遠程團隊如果沒有自動化的工具,那麼,就會導致整體效率的下降。

Owner 文化

這個太重要的了,但是,這並不是在說,如果一個事沒有 Owner,就會像“三個和尚”那樣,事情就到了沒人管的地步。這是因為很多人在工作中都是比較 nice 的,比較 nice 的人通常來說都不好意思跳出來對別人發號施令。所以,Owner 文化就是要求每件事都要定義一個 Owner,而這個 Owner 是有權對其它人發號施令的,其他人也有義務要配合他。當然,Owner 的權利越大,責任也會越大!

Review 文化

Review 文檔是一種把知識或是想法傳遞出去的方式。我們在實踐過程中,需要大家把好的想法寫下來,這需要包括問題背景、目標、可選的方案(這些方案需要有引用和數據,不能是拍腦袋),還需要有Pros/Cons 的比較,然後再發起討論。這樣,事情在一開始就做好,那麼就可以讓大家的討論更加地有效率。很多人以為開會討論有個議題就行了,其實不夠,有效率的開會討論需要的是議案,而且還是高質量的議案!

目標承諾

我們需要每個人承諾自己的工作目標,這個完全由每個個體來自發完成。一般來說,每個人自己給自己制定的計劃最好是在 1-2 週內。

自我管理

我們的實踐是沒有審批制度,無論是休假、報銷還是出差,完全是自己自由安排,但需要告訴團隊(除非在一些關鍵時期沒法休長假,需要整個團隊全力以赴)。千萬不要撒謊和作弊,一旦發現,直接開除就好了。這個是基於好人更多的原則制定的(沒有必要為了少數的壞人一刀切後讓所有人痛苦)。

閒聊和自行見面

見面和不能見面是一件非常不一樣的事,在一起工作時,人和人是會有感情的,因為會有閒聊。遠程的時候,則只有工作了。所以,我們鼓勵團隊人員間的私聊、閒聊,互相講講自己的經歷和過往,同時,也鼓勵員工自行出差到對方的城市見見跟你一起工作的人,公司報銷差旅費。

知識分享會

我們每週都有知識分享會,一次只講半個小時,不貪多,就講一個小的知識點。然後,團隊中的一些人還主動使用 Google Form 來收集分享的反饋信息。

就地獎勵文化

我們默認上是沒有年終獎的,只有就地獎勵文化。也就是說,你做的事掙錢了,利潤中有 70% 公司拿走,剩下的 30% 團隊的人就地分掉。這樣會讓團隊裡的每個人都會想怎麼掙錢,除了可以把精力放到那些能夠讓用戶付費的地方上,更重要的是讓團隊成員了解業務。當然,如果公司沒有掙錢,但是員工工作的不錯,我們還是會給年終獎的。不掙錢的主要責任是我的,而掙錢的主要功勞是團隊的。

外包支持性的工作

一些支持性的工作盡可能地使用外包,比如:HR、行政、發工資、財務、員工持股、測試人員、定制化開發……這樣可以讓你的團隊更小,更高內聚,更利於遠程。

異步編程

如果一個項目是從零開始的,對於一個團隊來說可能會無從下手,這需要有個人把代碼的框架和結構給組織好。然後其他的人進入把坑填了,這樣的效率會高很多。另外,不見面的結對編程,完全可以使用異步的方式進行,這其實就是多人幹同一個 pull request 的方式。有 GitHub 這樣的的協作工具,遠程編碼變得很方便。

遠程工具

關於我們的遠程工具,我們主要是使用:

開發環境

AWS。因為我希望團隊在使用 AWS 的時候能夠被潛移默化。

協作工具

Github。我們所有跟軟件開發的工作都會在 GitHub 上,我們重度使用 GitHub 的 pull request 和 issue,也會使用 GitHub Project 裡的看板和 Wiki。

Google 全家桶。我們重度使用 Google,包括 Google Group、Google Driver、Google Docs。

通訊工具

語音溝通主要是使用 Zoom,因為 Zoom 不但可以支持幾十人在線,還可以雲錄製。如果小範圍交流的話,一般使用微信語音。

工作溝通主要是使用 Slack,Slack 作為一個信息集散地,可以分頻道,可以分 thread 討論,微信是個渣。

吹水群。我司的吹水群主要是 Telegram,因為比微信好太多了……

你會發現,我們的工具有好些都是在牆外的,是的,因為牆內的同類工具實在是太難用了。而且,我傾向於讓大家用上最先進的工具,這樣我們團隊中的每個人的品味才會被這些好的工具潛移默化。

遠程工作協議

下面是我們的遠程工作協議(無刪減),這是每一個遠程工作人員需要同意並做到的協議(其中有Amazon Leadership Principles 的影子),目前在v1.3 版,未來還會更新,我現在把它曬出來,也希望得到大家更好的建議!

MegaEase 遠程工作團隊協作協議 v1.3
Principles

0)Ownership & Leadership

每個人都是 Owner,都是 Leader,如果看到團隊或是項目有問題的時候,不要等,也不忍,請馬上說出來,並給出相應的方案,自己跳出來召集開會,及時調整。不要悶在那裡,自己憋!

1)Initiative

每人個都必需是主動的,都需要自己發起要做的事,或是自己要認領要做的事,如果發現自己沒有事情了, 需要學會主動發現問題,主動找到可以improve 的地方,創新來源於此。沒有路要學會自己造路!

2)Objectives Oriented

每個人都是產品經理,也都是項目經理,每個人都必需把自己的工作和我們大的目標連接在一起,知道什麼是重點,重點的東西就是兩件事:一)從用戶的角度出發;二)從產品的角度出發。這意味著我們要隨時觀察整個產品的樣子,而不只是自己這一塊東西 。

3)Insists on High Standard

舉法其上,得乎其中,舉法其中,得乎其下,舉法其下,法不得也。我們要堅持用高的標準要求自己,對於高標準的目標不妥協,但是在實施路徑和策略上可以妥協。

Practices
0)Online

工作的時候必需在線。如果不在線了,需要說一下不在線的時長。目前我們工作的事宜在通訊工具上採用 Slack, 如果需要請假,如果不是緊急情況,需要提前一天在 MegaEase 的 Slack #random 頻道中提前說明。如果是緊急情況,也需要提前在 random 頻道中告知大家。

1) Documentation Driven

面對面交談、電話語音、微信、Slack 雖然是比較實時的反饋工具,但是只有文檔是可以把重要信息結構化的,而且寫文檔其實比起前面的方式來說是更為深度的思考,因為會讓你自己審視自己的想法。所以,對於一些重要 “功能”、“流程”、“業務邏輯” 、“設計”、“問題”,以及“想法”,最好都以文檔化的方式進行。請使用 GitHub 的 wiki、project、issue 這些工具或是使用 Google Doc。

2)Design Review

對於一些重要的問題或是工作(每個人都能夠判斷什麼是關鍵問題和工作), 需要先把自己的想法 share 出來,而不是先實現 。

一個好的 Design 文檔需要包括如下項:

  • Background。交待這個事的背景、需求和要解決問題。
  • Objectives。說明這個事的目標和意義。
  • Alternative Solutions。給出多個解決方案,並能夠進行 Pros/Cons 對比。 Reference——方案需要有權威引用支持;Data——方案需要有相關數據數據支持。
  • Conclusion。結論是什麼。

3) Simplification & Automation

簡化和自動化是軟件工程所追求的兩大目標,簡化不是簡陋,簡化是對事物一種抽象和歸納能力,能夠提升軟件的複用能力和擴展性。自動化是工程能力的重要體現,一方面遠程工作中自動化的能力可以讓整個團隊更高效地協作;另一方面,自動是規模化的前得條件。所以,我們要無時無刻地思考如何簡化和自動化現有的事情。

4)Review & Re-factory

無論是代碼還是工作都是需要反思和重構的。反思是進步的源泉,項目告一段落時,出現問題時,都應該召集團隊做集體反思,把好的東西堅持下去,把不好的東西優化掉,這樣才能進步和改進。但是任何的優化措施都是可執行的。

5)Milestone Commitment

對於一個項目,每個人都需要有自己的 milestone 計劃, 這個計劃最好是在 2 週以內,1 週內是最好的,而且要承諾到 。

6)Evidence Driven

任何討論和分析都要基於權威的證據、數據或是引用。在我們做設計的時候,或是有爭論的時候,說服對方最好的方式就是拿出證據、數據或是權威引用。比如:我的 XX 設計參考了 TCP 協議中的 XX 設計,我的 XX 觀點是基於 XX 開源軟件的實現……如果爭論不休就停止爭論,然後各自收集和調查自己觀點的佐證。

7)Demo Day

把自己做的東西跟團隊做一次實時的演示。這樣有助於開發人員從產品角度思考自己的工作。除了演示產品功能,還可以演示算法、設計甚至代碼。

8) Effective Meeting

會議主要處理三件事:提出議案、發現問題、共識結論。

會議不僅僅要有議題,最好還有議案。

會議期間不解決問題,只發現問題,和跟踪問題。

會議必需要有共識和結論,如果不能達到共識和結論,那就當成問題處理,由問題的負責人跟進問題。

關於週會或是臨時性的團隊會議(私下討論不屬於會議),會議組織者需要在事前收集會議議題,其中包括如下分類:

  • 項目類:需要事先有項目進度計劃表(任何分項最好控制在 1-2 人周內)
  • 方案類:需要事先寫好相關的方案和設計才能討論(參看 Design Review 章節)
  • 問題類:需要事先寫好相關的問題和解決提案(參看 Design Review 章節)
  • 決策類:需要事先寫好整事的前因後果以及利弊分析信息類:需要事先寫好相關的事宜說明

組織者需要在周五的時候發出會議議題收集,其中包括:

  • 自己知道的項目的進度跟進(需要相相關的項目負責人準備相關的項目計劃)
  • 方案和問題類的需要各個項目負責人提出來,並有相關的設計文檔可供 Review
  • 信息類和決策類的事宜可以寫在 Google Doc 上,也可以寫在 Team 的 Issue 裡
  • 其它負責人可以在會議上加入自己團隊的東西,或是要求其他團隊提供更多的信息。

9)1-2-3 Escalation

遇到問題的時候,自己一個人處理1 小時內沒有思路,請找他人小範圍討論,如果與他人2 小時內沒有結果,請上升到團隊範圍,如果在團隊範圍3 小時內沒有思路,我們就需要藉助外部力量了。

A)3PS Update

每個人每天在簽到的時候,不要只是一個 check-in,而是需要更 meaningful 的說一下今天的工作內容,在每天工作完全的時候,希望簡單的說一下當天的工作總結。這裡的 practice 是:3PS – Plan,Proirity,Problem,Summary, – 你的計劃是什麼?優先級是什麼?遇到了什麼問題?一天的工作摘要 。

B) Disagree and Commitment

在我們開發的時候,團隊的成員都會有自己的風格,必然會對同一個問題產生較大的爭議(Disagree),我們鼓勵有爭議,但是是在團隊的決議作出之前。一旦團隊形成決議,團隊的成員就必須支持這個決議,並在這個方向上做出貢獻。

但是關於決議的形成過程肯定充斥著各種爭論,對於這些爭論,我們可以按照下面的 Guidline 來處理爭議:

  • Owner 要負責對重大的討論推進,盡快形成結論。
  • 在決議過程中,要有紀要,要更新到 Github 相關項目的 Issue 或 Pull Request 裡,並且要讓整個團隊知道,信息平等很重要。
  • 不要妥協,堅持高的標準。第一標準是工業標準,第二標準是國外的大公司標準(如:Google, Facebook, GitHub, AWS…),第三標準才是國內的標準。
  • 哪怕再复雜,只要是標準,就可以說服用戶。用戶再無理,也不可能反對工業級的標準。
  • Release 出去的東西,只要被用戶用上了,要改就難了,所以要謹慎而果敢。

作者介紹:

陳皓,網名“左耳朵耗子”,MegaEase 創始人 &CEO,資深技術專家,骨灰級程序員,QCon2020 全球軟件開發大會講師,極客時間《左耳聽風》專欄作者。本文首發自酷殼 CoolShell,InfoQ 獲得陳皓授權發布。