十年硅谷技術(shù)管理經(jīng)驗總結(jié)的 6 條技術(shù)工程原則

一位常年征戰(zhàn)于硅谷技術(shù)管理前線的技術(shù)工程文化踐行者認(rèn)為競爭的核心在于“效率”、“質(zhì)量”和“人才”。本文將分享他用十年的經(jīng)驗總結(jié)的 6 條技術(shù)工程原則，并詳細(xì)解說技術(shù)工程文化在團(tuán)隊中實踐落地的案例與方法。

先跟大家說說我對科技創(chuàng)新的看法。在我讀書那會兒，覺得創(chuàng)新、創(chuàng)業(yè)都是學(xué)霸們做的事情，畢竟有多少人會寫 PageRank 呢？

現(xiàn)在，隨著一些代碼的開源，隨著很多開發(fā)工具的深入人心，創(chuàng)新的門檻降低了，這讓更多在產(chǎn)品、設(shè)計方面有天賦的同學(xué)可以更好地加入到其中，這是一件好事。

過去的技術(shù)產(chǎn)品創(chuàng)新靠的是技術(shù)的壁壘，現(xiàn)在我們更強(qiáng)調(diào)的是走心，產(chǎn)品要抓住客戶的心理。

再說到“平臺”。我有時候在想，像亞馬遜的云計算平臺 AWS、以及安卓等，如果沒有它們的話，現(xiàn)在也許一半的初創(chuàng)公司都不會存在了。

因為有了平臺的出現(xiàn)，創(chuàng)新的資本要求也降低了，資金可以重點用在用戶增長方面，而不是更多地花在基礎(chǔ)建設(shè)和硬件上。

我們且不去討論這是不是走偏了，是不是行業(yè)過熱的表現(xiàn)，我覺得我們作為這一代的科技人，無論你是來自創(chuàng)新公司，還是身在已經(jīng)進(jìn)入成熟發(fā)展階段的大公司，都要認(rèn)清現(xiàn)在的變化，適應(yīng)現(xiàn)在的變化，理解競爭的機(jī)制，尋找對策。

毫不夸張地說，現(xiàn)在的科技界感覺像到了春秋戰(zhàn)國時期一樣，百家爭鳴。如果有人問你下一代的核心科技是什么？答案眾說紛紜。

有人說是自動化的再次爆發(fā)，無人機(jī)、無人車，連機(jī)器人項目都已經(jīng)開始做成平臺了。

也有人覺得是人工智能，機(jī)器學(xué)習(xí)、深度學(xué)習(xí)已經(jīng)不僅僅是局限在想戰(zhàn)勝人腦，而是想要徹底顛覆人類學(xué)習(xí)新東西時所采取的方法。

還有人說是共享經(jīng)濟(jì)，現(xiàn)在包括衣食住行在內(nèi)的我們生活中的很多活動都在實時化、個性化。

當(dāng)然也有人相信是物聯(lián)網(wǎng)，在不久的將來，如果手機(jī)丟了，我們估計就是寸步難行、無家可歸。

因為沒有手機(jī)你的汽車就不能發(fā)動、你就打不到車，就算走回了家，估計沒有了手機(jī)你連房門都打不開。

在這樣一個科技的盛世中，到底是小公司更容易立足了，還是大公司更有優(yōu)勢？

如果我們回過頭來看過去的 30-40 年，從硬件到軟件、從信息到社交的網(wǎng)站，歷史似乎告訴我們是大公司的優(yōu)勢更大。

因為在每個時期，最后只有那么一家或者幾家公司可以代表這個時代。

國內(nèi)一位有名的投資者曾經(jīng)說過，新科技帶來的生產(chǎn)力的提高會逐漸地轉(zhuǎn)化成由資本支撐的競爭優(yōu)勢，但當(dāng)資本的投入到了趨于飽和的時候，規(guī)?；俏覀?nèi)祟惿鐣谙乱徊娇萍汲霈F(xiàn)前的一種等待。

盡管現(xiàn)在的科技領(lǐng)域非常多，但是資本介入、規(guī)?；刻於荚诎l(fā)生。

