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

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

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

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

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

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

因?yàn)橛辛似脚_(tái)的出現(xiàn)，創(chuàng)新的資本要求也降低了，資金可以重點(diǎn)用在用戶增長(zhǎng)方面，而不是更多地花在基礎(chǔ)建設(shè)和硬件上。

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

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

有人說(shuō)是自動(dòng)化的再次爆發(fā)，無(wú)人機(jī)、無(wú)人車，連機(jī)器人項(xiàng)目都已經(jīng)開始做成平臺(tái)了。

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

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

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

因?yàn)闆](méi)有手機(jī)你的汽車就不能發(fā)動(dòng)、你就打不到車，就算走回了家，估計(jì)沒(méi)有了手機(jī)你連房門都打不開。

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

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

因?yàn)樵诿總€(gè)時(shí)期，最后只有那么一家或者幾家公司可以代表這個(gè)時(shí)代。

國(guó)內(nèi)一位有名的投資者曾經(jīng)說(shuō)過(guò)，新科技帶來(lái)的生產(chǎn)力的提高會(huì)逐漸地轉(zhuǎn)化成由資本支撐的競(jìng)爭(zhēng)優(yōu)勢(shì)，但當(dāng)資本的投入到了趨于飽和的時(shí)候，規(guī)?；俏覀?nèi)祟惿鐣?huì)在下一步科技出現(xiàn)前的一種等待。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我們?cè)谠u(píng)估工程師業(yè)績(jī)的時(shí)候，要和他們所負(fù)責(zé)產(chǎn)品的商業(yè)價(jià)值做直接的掛鉤，通過(guò)用戶得到的價(jià)值、利益來(lái)體現(xiàn)工程師的貢獻(xiàn)。

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

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

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

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

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

踐行這條原則時(shí)需要注意：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

什么叫有獨(dú)立性的指標(biāo)？因?yàn)橛幸恍┖芎玫闹笜?biāo)都不具有獨(dú)立性，這里跟大家舉一個(gè)不能算反例的“反例”。

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

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

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

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

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

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

踐行這條原則時(shí)需要注意的方面：

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

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

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

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

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

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

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

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

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

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

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

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

踐行這條原則時(shí)需要注意的方面：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

踐行這條原則時(shí)需要注意的方面：

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

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

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

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

整個(gè)過(guò)程 Twitter 花了四年半的時(shí)間，因?yàn)槟繕?biāo)是要把每一行代碼都從這個(gè)單一的程序庫(kù)中挪出來(lái)，變到其他的組件中去。

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

原則5：客戶為先

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

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

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

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

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

踐行這條原則時(shí)需要注意的方面：

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

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

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

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

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

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

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

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

而當(dāng)公司發(fā)展到 2000 人的時(shí)候，新來(lái)的員工上手很慢，因?yàn)樗麄冃枰匦聦W(xué)習(xí)語(yǔ)言，程式庫(kù)的研發(fā)效率也很低，因?yàn)樗瑫r(shí)支持兩個(gè)版本。當(dāng)時(shí)一個(gè)不經(jīng)意的決定成為了 Twitter 發(fā)展歷史上最大的技術(shù)債務(wù)。

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

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

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

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

不過(guò)要實(shí)現(xiàn)并不容易，因?yàn)檫@里需要海量的數(shù)據(jù)和大數(shù)據(jù)技術(shù)，而這些信息都來(lái)源于成熟的大公司，只有他們?cè)敢獍延脩糇?cè)賬戶和登錄信息共享給你，你才能正確地看到數(shù)據(jù)及各種各樣的攻擊形式。

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

踐行這條原則時(shí)需要注意的方面：

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

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

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

結(jié)語(yǔ)

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

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

我認(rèn)為硅谷是一個(gè)技術(shù)的圣地，但不是科技的神話?？萍冀缥磥?lái)的幾十年里，我們中國(guó)的公司要起到更多的引領(lǐng)作用。

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