技術的發展迎來盛世，是機遇還是挑戰？環境在急劇變化，競爭壓力在不斷增加，技術型企業和研發團隊如何在競爭的大潮中屹立不倒穩步向前？

[[212780]]

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

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

現在，隨著一些代碼的開源，隨著很多開發工具的深入人心，創新的門檻降低了，這讓更多在產品、設計方面有天賦的同學可以更好地加入到其中，這是一件好事。

過去的技術產品創新靠的是技術的壁壘，現在我們更強調的是走心，產品要抓住客戶的心理。

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

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

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

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

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

也有人覺得是人工智能，機器學習、深度學習已經不僅僅是局限在想戰勝人腦，而是想要徹底顛覆人類學習新東西時所采取的方法。

還有人說是共享經濟，現在包括衣食住行在內的我們生活中的很多活動都在實時化、個性化。

當然也有人相信是物聯網，在不久的將來，如果手機丟了，我們估計就是寸步難行、無家可歸。

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

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

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

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

國內一位有名的投資者曾經說過，新科技帶來的生產力的提高會逐漸地轉化成由資本支撐的競爭優勢，但當資本的投入到了趨于飽和的時候，規模化是我們人類社會在下一步科技出現前的一種等待。

盡管現在的科技領域非常多，但是資本介入、規模化每天都在發生。

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

在這樣的環境中，大公司還有沒有優勢可以繼續保持這樣的速度？不管是所謂的大公司，還是初創企業，面臨的最大挑戰都是人才的問題。

十年前學軟件的同學可能都在學 Java，而現在因為領域多了，人才開始比較分散。現在好的研發能得到的機會太多了，而且每一個選擇的風險成本正在降低。

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

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

[[212781]]

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

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

這三個公司屬于完全不同的產業，不同的規模，也有著完全不同的競爭壓力。然而從研發團隊管理的角度來看，我覺得他們有很多東西是共通的。

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

• 研發責任制
• 數據驅動
• 迭代式發展
• 組合型發展
• 客戶為先
• 統一性

當然這 6 條原則都是從研發角度出發的，不能代表商業競爭的全部。但作為科技公司，研發至關重要。我們推廣技術工程原則要達到的目標是：一提高效率、二保證質量、三培養人才。

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

原則1：研發責任制

研發責任制是要讓工程師能夠在“做什么產品”、“怎么做產品”等問題上有更多的發言權。

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

很多人認為只有讓研發工程師做自己有興趣的產品，才能最大地激發他們的潛能。

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

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

我們在評估工程師業績的時候，要和他們所負責產品的商業價值做直接的掛鉤，通過用戶得到的價值、利益來體現工程師的貢獻。

而對于所做產品不是面向終端用戶的研發團隊來說，我們也可以找到內部的客戶。

總之，我們要把“客戶的需求被滿足”這一指標度量化，來客觀地給研發團隊打分。

[[212782]]

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

他們甚至可以在不影響商業指標的情況下做技術與非技術的決定，提高團隊效率，比如可以由研發領頭來進行 Beta 測試等。

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

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

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

比如上文中提到的全棧，全棧不能過度，如果過度，全棧會產生對技術的不統一。

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

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

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

我們不妨拿“Google Wave”這個產品舉例，這個產品當時的目的是想改變電子郵件的呈現方式。

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

有的同學喜歡逐字逐行回復，這樣再經轉發，后來被加進來的同學就不能實時看到修改的痕跡，很難得知和參與之前的討論。

Google Wave 就是想把電子郵件通過像網絡文檔的方式來處理，把整個電子郵件鏈發展的過程呈現在眼前。

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

原則2：數據驅動

首先，數據可以幫助確定優先級。對每個公司而言，產品、項目優先級的確定都非常重要，尤其是初創公司更要學會關注。

用數據去決定優先級，而不是靠專家。無論你是做市場調查、做 Beta 測試，還是對之前的產品做一些研究，都要用數據說話。

這些數據除了用戶對產品使用的指標之外，還要考慮人力成本、要計算人均產出。要考慮團隊人數和角色構成，除了技術、產品、運營、設計等以外還有沒有其他的角色。

作為研發團隊要做到數據驅動，在討論設計的時候，就要確定數據采集的要求。數據的采集和分析是有滯后性的。

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

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

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

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

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