從另一個方面我們也看到，相對于企業(yè)軟件來講，我們現(xiàn)在做面向個人消費者的產(chǎn)品，研發(fā)周期在縮短，智能手機(jī)的普及對產(chǎn)品的更新迭代提出了更高的要求。

在這樣的環(huán)境中，大公司還有沒有優(yōu)勢可以繼續(xù)保持這樣的速度？不管是所謂的大公司，還是初創(chuàng)企業(yè)，面臨的最大挑戰(zhàn)都是人才的問題。

十年前學(xué)軟件的同學(xué)可能都在學(xué) Java，而現(xiàn)在因為領(lǐng)域多了，人才開始比較分散?，F(xiàn)在好的研發(fā)能得到的機(jī)會太多了，而且每一個選擇的風(fēng)險成本正在降低。

當(dāng)然，不管科技怎么發(fā)展、時代怎么變革，作為一個公司、一個商業(yè)主體，有一些東西是不會變的。

那就是：我們永遠(yuǎn)要做用戶需要的產(chǎn)品。降低成本、提升效率是公司競爭永恒的主題，高效且不失質(zhì)量是一個產(chǎn)品、一個公司的立足之本。

過去 10 年，我有幸在硅谷的三家公司效力，我先去了如日中天的業(yè)界新貴 Google，后來去了一個大家認(rèn)為躺著都能贏的初創(chuàng)企業(yè) Twitter，現(xiàn)在在 Lyft。

在外界看來我們 Lyft 的競爭壓力非常大，但是在我們內(nèi)部有一種打不死的小強(qiáng)精神。

這三個公司屬于完全不同的產(chǎn)業(yè)，不同的規(guī)模，也有著完全不同的競爭壓力。然而從研發(fā)團(tuán)隊管理的角度來看，我覺得他們有很多東西是共通的。

今天，我將與大家分享 6 條技術(shù)工程原則，這 6 條原則是我作為一個研發(fā)工程師和技術(shù)主管在這么多年的工作中總結(jié)下來的一些經(jīng)驗，希望對大家有所啟發(fā)和幫助：

• 研發(fā)責(zé)任制
• 數(shù)據(jù)驅(qū)動
• 迭代式發(fā)展
• 組合型發(fā)展
• 客戶為先
• 統(tǒng)一性

當(dāng)然這 6 條原則都是從研發(fā)角度出發(fā)的，不能代表商業(yè)競爭的全部。但作為科技公司，研發(fā)至關(guān)重要。我們推廣技術(shù)工程原則要達(dá)到的目標(biāo)是：一提高效率、二保證質(zhì)量、三培養(yǎng)人才。

接下來提到的不少技術(shù)工程原則，都是耳熟能詳?shù)?。所以在接下來的分享中我盡量多舉一些例子供大家參考。

原則1：研發(fā)責(zé)任制

研發(fā)責(zé)任制是要讓工程師能夠在“做什么產(chǎn)品”、“怎么做產(chǎn)品”等問題上有更多的發(fā)言權(quán)。

在谷歌獲得了巨大的成功之后，美國硅谷以研發(fā)工程師為主導(dǎo)的科技企業(yè)的企業(yè)文化也隨之悄然流行。

很多人認(rèn)為只有讓研發(fā)工程師做自己有興趣的產(chǎn)品，才能最大地激發(fā)他們的潛能。

這條原則最好的實踐案例可能是谷歌當(dāng)年的“20% Project”：每個工程師可以在每星期花一天的時間做與自己本職工作完成無關(guān)的東西，可以是一些原始的項目，也可以是一些看似無稽荒謬的點子（谷歌早期的很多產(chǎn)品都來自于這些點子）。

谷歌這么做是對研發(fā)團(tuán)隊以及工程師的無限信任，雖然很多年之后由于公司規(guī)模的擴(kuò)大他們最終放棄了這個政策。

我們在評估工程師業(yè)績的時候，要和他們所負(fù)責(zé)產(chǎn)品的商業(yè)價值做直接的掛鉤，通過用戶得到的價值、利益來體現(xiàn)工程師的貢獻(xiàn)。

