作者 | 洪亮劼

編輯 | 小智

微軟亞洲研究院、百度研究院、阿里巴巴達摩院……研究院在互聯網公司是一種怎樣的存在？互聯網公司到底該不該設立研究院？研究院在公司內部又該起到怎樣的作用？怎麼能夠設置一個有效的研究院架構？怎麼來衡量研究院是否成功？本文嘗試給您一個解答。

什麼是研究院

前百度研究院首席科學家吳恩達

在我們討論其他話題之前，我們首先來看看目前互聯網公司的各種研究院有什麼特徵。怎樣的團隊就算是一個“研究院類型”的團隊（因爲有一些公司並不直接單獨稱這些團隊爲“研究院”）。我們這裏總結下面這麼一些特徵:

特徵一：以博士爲核心組成的團隊

大多數研究院的核心人員，甚至是全部研發人員都具有博士或以上（含博士後、有教職經驗）研究經歷。這個特徵是因爲很多研究院需要解決的問題或者研究的方向是產業的前沿，的確需要有掌握高級知識的人才進行研發工作。然而這個特徵也直接導致了很多其他問題，那就是一個以博士爲核心組成的團隊和其他團隊來比較，有一些其他團隊所不具備的特點，爲管理工作帶來了額外的挑戰。

比如，很多博士習慣做長期項目（三個月以上甚至更長）。這些研發人員很不習慣更換項目，而且博士對於項目就像是研究課題，有個人的歸屬感和榮譽觀，這是好事也是壞事。再比如，博士希望有比較長期的職業規劃，對於自己的研究方向希望能夠有所延續，能夠參加學術會議，能夠發表論文。這些需求都是其他一般的研發團隊一般不具有的。如果一個研究院的管理層不能正視這些需求，則很難形成一個有很強創新力和執行力的團隊。

特徵二：相對比較獨立的運作環境

儘管我們後面要提到，很多研究院都和產品部門有或多或少的聯繫，有時候甚至和產品部門有密切的合作，但絕大多數研究院，都需要有一個相對比較獨立的運作環境。比如，研究院是一個獨立的團隊，有自己部門的領導（而不是工程部門的兼任），有自己部門的單獨預算，有自己部門的 KPI，有自己部門的組織結構和運作模式等等。這些都是建立一個研究院獨立的形象。而且，也由於我們剛纔提到的第一個特徵，也就是研究院以博士爲核心的特點，一個相對獨立的運作環境有助於管理這一個可能和公司其他部門組成結構非常不一樣的人羣（因爲這個人羣的需求可能很不一樣）。

特徵三：研究院不是產品部門

絕大多數研究院作爲一個獨立的運行實體都不直接掌管（Ownership）產品線。研究院可以作爲產品部門的協作單位，但大多數成熟的研究院均不直接運作產品線。一個簡單的原因是，產品線的研發和運作與研究院的目標是不完全一致的。那麼這一點特徵，可能會帶來研究院在管理和定位上出現問題。我們下面會提到研究院的目標中就要來分析一下，在不掌管產品線的情況下，研究院如何能夠保持其在公司內的影響力。

上面三個特徵只是研究院諸多特徵中的代表。然而我們已經可以看出，研究院在現代互聯網公司中的一個比較特殊的地位：人員構成、運作模式、需要爲產品做貢獻但又不是產品部門。正是因爲有這些特點，成功運行一個研究院對於現代高科技企業來說，是一個巨大的管理挑戰。

研究院的目標

什麼樣的公司需要研究院呢？要回答這個問題，我們必須要來看，什麼樣的產品需要研究院的支持。有兩類產品很適合搭配研究院：

比較成熟的產品。
和公司現在產品線沒有太大關係的前沿產品，有時候也叫“打月亮”（Moonshot）產品。

