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