而對于所做產(chǎn)品不是面向終端用戶的研發(fā)團(tuán)隊來說，我們也可以找到內(nèi)部的客戶。

總之，我們要把“客戶的需求被滿足”這一指標(biāo)度量化，來客觀地給研發(fā)團(tuán)隊打分。

我們希望研發(fā)團(tuán)隊有足夠的自主權(quán)，尤其是在產(chǎn)品開發(fā)的初期。他們要不受其他職能部門的限制，敢于做一些其他的事情，不管是不是技術(shù)，都需要他們勇于探索。

他們甚至可以在不影響商業(yè)指標(biāo)的情況下做技術(shù)與非技術(shù)的決定，提高團(tuán)隊效率，比如可以由研發(fā)領(lǐng)頭來進(jìn)行 Beta 測試等。

我們希望通過培養(yǎng)全棧式研發(fā)團(tuán)隊，降低跨部門合作的壁壘。其他的職能部門更多的是對研發(fā)部門起到輔助的作用，以此減少每個團(tuán)隊對其他團(tuán)隊的依賴。

踐行這條原則時需要注意：

任何技術(shù)工程的原則都不是一個數(shù)學(xué)公式，不能直接套用，我們在實踐過程中要注意不能矯枉過正。

比如上文中提到的全棧，全棧不能過度，如果過度，全棧會產(chǎn)生對技術(shù)的不統(tǒng)一。

盲目追求全棧，把所有做基礎(chǔ)架構(gòu)的人都分配到全棧中去，對基礎(chǔ)架構(gòu)的投入就會不足。

再來說說“研發(fā)至上”。研發(fā)至上是從谷歌開始推行的，本意是讓工程師可以有足夠的自主權(quán)決定做什么，結(jié)果卻會造成一些過度追求工程完美的現(xiàn)象出現(xiàn)。

有些產(chǎn)品可能從工程的角度來看非常好，但是市場切入點不夠，或者由于產(chǎn)品太前衛(wèi)沒辦法找到匹配的用戶和需求，無法流通于市場實現(xiàn)其價值。

我們不妨拿“Google Wave”這個產(chǎn)品舉例，這個產(chǎn)品當(dāng)時的目的是想改變電子郵件的呈現(xiàn)方式。

大家熟知的電子郵件是：我給你發(fā)一個郵件，之后我還想修改，可我并不能在你收到的那封郵件上直接進(jìn)行修改，而是需要另外傳送一封修改過的郵件。

有的同學(xué)喜歡逐字逐行回復(fù)，這樣再經(jīng)轉(zhuǎn)發(fā)，后來被加進(jìn)來的同學(xué)就不能實時看到修改的痕跡，很難得知和參與之前的討論。

Google Wave 就是想把電子郵件通過像網(wǎng)絡(luò)文檔的方式來處理，把整個電子郵件鏈發(fā)展的過程呈現(xiàn)在眼前。

我個人非常喜歡，這是一個非常好的產(chǎn)品，很多功能是工程師想出來的 idea，但是當(dāng)時并沒有足夠的市場，以至于這個產(chǎn)品最終甚至于沒有發(fā)布。

原則2：數(shù)據(jù)驅(qū)動

首先，數(shù)據(jù)可以幫助確定優(yōu)先級。對每個公司而言，產(chǎn)品、項目優(yōu)先級的確定都非常重要，尤其是初創(chuàng)公司更要學(xué)會關(guān)注。

用數(shù)據(jù)去決定優(yōu)先級，而不是靠專家。無論你是做市場調(diào)查、做 Beta 測試，還是對之前的產(chǎn)品做一些研究，都要用數(shù)據(jù)說話。

這些數(shù)據(jù)除了用戶對產(chǎn)品使用的指標(biāo)之外，還要考慮人力成本、要計算人均產(chǎn)出。要考慮團(tuán)隊人數(shù)和角色構(gòu)成，除了技術(shù)、產(chǎn)品、運(yùn)營、設(shè)計等以外還有沒有其他的角色。