我們先來說說爲什麼“比較成熟的產品”適合搭配研究院。成熟的產品，已經有了比較成熟的數據鏈條（Data Pipeline)，能夠使得基於數據（Data-Driven) 的研究工作有了可能性。而目前幾乎所有的前沿研究，包括機器學習（Machine Learning)、人工智能（Artificial Intelligence）、數據科學（Data Science）等都無一例外非常強烈依賴於大量的數據。沒有數據，絕大多數這類研究都沒法進行。早期的產品並不具備這樣的條件。

比如，產品部門需要推出一款新的手機 APP，而如果這個應用有比較多的功能之前並沒有在公司其他產品中存在過，那麼研究部門很難進行基於數據的研究工作。成熟的產品，也有相對比較成熟的衡量指標（Metrics）。這一點對於數據驅動的研究來說額外重要。因爲有了衡量指標，就能夠圍繞這個指標展開特定的研究工作，設計相應的模型和算法，提出合理的優化解決方案。

比如，當前的產品是搜索引擎，那麼研究院就可以針對搜索引擎的成功衡量指標進行建模，更新搜索排序算法等等。早期的產品一般也沒有固定、和合理的衡量指標，這會讓大多數的研究工作一籌莫展。當然，研究院可以幫助產品部門建立衡量指標。不過這也是一個需要一定時間的過程。在這個過程結束前，其他的研究工作很難進行。

我們再來說說爲什麼和現有產品線沒有太大關係的前沿產品也是比較適合搭配研究院的原因。我們剛纔提到研究院的特點的時候說到，絕大多數研究院都是相對比較獨立運行的團隊或者機構。這個特點就非常利於研發前沿產品。前沿產品因爲其高失敗率的特點並不適合普通的已經有成熟產品運維壓力的產品部門進行研發。同時，前沿產品的“前沿”特點也使得研究院成爲這種類型產品研發當仁不讓的選擇。另外，前沿產品一般並沒有一個特定的產品公佈時間表。

這和前面所說的“非成熟”或者早期產品不一樣。早期產品，儘管沒有數據，沒有成功指標，但往往有驚人的產品公佈時間表，產品上線壓力很大。而前沿產品，雖然也沒有數據，也沒有成功指標，但一般沒有上線壓力。這也就給了研究院自由空間去收集數據（比如 Google 的無人駕駛車），定義成功指標，進行迭代。當然，從這個角度來看，這也直接導致了，前沿產品的研發週期非常長，而且也很難去定義其上線的時間，於是成爲其失敗率高的部分原因。

在我們瞭解了什麼樣的產品比較容易搭配研究院以後，我們再回到最開始的那個問題，“什麼樣的公司需要研究院”。如果一個公司的產品線相對還不穩定，很多產品處於快速迭代的狀態下，這個時候，這樣的公司其實並不太適合建立研究院。因爲絕大多數產品線都沒法真正“享受”到研究院的成果。如果一個公司並沒有足夠穩定的內部環境和財務基礎，那麼這個公司也就沒有研發前沿產品的基礎。那自然這樣的情況下，配置一個以研發前沿產品爲導向的研究院就更加顯得沒有必要。基於這樣兩個原因，絕對多數的初創公司，或者其實說，在上市前的初創公司都並不真正具備配置研究院的內外部環境。只有相對比較穩定的公司纔有對研究院真正的需求。

值得注意的是，我們也可以從這裏關於研究院和產品線的討論引申得到這麼一個結論。因爲研究院最大的功效是在對成熟產品的優化和改進上，以及對前沿產品的研發上，要想依賴研究院對一個公司的商業模式進行創新，或者寄希望研究院對快速迭代的產品產生貢獻使得公司進入高速增長期都是不可能完成的任務。這些不切合實際的初衷往往給研究院的定位和發展帶來困境。從另一個角度來說，那就是研究院可能對公司的長期商業運行可能會有比較大的影響（比如一些前沿產品如何研發成功），但在中短期來看，影響是相對比較有限的、是漸進式（Incremental）的（主要來自於對成熟產品的優化）。

研究院的架構和運行