再有一點，不管這個產品或架構有多復雜，很多時候都可以用最簡單、最簡潔的指標去測量。

[[212783]]

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

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

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

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

所以我們建議研發團隊不能迷信數據，該做決定的時候要勇于做決定。

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

原則3：迭代式發展

迭代式發展的精髓是：先設置一個大的目標，但要一步一步腳踏實地地去達成。

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

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

比如在研發過程中有個很關鍵的環節：做代碼檢查。

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

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

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

在預定的時間內，如果沒有發現突破，沒有看到好的結果，要懂得放棄，降低實驗的成本。

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

第一，我們經常會過分強調眼前一小步一小步地去達成遠景的目標，可是這個遠景目標到底是什么？

每過一段時間我們都要根據現在的項目進度及結果來思考是不是需要調整和改變遠景目標，以免陷入一種叫“長期性的還債式的項目”。

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

如果我們只是一小步一小步地去優化這個計算，在整合中加以微調，而另一方面我們的業務還在迅速增長。

[[212784]]

在這種情況下我們每次得到的提高根本比不上業務增長所帶來的新的計算量，長此以往這個債永遠都還不清，我們的系統永遠都不能取得長足的進步。

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

第二，我們一些負責用戶增長的團隊，有的時候非常強調迭代，要做海量的實驗。但是每一個實驗從技術層面上說都很簡單。

這樣對本團隊員工的職業發展可能不是最有利的，一些很資深的工程師、架構師不愿意加入這樣的團隊。這是我們技術管理者在人才的培養和培訓方面需要解決的問題。

原則4：組合型發展

這里的關鍵是要尋找到產品的功能開發和基礎架構之間投入的平衡點，全棧式的團隊更要注重組合型的規劃。

我們建議讓技術主管、技術管理者對架構的投入直接負責；產品經理則要明確地知道不是團隊中所有的人力資源都能放在做產品上。

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

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

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

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

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

首先，組合型規劃要避免在團隊中出現小團隊。如果明確劃分你是做產品的，我是做基礎架構的，那這個全棧團隊的意義就消失了。

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

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

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

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

這一進程多次延緩或阻礙了產品功能的迅速推出。這就是上文說的當你有了組合型的規劃，并對基礎架構足夠投入的時候，如果過度追求完美，也會帶來負面的影響。

原則5：客戶為先

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

這里有很多實踐案例，比如一個公司的設計團隊除了追求美學上的完美設計，還要把研發、產品團隊的進度納入到自己團隊的工作計劃中去。

做品牌架構的同學經常會抱怨產品組把系統拖垮了，實際上你作為做平臺的人就要把整合測試和壓力測試作為自己的工作，要爭取做出怎么用都用不壞的平臺，這才是最好的架構。

[[212785]]

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

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

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

當有一些團隊（特別是面向公司內部的服務型研發團隊）做出了成績，提高了其他客戶團隊的效率，我們希望有一個閉合反饋環，團隊之間達成共贏，促進共同發展。

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

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

原則6：統一性

全棧團隊容易造成各個部門之間技術實現的不統一。這時我們可以在全公司范圍內跨團隊地形成專門針對某個技術領域的虛擬組，由這些虛擬組來推廣規范。

當然這里覆蓋的面很廣，大到技術選擇(technology)、架構(architecture)，小到設計模式(design patterns)、代碼規范(code style)等。

再舉一個與統一性原則相悖的例子：

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

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

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

另外，我覺得對一個相同架構進行重復搭建的情況，不僅僅存在于一個公司中，在我們整個行業中也是非常普遍的。

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

我個人認為實時的風控系統應該被開源。也有很多投資者希望我去創業，把風控的平臺做成一個第三方的產品。

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

[[212786]]

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

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

跨團隊的虛擬組有時會導致程序檢查的阻滯，過度追求統一可能出現吹毛求疵的情況。

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

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

結語

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

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

我認為硅谷是一個技術的圣地，但不是科技的神話。科技界未來的幾十年里，我們中國的公司要起到更多的引領作用。

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

[[212787]]

沈思維，就讀于密歇根大學和卡耐基梅隆大學，畢業后加入 Google，任高級研發經理，現為 Lyft Engineering Director，專注風控領域，在反欺詐，反垃圾信息方面有非常豐富的經驗。