作為研發(fā)團(tuán)隊要做到數(shù)據(jù)驅(qū)動，在討論設(shè)計的時候，就要確定數(shù)據(jù)采集的要求。數(shù)據(jù)的采集和分析是有滯后性的。

因此在產(chǎn)品發(fā)布之前，我們希望說清楚成功的指標(biāo)是什么？怎么去衡量？這里建議大家用一些比較有獨立性的指標(biāo)去衡量你的產(chǎn)品是否成功。

什么叫有獨立性的指標(biāo)？因為有一些很好的指標(biāo)都不具有獨立性，這里跟大家舉一個不能算反例的“反例”。

例如 Lyft 每次推出司機(jī)功能的時候，我們會考慮平均司機(jī)駕駛的時間，這不是一個有完全獨立性的指標(biāo)。

我遇到過一個司機(jī)，在舊金山一個小時之內(nèi)只要開 50 分鐘的車，就可以滿足我們對司機(jī)獎勵的機(jī)制，最后 10 分鐘，他不用真的去開車，也不用去接單，只需要把 APP 打開。

如果我們只計算平均駕駛時間的話，會發(fā)現(xiàn)這樣的司機(jī)多了 20% 的駕駛時間，但這并不代表他們對產(chǎn)品的粘度真的增加了。這就沒有換來我們真正想要測量到的東西。

再有一點，不管這個產(chǎn)品或架構(gòu)有多復(fù)雜，很多時候都可以用最簡單、最簡潔的指標(biāo)去測量。

這里的案例我們說說谷歌的搜索，這么多年來，每次在講到搜索質(zhì)量的時候，谷歌都是沿用一個非常簡單的方法，就是收集谷歌的搜索結(jié)果和其他搜索引擎搜索到的結(jié)果讓用戶進(jìn)行盲測、打分。

我們當(dāng)年每個季度末開大會，Google 的兩位創(chuàng)始人 Larry Page 和 Sergey Brin 上臺的時候，就能以非常簡單和清晰的方式對過去的一個季度打分，然后讓所有人都知道接下來的一段時間的目標(biāo)在哪里。

踐行這條原則時需要注意的方面：

充分發(fā)揮數(shù)據(jù)的作用需要海量的數(shù)據(jù)樣本，或者即便你有海量的數(shù)據(jù)，也有可能存在著不確定的因素。

所以我們建議研發(fā)團(tuán)隊不能迷信數(shù)據(jù)，該做決定的時候要勇于做決定。

還有一點，在社交網(wǎng)站搭建的過程中，有一些功能在剛推出的時候，只有一部分的用戶在用，還沒有起到網(wǎng)絡(luò)的效應(yīng)，這個效應(yīng)有一定的滯后性，這個時候數(shù)據(jù)并不一定能完全說明問題。

原則3：迭代式發(fā)展

迭代式發(fā)展的精髓是：先設(shè)置一個大的目標(biāo)，但要一步一步腳踏實地地去達(dá)成。

說到團(tuán)隊、項目要迭代時，大家都能理解，但其實每個研發(fā)工程師在負(fù)責(zé)自己項目的時候，也可以去迭代。

這個迭代指的是你要有這個能力把自己的項目分塊，分成不同的部分去展現(xiàn)階段性的成果。

比如在研發(fā)過程中有個很關(guān)鍵的環(huán)節(jié)：做代碼檢查。