在我們瞭解了什麼樣的產品需要研究院，什麼樣的公司需要配備研究院以後，我們現在就來探討一下研究院的架構問題。

我們上面提到了研究院在公司內部需要有一定的獨立性。但是，現代高科技公司，畢竟從根本上來說還是追逐利潤的企業，如何來確保研究院能夠從長期上是符合公司發展的利益呢？這一點，是研究院生存的根本。

從歷史上來說，早期研究院很多都是這麼一種運作模式：

研究院的科學家針對某個技術難題（這個技術難題有可能是來自產品工程部門，也有可能是研究院的科學家自己發現）找到了一種解決方案，形成一個研究成果。
根據不同的研究院的情況，科學家可能會選擇發表研究成果，形成論文，或者是申請形成專利。
科學家根據這個研究成果做出一個解決方案的原型（Prototype）。
研究院團隊根據解決方案的原型，到產品工程部門進行遊說。產品工程部門根據自身的需求和產品週期，決定是否要把目前的原型重新在工程中實現，從而在下一代產品中使用上這個新成果。
產品工程團隊和科學家一起把原型在工程代碼中重新實現。

這個模式看似有一定道理，但也存在一些非常關鍵的問題。

首先，第（1）步中就直接存在可能導致第（4）和第（5）沒法發生的誘因。我們假設研究院的科學家拿到的技術難題是來自產品工程部門的。從現代產品的角度來說，一般的產品工程迭代都非常快。現在的技術難題可能幾個星期後就有了能夠解決 80% 問題的解決方案。也就是說，研究院拿到的技術難題有可能是有時效性的。這並不代表這些技術難題隨着時間都有可能被解決，而是說，隨着時間進程，很多技術難題可以出現多種解決方案。科學家能夠找到的比較完美的解決方案（姑且假設能夠 100% 解決問題）需要（2）-（5）這些步驟進入產品，這必然導致產品部門必須在科學家方案推出之前找到可以運行但很粗獷的方案。

然而這種方案一旦進入產品，就會成爲日後科學家的完美方案進駐的強大阻力。因爲產品工程部門會覺得，在產品已經進一步迭代的情況下，是不是有精力和時間去改進一個已經可以運行的方案爲更加完美的方案，其實是一個很棘手的問題。這也就會導致步驟（4）常常非常政治化（Political），成爲各個團隊扯皮的重要原因。剛纔說的，還只是假設研究院的科學家拿到的技術難題是來自產品部門的，還有很多情況是，科學家或者研究院自身認爲某些技術難題需要得到解決。這樣發展出來的研究成果或者產品原型往往就更加難以通過第（4）和第（5）步得到產品化。

因爲第（4）和第（5）步的不確定性，很多研究院在發展過程中，往往把第（2）和第（3）步作爲績效評定的重要結果。這也就導致了很多研究院的成果只能完成第（1）步到第（3）步這個流程。而第（4）步成爲了研究院成果產品化的不可逾越的鴻溝。

那麼如何運作研究院能夠跨過這個鴻溝呢？雅虎研究院在過去 10 年的時間裏對這個問題有着不錯的實踐經驗。這裏的核心問題就是如何把研究院的目標和一般產品工程團隊的目標統一起來，使得大家對於產品的開發和運作是同步的。我們這裏要提到這麼一個概念，那就是“共享目標”。什麼意思呢？那就是研究院和產品工程團隊雖然從行政上隸屬不同的部門，但在項目開發上，兩個團隊必須組成一個“虛擬團隊”，有統一的領導和統一的進程管理，並且執行統一的、共享的目標。研究院和產品工程團隊只是在這麼一個共享的、統一的目標下分工不一樣，責任不同而已。

