遠程辦公4年，總結了15條高效協(xié)作的經(jīng)驗
發(fā)布時間：2020-4-23 16:29:40 點擊次數(shù)：1982
疫情下的遠程辦公，跟你聊聊我的經(jīng)驗和實踐。我于 2016 年成立 MegaEase，從早期 8 個人，直到今天有 20 來個人，我們從一開始到今天都是在遠程工作。因為我很喜歡《Rework》這本書，寫這本書的公司叫 37signal（現(xiàn)名 basecamp），這家公司在發(fā)《Rework》這本書的時候，整個公司只有 16 個人，分布在全世界 8 個城市，這種 Geek 的公司文化很吸引我，所以在我決定創(chuàng)業(yè)的時候，我就止不住地想成立這樣一家能夠遠程工作的公司。于是遠程工作的公司文化就成為了 MegaEase 的基因。我們在早期的時候，8 個員工來自 5 個城市，現(xiàn)在的 20 來個員工來自 8 個城市 2 個國家。雖然我們現(xiàn)在使用“共享辦公室”，但是本質(zhì)上，我們的整個文化是遠程工作的文化。在 2017-2018 年度，我們公司產(chǎn)品商業(yè)化以來，公司早期的 8 個工程師在遠程工作的狀態(tài)下成功支持了得到老羅的跨年演講活動，以及其它幾個客戶。一方面驗證了用戶愿意付費購買我們的產(chǎn)品和服務，另一方面也有一些不錯的收入，客單價都在百萬左右。還記得當時有幾個投資人并不相信我們是一家連辦公室都沒有的公司，而且 8 個人還分布在 5 個城市，覺得我們是個騙子公司（哈哈）。在過去的一年，我們通過我們的產(chǎn)品和服務幫助銀行、電信、互聯(lián)網(wǎng)等公司進行了他們系統(tǒng)架構的改造和升級，讓復雜和高門檻的分布式技術和架構可以被更多企業(yè)所掌握。這說明，遠程工作是沒有什么問題的。實際上遠程團隊、遠程工作真的不新鮮，Github 上有個 Repo 維護著一個支持遠程工作的公司列表，還有一個跟遠程工作相關的 Awesome 索引。https://github.com/remoteintech/remote-jobshttps://github.com/lukasz-madon/awesome-remote-job
下面是我的一些經(jīng)驗和分享。先說宏觀管理，再說微觀實踐，想看操作層面的可以直接下拉第三部分，分享我們的遠程工作協(xié)議。
宏觀管理角度其實并不分遠程辦公還是集中式辦公，只不過，這些問題在“遠程辦公”的場景下更突顯罷了。團隊管理的頭等大事是找人，沒有之一。遠程集中都一樣，而遠程團隊需要的人的一般需要有這些特質(zhì)：能獨擋一面的人。這樣交給他的事能獨立完成，沒有路能自己找路，這樣可以節(jié)省很多管理成本。
溝通能力很強的人。一方面，他能把模糊的事變清楚，另一方面，他能有效地說服他人。不然就會非常扯皮和消耗時間。
能自管理和自驅(qū)動的人。不能自管理和自驅(qū)的人，會增加大量的管理和教育成本。能自驅(qū)動的人，都是對所負責的事情有認同的人。
如果你仔細思考一下，你會發(fā)現(xiàn)，這樣的人是任何一家公司所渴望的人，和遠不遠程無關。只不過，如果是遠程團隊的話，你會被逼著要招到這樣的人。招到這樣的人，你團隊的執(zhí)行力會非常的強悍。招不到這樣的人，你只能為他們不能自管理和自驅(qū)而招“經(jīng)理”；不能寫出好代碼而招“測試”；不能很好溝通而招“項目經(jīng)理”；不能獨擋一面，而要把好的人安排給他們當“教練”，而好的人則會被累死……對于遠程團隊來說因為見不到面，缺乏交流和溝通。所以，需要團隊里所有人能夠?qū)σ龅氖掠幸粋€統(tǒng)一標準的認識。往大了說是共同的目標和使命的認知。知道要什么、不要什么，知道取舍，知道 trade-off。這些東西都是需要團隊一起達成共識的。如果沒有這樣“Same Picture”的目標和使命，就會出現(xiàn)很多不必要的誤解和沖突。另外，因為團隊和業(yè)務也在迅速發(fā)展中，所以，也需要不斷地調(diào)整和溝通。這都需要領導者花費時間統(tǒng)一目標和使命。老實說，無論遠程不遠程，一個團隊都需要有共同的目標和使命。沒有共同的目標，就算是集中在一起辦公，也一樣沒有效率。因為溝通成本的問題，遠程團隊更傾向使用小團隊，但并不是說小團隊會限制整個公司的規(guī)模。人數(shù)越多的團隊，基本上來說就更偏勞動密集型。勞動密集型的一個特征就是，大家整天在想，得整點什么事給這么多人，好讓他們忙起來。而人數(shù)少的團隊，因為人不夠，所以每天都在想，什么樣的事更重要，什么樣的事可以自動化，怎么做更有效率……小團隊和大團隊的關注點就這么不一樣了，所以做出來的事也就不一樣了……
當然，并不是說勞動密集型有什么問題，就像《軟件團隊的兩種管理方式》一文所說的一樣，遠程團隊更傾向于“電影工作組”式的每個人都是 leader 的知識密集型的團隊。在遠程工作中，我們需要有很多的微觀操作來讓大家能夠更好地進行遠程工作。首先，遠程的問題就是溝通不方便。集中辦公的話，一群人可以在白板上進行討論，然而遠程工作這個事就變成很復雜了。所以，當要討論什么事的時候，需要發(fā)起人先寫一個文檔，然后大家在這個文檔上進行討論。我們通常使用 GitHub 的 issue，Pull Request 或 Google Doc。另外，寫文檔的好處太多了，除了給后人有一個可以追溯的東西，更重要的是，寫作是一種深度思考，當你把你腦子里想的東西寫下來的時候，你就會發(fā)現(xiàn)你的思考更多了。所以，文檔驅(qū)動是我們團隊非常重要的事。自動化和簡化是我平時追得最多的東西了，從軟件的 Unit Test, Functional Test, Performance Test 一直到用 Kubernetes 進行自動化部署，我要求的就是從一提交完代碼后就自動化的上線。我們玩的是 Amazon 的“單分支”代碼管理的玩法，一旦代碼 merge 上 master，就會直接上線（當然需要通過灰度）。因為遠程團隊如果沒有自動化的工具，那么，就會導致整體效率的下降。這個太重要的了，但是，這并不是在說，如果一個事沒有 Owner，就會像“三個和尚”那樣，事情就到了沒人管的地步。這是因為很多人在工作中都是比較 nice 的，比較 nice 的人通常來說都不好意思跳出來對別人發(fā)號施令。所以，Owner 文化就是要求每件事都要定義一個 Owner，而這個 Owner 是有權對其它人發(fā)號施令的，其他人也有義務要配合他。當然，Owner 的權利越大，責任也會越大！Review 文檔是一種把知識或是想法傳遞出去的方式。我們在實踐過程中，需要大家把好的想法寫下來，這需要包括問題背景、目標、可選的方案（這些方案需要有引用和數(shù)據(jù)，不能是拍腦袋），還需要有 Pros/Cons 的比較，然后再發(fā)起討論。這樣，事情在一開始就做好，那么就可以讓大家的討論更加地有效率。很多人以為開會討論有個議題就行了，其實不夠，有效率的開會討論需要的是議案，而且還是高質(zhì)量的議案！我們需要每個人承諾自己的工作目標，這個完全由每個個體來自發(fā)完成。一般來說，每個人自己給自己制定的計劃最好是在 1-2 周內(nèi)。我們的實踐是沒有審批制度，無論是休假、報銷還是出差，完全是自己自由安排，但需要告訴團隊（除非在一些關鍵時期沒法休長假，需要整個團隊全力以赴）。千萬不要撒謊和作弊，一旦發(fā)現(xiàn)，直接開除就好了。這個是基于好人更多的原則制定的。見面和不能見面是一件非常不一樣的事，在一起工作時，人和人是會有感情的，因為會有閑聊。遠程的時候，則只有工作了。所以，我們鼓勵團隊人員間的私聊、閑聊，互相講講自己的經(jīng)歷和過往，同時，也鼓勵員工自行出差到對方的城市見見跟你一起工作的人，公司報銷差旅費。我們每周都有知識分享會，一次只講半個小時，不貪多，就講一個小的知識點。然后，團隊中的一些人還主動使用 Google Form 來收集分享的反饋信息。我們默認上是沒有年終獎的，只有就地獎勵文化。也就是說，你做的事掙錢了，利潤中有 70% 公司拿走，剩下的 30% 團隊的人就地分掉。這樣會讓團隊里的每個人都會想怎么掙錢，除了可以把精力放到那些能夠讓用戶付費的地方上，更重要的是讓團隊成員了解業(yè)務。當然，如果公司沒有掙錢，但是員工工作的不錯，我們還是會給年終獎的。不掙錢的主要責任是我的，而掙錢的主要功勞是團隊的。一些支持性的工作盡可能地使用外包，比如：HR、行政、發(fā)工資、財務、員工持股、測試人員、定制化開發(fā)……這樣可以讓你的團隊更小，更高內(nèi)聚，更利于遠程。如果一個項目是從零開始的，對于一個團隊來說可能會無從下手，這需要有個人把代碼的框架和結構給組織好。然后其他的人進入把坑填了，這樣的效率會高很多。另外，不見面的結對編程，完全可以使用異步的方式進行，這其實就是多人干同一個 pull request 的方式。有 GitHub 這樣的的協(xié)作工具，遠程編碼變得很方便。AWS。因為我希望團隊在使用 AWS 的時候能夠被潛移默化。
協(xié)作工具
Github。我們所有跟軟件開發(fā)的工作都會在 GitHub 上，我們重度使用 GitHub 的 pull request 和 issue，也會使用 GitHub Project 里的看板和 Wiki。
Google 全家桶。我們重度使用 Google，包括 Google Group、Google Driver、Google Docs。
通訊工具
語音溝通主要是使用 Zoom，因為 Zoom 不但可以支持幾十人在線，還可以云錄制。如果小范圍交流的話，一般使用微信語音。
工作溝通主要是使用 Slack，Slack 作為一個信息集散地，可以分頻道，可以分 thread 討論，微信是個渣。
吹水群
我司的吹水群主要是 Telegram，因為比微信好太多了……
你會發(fā)現(xiàn)，我們的工具有好些都是在墻外的，是的，因為墻內(nèi)的同類工具實在是太難用了。而且，我傾向于讓大家用上最先進的工具，這樣我們團隊中的每個人的品味才會被這些好的工具潛移默化。
下面是我們的遠程工作協(xié)議（無刪減），這是每一個遠程工作人員需要同意并做到的協(xié)議（其中有 Amazon Leadership Principles 的影子），目前在 v1.3 版，未來還會更新。??????
MegaEase 遠程工作團隊協(xié)作協(xié)議 v1.3每個人都是 Owner，都是 Leader，如果看到團隊或是項目有問題的時候，不要等，也不忍，請馬上說出來，并給出相應的方案，自己跳出來召集開會，及時調(diào)整。不要悶在那里，自己憋！每個人都必須是主動的，都需要自己發(fā)起要做的事，或是自己要認領要做的事，如果發(fā)現(xiàn)自己沒有事情了， 需要學會主動發(fā)現(xiàn)問題，主動找到可以 improve 的地方，創(chuàng)新來源于此。沒有路要學會自己造路！每個人都是產(chǎn)品經(jīng)理，也都是項目經(jīng)理，每個人都必須把自己的工作和我們大的目標連接在一起，知道什么是重點，重點的東西就是兩件事：一）從用戶的角度出發(fā)；二）從產(chǎn)品的角度出發(fā)。這意味著我們要隨時觀察整個產(chǎn)品的樣子，而不只是自己這一塊東西 。3）Insists on High Standard舉法其上，得乎其中，舉法其中，得乎其下，舉法其下，法不得也。我們要堅持用高的標準要求自己，對于高標準的目標不妥協(xié)，但是在實施路徑和策略上可以妥協(xié)。工作的時候必須在線。如果不在線了，需要說一下不在線的時長。目前我們工作的事宜在通訊工具上采用 Slack， 如果需要請假，如果不是緊急情況，需要提前一天在 MegaEase 的 Slack #random 頻道中提前說明。如果是緊急情況，也需要提前在 random 頻道中告知大家。面對面交談、電話語音、微信、Slack 雖然是比較實時的反饋工具，但是只有文檔是可以把重要信息結構化的，而且寫文檔其實比起前面的方式來說是更為深度的思考，因為會讓你自己審視自己的想法。所以，對于一些重要 “功能”、“流程”、“業(yè)務邏輯” 、“設計”、“問題”，以及“想法”，最好都以文檔化的方式進行。請使用 GitHub 的 wiki、project、issue 這些工具或是使用 Google Doc。對于一些重要的問題或是工作（每個人都能夠判斷什么是關鍵問題和工作）， 需要先把自己的想法 share 出來，而不是先實現(xiàn) 。3) Simplification & Automation簡化和自動化是軟件工程所追求的兩大目標，簡化不是簡陋，簡化是對事物一種抽象和歸納能力，能夠提升軟件的復用能力和擴展性。自動化是工程能力的重要體現(xiàn)，一方面遠程工作中自動化的能力可以讓整個團隊更高效地協(xié)作；另一方面，自動是規(guī)?；那疤釛l件。所以，我們要無時無刻地思考如何簡化和自動化現(xiàn)有的事情。無論是代碼還是工作都是需要反思和重構的。反思是進步的源泉，項目告一段落時，出現(xiàn)問題時，都應該召集團隊做集體反思，把好的東西堅持下去，把不好的東西優(yōu)化掉，這樣才能進步和改進。但是任何的優(yōu)化措施都是可執(zhí)行的。對于一個項目，每個人都需要有自己的 milestone 計劃， 這個計劃最好是在 2 周以內(nèi)，1 周內(nèi)是最好的，而且要承諾到 。任何討論和分析都要基于權威的證據(jù)、數(shù)據(jù)或是引用。在我們做設計的時候，或是有爭論的時候，說服對方最好的方式就是拿出證據(jù)、數(shù)據(jù)或是權威引用。比如：我的 XX 設計參考了 TCP 協(xié)議中的 XX 設計，我的 XX 觀點是基于 XX 開源軟件的實現(xiàn)……如果爭論不休就停止爭論，然后各自收集和調(diào)查自己觀點的佐證。把自己做的東西跟團隊做一次實時的演示。這樣有助于開發(fā)人員從產(chǎn)品角度思考自己的工作。除了演示產(chǎn)品功能，還可以演示算法、設計甚至代碼。會議主要處理三件事：提出議案、發(fā)現(xiàn)問題、共識結論。會議期間不解決問題，只發(fā)現(xiàn)問題，和跟蹤問題。會議必須要有共識和結論，如果不能達到共識和結論，那就當成問題處理，由問題的負責人跟進問題。關于周會或是臨時性的團隊會議（私下討論不屬于會議），會議組織者需要在事前收集會議議題，其中包括如下分類：項目類：需要事先有項目進度計劃表（任何分項最好控制在 1-2 人周內(nèi)）
方案類：需要事先寫好相關的方案和設計才能討論（參看 Design Review 章節(jié)）
問題類：需要事先寫好相關的問題和解決提案（參看 Design Review 章節(jié)）
決策類：需要事先寫好事情的前因后果以及利弊分析信息類：需要事先寫好相關的事宜說明
組織者需要在周五的時候發(fā)出會議議題收集，其中包括：自己知道的項目的進度跟進（需要相相關的項目負責人準備相關的項目計劃）方案和問題類的需要各個項目負責人提出來，并有相關的設計文檔可供 Review信息類和決策類的事宜可以寫在 Google Doc 上，也可以寫在 Team 的 Issue 里其它負責人可以在會議上加入自己團隊的東西，或是要求其他團隊提供更多的信息。9）1-2-3 Escalation遇到問題的時候自己一個人處理 1 小時內(nèi)沒有思路，請找他人小范圍討論，如果與他人 2 小時內(nèi)沒有結果，請上升到團隊范圍，如果在團隊范圍 3 小時內(nèi)沒有思路，我們就需要借助外部力量了。每個人每天在簽到的時候，不要只是一個 check-in，而是需要更 meaningful 的說一下今天的工作內(nèi)容，在每天工作完全的時候，希望簡單的說一下當天的工作總結。這里的 practice 是：3PS – Plan，Priority，Problem，Summary， – 你的計劃是什么？優(yōu)先級是什么？遇到了什么問題？一天的工作摘要 。B) Disagree and Commitment在我們開發(fā)的時候，團隊的成員都會有自己的風格，必然會對同一個問題產(chǎn)生較大的爭議（Disagree），我們鼓勵有爭議，但是是在團隊的決議作出之前。一旦團隊形成決議，團隊的成員就必須支持這個決議，并在這個方向上做出貢獻。但是關于決議的形成過程肯定充斥著各種爭論，對于這些爭論，我們可以按照下面的 Guidline 來處理爭議：Owner 要負責對重大的討論推進，盡快形成結論。
在決議過程中，要有紀要，要更新到 Github 相關項目的 Issue 或 Pull Request 里，并且要讓整個團隊知道，信息平等很重要。
不要妥協(xié)，堅持高的標準。第一標準是工業(yè)標準，第二標準是國外的大公司標準（如：Google, Facebook, GitHub, AWS…），第三標準才是國內(nèi)的標準。
哪怕再復雜，只要是標準，就可以說服用戶。用戶再無理，也不可能反對工業(yè)級的標準。
Release 出去的東西，只要被用戶用上了，要改就難了，所以要謹慎而果敢。
來源：HR實名俱樂部
徐州外服獵頭招聘部 孟健 提供
聲明 | 本文僅供交流學習，版權歸原作者所有，部分文章推送時未能及時與原作者取得聯(lián)系，若來源標注錯誤或侵犯到您的權益，煩請告知！
您感興趣的新聞
蘇公網(wǎng)安備 32031102001060號