很多同學(xué)喜歡把整個項目都做完了才發(fā)一個 code review request(專指請求別人給自己做代碼檢查），涉及很多文件，真正做檢查的人很難給出有針對性的方案。

我們希望我們的研發(fā)可以把他的項目分成幾塊（逐塊進(jìn)行代碼檢查），這樣做第一是對別人時間的尊重，第二也是一種個人能力的培養(yǎng)。

我們的迭代式發(fā)展講究不惜一切代價快速推出實驗，實驗的時候不要追求完美。同時，我們也要求團(tuán)隊在做一些探索性的項目時要加上時間的限制。

在預(yù)定的時間內(nèi)，如果沒有發(fā)現(xiàn)突破，沒有看到好的結(jié)果，要懂得放棄，降低實驗的成本。

踐行這條原則時需要注意的方面：

第一，我們經(jīng)常會過分強(qiáng)調(diào)眼前一小步一小步地去達(dá)成遠(yuǎn)景的目標(biāo)，可是這個遠(yuǎn)景目標(biāo)到底是什么？

每過一段時間我們都要根據(jù)現(xiàn)在的項目進(jìn)度及結(jié)果來思考是不是需要調(diào)整和改變遠(yuǎn)景目標(biāo)，以免陷入一種叫“長期性的還債式的項目”。

舉個例子：幾年前，Lyft 對大數(shù)據(jù)的架構(gòu)投入不夠，所以造成了我們的系統(tǒng)比較落后。一個系統(tǒng)既要做數(shù)據(jù)的存儲，又要做數(shù)據(jù)的查詢工作，還要支撐數(shù)據(jù)的計算和整合。

如果我們只是一小步一小步地去優(yōu)化這個計算，在整合中加以微調(diào)，而另一方面我們的業(yè)務(wù)還在迅速增長。

在這種情況下我們每次得到的提高根本比不上業(yè)務(wù)增長所帶來的新的計算量，長此以往這個債永遠(yuǎn)都還不清，我們的系統(tǒng)永遠(yuǎn)都不能取得長足的進(jìn)步。

所以這個時候這種迭代式的發(fā)展，一小步一小步走反而阻礙了我們，需要我們停下來看終點目標(biāo)到底在哪里。我們可以反向規(guī)劃，尋求一個長遠(yuǎn)的投資和短期的痛點之間的平衡。

第二，我們一些負(fù)責(zé)用戶增長的團(tuán)隊，有的時候非常強(qiáng)調(diào)迭代，要做海量的實驗。但是每一個實驗從技術(shù)層面上說都很簡單。

這樣對本團(tuán)隊員工的職業(yè)發(fā)展可能不是最有利的，一些很資深的工程師、架構(gòu)師不愿意加入這樣的團(tuán)隊。這是我們技術(shù)管理者在人才的培養(yǎng)和培訓(xùn)方面需要解決的問題。

原則4：組合型發(fā)展

這里的關(guān)鍵是要尋找到產(chǎn)品的功能開發(fā)和基礎(chǔ)架構(gòu)之間投入的平衡點，全棧式的團(tuán)隊更要注重組合型的規(guī)劃。

我們建議讓技術(shù)主管、技術(shù)管理者對架構(gòu)的投入直接負(fù)責(zé)；產(chǎn)品經(jīng)理則要明確地知道不是團(tuán)隊中所有的人力資源都能放在做產(chǎn)品上。

大家都知道技術(shù)債務(wù)的問題，建議團(tuán)隊定期進(jìn)行“技術(shù)債務(wù)償還周”，就是每個階段都花一周時間集中精力償還這段時間所積累的技術(shù)債務(wù)。

這里說的技術(shù)債務(wù)，除了一些程序中的 Bug 之外，還包括架構(gòu)的缺陷，甚至文檔的短缺。

除了全棧組之外，我們還希望培養(yǎng)全棧的人才，就是一個人可以扮演多個角色。

一個人扮演多個角色，一方面有助于自己技術(shù)的提高，另一方面可以進(jìn)行人才的輪換，讓不同的人在不同的時間做不同的事情，這樣也更有利于整個團(tuán)隊的平衡。

踐行這條原則時需要注意的方面：

首先，組合型規(guī)劃要避免在團(tuán)隊中出現(xiàn)小團(tuán)隊。如果明確劃分你是做產(chǎn)品的，我是做基礎(chǔ)架構(gòu)的，那這個全棧團(tuán)隊的意義就消失了。

其次，要防止過度設(shè)計。在償還技術(shù)債務(wù)的時候，也不能過度地追求完美。

舉個例子：早年 Twitter 剛開始的時候，所有的程序都在一個程序庫里面，當(dāng)時 Twitter 的網(wǎng)站也就是一個可執(zhí)行文件，很多初創(chuàng)公司都是這么過來的。

隨著時間的發(fā)展，隨著產(chǎn)品變得復(fù)雜，我們必須把單一的程序分解開，變成各個組件。

整個過程 Twitter 花了四年半的時間，因為目標(biāo)是要把每一行代碼都從這個單一的程序庫中挪出來，變到其他的組件中去。

這一進(jìn)程多次延緩或阻礙了產(chǎn)品功能的迅速推出。這就是上文說的當(dāng)你有了組合型的規(guī)劃，并對基礎(chǔ)架構(gòu)足夠投入的時候，如果過度追求完美，也會帶來負(fù)面的影響。

原則5：客戶為先

每一個團(tuán)隊都要明確自己的客戶，這個客戶可以是終端用戶也可以是公司內(nèi)部的客戶。我們提倡組建服務(wù)型、平臺型的團(tuán)隊，找到客戶并解決客戶的痛點。

這里有很多實踐案例，比如一個公司的設(shè)計團(tuán)隊除了追求美學(xué)上的完美設(shè)計，還要把研發(fā)、產(chǎn)品團(tuán)隊的進(jìn)度納入到自己團(tuán)隊的工作計劃中去。

做品牌架構(gòu)的同學(xué)經(jīng)常會抱怨產(chǎn)品組把系統(tǒng)拖垮了，實際上你作為做平臺的人就要把整合測試和壓力測試作為自己的工作，要爭取做出怎么用都用不壞的平臺，這才是最好的架構(gòu)。

面向客戶，要時時刻刻關(guān)心客戶的利益。有的時候增長過快會損害客戶的利益，這時我們建議引進(jìn)一個杠桿指標(biāo)，對每個增長指標(biāo)做更全面的考量。

比如在 Lyft 我們所有的產(chǎn)品組都會用到一個叫“T1K”的指標(biāo)，即每一千單得到用戶的投訴率。國內(nèi)滴滴也在用類似的指標(biāo)，以此來對所有的事業(yè)部進(jìn)行橫向的比較。

踐行這條原則時需要注意的方面：

當(dāng)有一些團(tuán)隊（特別是面向公司內(nèi)部的服務(wù)型研發(fā)團(tuán)隊）做出了成績，提高了其他客戶團(tuán)隊的效率，我們希望有一個閉合反饋環(huán)，團(tuán)隊之間達(dá)成共贏，促進(jìn)共同發(fā)展。

舉個例子：在 Twitter、Lyft，我們的反作弊風(fēng)控團(tuán)隊都開發(fā)了一個實時規(guī)則引擎。使用這個產(chǎn)品，在不經(jīng)過提交代碼的情況下，風(fēng)控的運(yùn)營團(tuán)隊可以比較獨立地去抵抗突發(fā)事件，這大大提高了他們的效率，減少了他們對研發(fā)團(tuán)隊的依賴。

在這個過程中，我們希望運(yùn)營團(tuán)隊可以用這樣的引擎來保持實時關(guān)注，并及時發(fā)現(xiàn)新攻擊種類，為研發(fā)團(tuán)隊提供最新線索和第一手資料，這樣的反饋可以幫助我們的算法再提高。

原則6：統(tǒng)一性

全棧團(tuán)隊容易造成各個部門之間技術(shù)實現(xiàn)的不統(tǒng)一。這時我們可以在全公司范圍內(nèi)跨團(tuán)隊地形成專門針對某個技術(shù)領(lǐng)域的虛擬組，由這些虛擬組來推廣規(guī)范。

當(dāng)然這里覆蓋的面很廣，大到技術(shù)選擇(technology)、架構(gòu)(architecture)，小到設(shè)計模式(design patterns)、代碼規(guī)范(code style)等。

再舉一個與統(tǒng)一性原則相悖的例子：

在 Twitter 的早期，一半的工程師來自谷歌，他們覺得后臺一定要用 Java 系統(tǒng)；另一半的工程師是自己創(chuàng)業(yè)，他們覺得 Java 太重，所以選擇的是另一種語言 Scala，于是造成了 Java 和 Scala 兩種語言并存的局面。

而當(dāng)公司發(fā)展到 2000 人的時候，新來的員工上手很慢，因為他們需要重新學(xué)習(xí)語言，程式庫的研發(fā)效率也很低，因為它要同時支持兩個版本。當(dāng)時一個不經(jīng)意的決定成為了 Twitter 發(fā)展歷史上最大的技術(shù)債務(wù)。

因此，我們鼓勵研發(fā)人員在研發(fā)的過程中考慮里邊的組件（尤其是界面上的組件）的可用性、延展性，這樣大大降低了另一個技術(shù)的研發(fā)成本。

另外，我覺得對一個相同架構(gòu)進(jìn)行重復(fù)搭建的情況，不僅僅存在于一個公司中，在我們整個行業(yè)中也是非常普遍的。

我自己比較了解反作弊風(fēng)控系統(tǒng)，知道 Facebook、Twitter、Lyft 等每個公司都有幾十個甚至上百個研發(fā)工程師在重新搭建風(fēng)控的架構(gòu)，包括我前文提到的實施的規(guī)則引擎，這其實是一個巨大的浪費。

我個人認(rèn)為實時的風(fēng)控系統(tǒng)應(yīng)該被開源。也有很多投資者希望我去創(chuàng)業(yè)，把風(fēng)控的平臺做成一個第三方的產(chǎn)品。

不過要實現(xiàn)并不容易，因為這里需要海量的數(shù)據(jù)和大數(shù)據(jù)技術(shù)，而這些信息都來源于成熟的大公司，只有他們愿意把用戶注冊賬戶和登錄信息共享給你，你才能正確地看到數(shù)據(jù)及各種各樣的攻擊形式。

讓這些大公司開源系統(tǒng)或共享數(shù)據(jù)都很難，第一會牽涉到用戶的隱私，第二對公司的業(yè)務(wù)指標(biāo)也是一種泄露，“有多少人注冊賬號”、“多少人登陸”，通過這些數(shù)據(jù)是可以從中推出這個公司有多少用戶流量的。

踐行這條原則時需要注意的方面：

跨團(tuán)隊的虛擬組有時會導(dǎo)致程序檢查的阻滯，過度追求統(tǒng)一可能出現(xiàn)吹毛求疵的情況。

我們之前說了靠虛擬組來推廣一些規(guī)范，如果是虛擬組讓其他組里做同樣技術(shù)領(lǐng)域的人來做代碼檢查的時候，只要不是邏輯的錯誤，針對代碼的問題要提出善意的建議，不要輕易地 block 別人。

還需要特別注意的是對架構(gòu)統(tǒng)一的過分追求可能會形成某一些資深架構(gòu)師的單點權(quán)威，這樣不利于其他研發(fā)人員的職業(yè)發(fā)展，同時也限制了總體的研發(fā)速度，最終可能成為發(fā)展過程中的瓶頸。

結(jié)語

前文提到很多技術(shù)工程原理，因為時間的關(guān)系都是點到為止。希望在今后的時間里可以做更深入的分享。

這些原理都是我根據(jù)自己這十年在硅谷不同公司做技術(shù)管理的經(jīng)驗總結(jié)出來的，大家在運(yùn)用的時候一定要根據(jù)所處的競爭環(huán)境、公司的規(guī)模及人才結(jié)構(gòu)來甄別哪些東西是適合自己的，哪些東西是可以直接復(fù)制的，哪些東西是需要做改變和調(diào)整的，一切方法和經(jīng)驗的借鑒都需要適應(yīng)實際的國情和體制。

我認(rèn)為硅谷是一個技術(shù)的圣地，但不是科技的神話?？萍冀缥磥淼膸资昀铮覀冎袊墓疽鸬礁嗟囊I(lǐng)作用。

我希望更多的中國公司、更多的中國技術(shù)人可以歸納出自己的經(jīng)驗，分享給美國硅谷，也希望相互之間做更多的交流溝通，促進(jìn)技術(shù)的共同進(jìn)步。