具體說來，以筆者參與過的雅虎首頁推薦系統爲例。產品工程團隊每個季度都會和研究院的研究團隊一起指定目標。這個目標是一個綜合性目標，有產品的部分（比如提高多少用戶訪問、提高多少用戶點擊），有純工程的部分（比如如何加快代碼部署），有研究的部分（比如應該採用什麼模型來達到用戶訪問的提高、比如應該怎麼加快模型的訓練速度）。那麼，“虛擬團隊”就會根據這個綜合性的目標來分配資源，確保整個團隊的工作量和各個方面的目標達到一個不錯的平衡。目標共享以後，研究院的研究週期得到了明確，也就是每個季度。同時，研究院的“成果落地”得到了保證，那就是直接和產品對接，每一個季度都需要“上線”。這種模式下的研究院團隊，也不會去做“天馬行空”的項目，而是僅僅圍繞產品工程，做很多“增量式”的創新工作。

“共享目標”對於雅虎的很多產品決策過程以及運作過程產生了深遠的影響。首先，那就是採用“共享目標”架構的產品全責更加清晰，工程負責什麼，研究院負責什麼，設計師負責什麼，每個季度這幾個方面一目瞭然。另一個非常顯著的改變，那就是這些產品第一次把 AI（這也就是研究院往往負責的部分）、工程以及設計三個方面作爲一個產品每個季度推進的三個主要方面。也就是讓 AI 成爲了產品的目標的一類公民。

那麼，“共享目標”是不是就解決了研究院的運作問題了呢？答案是，不完全是。首先，“共享目標”聽上去容易，但在實際運作中難度其實還是很大。這裏面最重要的是信任問題。從公司結構上來說，產品工程團隊往往對產品有“所有權”（Ownership），自然希望能夠對產品的方方面面有所把握。然而在“共享目標”的框架下，實質上發生的則是，研究院對於產品的部分方面有了一定的決策權和執行權，這勢必需要產品工程團隊的領導和人員對於這方面有足夠的認識和預期。實際上，從另外一種角度來說，這種“共享目標”其實就是產品工程部門把部分產品開發方面長期外包給了研究院的團隊。雅虎的產品工程團隊能夠和研究院針對某些產品這麼做，是因爲研究院長期以來能夠對這些產品持續做出不俗的貢獻，贏得了信任。但並不是所有的產品都能夠在這樣的框架下運作。

同時，因爲和產品工程達成“共享目標”，這勢必也就造成了研究院的研究目標和成果相對比較“短視化”，常常迎合了產品週期。這也就呼應了我們之前提到的，比較適應研究院的一類產品，那就是成熟產品。實際上，“共享目標”的模式很好的契合了成熟產品的迭代。

對於前沿產品來說，這樣的架構顯然不太適用。因爲這個時候產品和工程組可能都還不存在。對於這樣的項目來說，最好以研究院的科學家爲核心，然後輔以工程師作爲支持。從某種意義上來說，這依然是一種“共享目標”，不過則是之前談到的相反的結構。

研究院的成功

之前已經討論了研究院的架構和運作，那麼，我們怎麼能夠保證研究院的成功呢？我們這裏談兩個比較顯著的問題。

第一個方面那就是研究院需要怎麼樣的領導。這個問題看似很簡單，其實需要相當認真的思考。因爲研究院需要負責招聘大量的博士層次的候選人。因此一個有聲望的、在學術圈有一定地位的人擔任研究院的領導勢必會對招聘起到很大的幫助作用。同時，因爲對於具有博士文憑的研究人員的背景更加熟悉，有學術背景的領導往往更加能夠制定人性化的管理方案，讓這些博士覺得能夠放心工作（比如對於參加學術會議的鼓勵，比如對於發表論人的支持等等）。相反，如果這個領導只有工程背景或者是產品背景，即便是以前公司內部的高管，因爲背景的差異，除了在招聘方面可能會遇到困難以外，在日常的管理上也可能無法往往都很難勝任研究院領軍人這個職務。

