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