然而這方面的反面，則是從學術圈裏直接挖來一些知名教授，來領導研究院。這裏面有一些公司希望能夠通過教授名氣來吸引眼球的目的，而另一方面，也是希望知名教授能夠帶來招聘上的便利。不過，這樣的行爲往往忽視了這些知名教授在學術圈的日常運作和公司運作的巨大區別。就算是知名教授，不少人也很難直接管理超過十個學生，而在大公司，特別是研究院這個級別的組織中，管理超過幾十人甚至上百人，並且有可能管理其他的中層領導，那麼絲毫沒有經驗的人往往沒法勝任這樣的複雜協作分工管理。同時，沒有公司經驗的教授也往往無法在很短時間內領會到現代企業文化（比如晉升、比如公司政治、比如資源協調），能夠爲自己的團隊在衆多的團隊的合作與競爭中謀取相應的利益。

因此，比較合適的研究院的領導是至少有一定工業界經驗，但可能早年在學術圈或者學校任職的優秀科技管理者。比如雅虎研究院的第一任領導 Prabhakar Raghavan，就是這樣一位人物。首先其人本就是知名的學者，出版過知名教科書《Randomized Algorithms》和《Introduction to Information Retrieval》，並且是 ACM，IEEE 的院士，也是美國工程院院士。同時，其在加入雅虎之前，已經在 IBM 研究院以及 Verity 任職多年，特別是 IBM 的經歷，讓他對企業文化和工業界的研究機構有了很深的瞭解。可以說 Prabhakar 到雅虎之後很快就能建立起一個非常有效的團隊，吸引了一大批的知名學者諸如 Andrei Broder、Ricardo Baeza-Yates、Alex Smola 等的加入，這和 Prabhakar 本人的背景可以說息息相關。同時，我們之前提到的關於研究院的運作規律，這其中有很多都是 Prabhakar 總結了他在多個組織的任職經驗以後，在雅虎慢慢發展成熟起來的。

第二個問題就是公司上下一定要對研究院究竟能給公司帶來什麼樣的價值有一個清晰的判斷。從我們剛纔的一系列論述來看，研究院雖然在很多產品的研發中佔有舉足輕重的地位，但總體說來在公司是還是一個合作者的角色，是一個錦上添花，而非雪中送炭的角色。從這一點說來，整個公司的管理者和運行者要十分清楚。

不過我們也要防止把研究院的價值庸俗化或者完全以產品成果爲唯一的衡量標準。比如 Google 收購了位於倫敦的 DeepMind 團隊來做深度學習的研究工作。DeepMind 最近幾年的研究成果，外加炒作的沸沸揚揚的 AlphaGo 究竟直接爲 Google 的線上產品帶來了多大收益恐怕很難直接衡量。但是 DeepMind 引領的這股深度學習的風潮，讓 Google 在吸引這方面的人才這一方面則形成了巨大優勢。這部分爲 Google 節約的公關廣告成本或者招聘陳本應該很容易就能覆蓋對 DeepMind 的運營陳本。

同時，DeepMind 的成果，雖然很多不能直接應用到 Google 的現有產品上，但是 Google 的領導人藉着這股風潮，讓公司更多的工程師和產品人員開始深度介入深度學習領域，在內部進行了很多培訓和推廣工作，也是利用 DeepMind 這個研究團隊來達到了原本不容易達到的目的。當然，從長遠來看，研究院還是需要從產品和視角（Vision）上爲公司帶來價值，而且這些價值是普通研發團隊所不能帶來的。

寫在最後

我們在這篇文章裏詳細討論了什麼樣的互聯網公司需要研究院，研究院又適合在什麼樣的產品線上發揮作用。我們還在這篇文章中深入剖析了研究院的研發團隊如何和一般的產品工程團隊合作，能夠爲現在成熟的產品線或者是前沿的產品的研發提供有力的支援。最後我們談了一下制約研究院成功的兩個關鍵的因素。本篇文章是第一篇比較完整得系統性闡述互聯網公司以及研究院制度的文章，希望能夠起到拋磚引玉的作用，讓大家更加深入思考如何讓研究機構在現代企業，特別是高新技術企業中生根發芽。