千人規模網際網路公司研發效能成功之路
這是「研發效能團隊規模、職能劃分和優劣勢分析」系列的第四篇。上篇文章「中小網際網路公司研發效能團隊規模、職能劃分和優劣勢分析」主要分析產研團隊在200人以下的中小公司現狀以及給出一些建議。本篇文章主要分析產研團隊在1000人規模的二三線中型網際網路公司研發效能現狀，並結合自己的切身體會，在組織架構、工作職責、優劣勢、以及怎麼幹怎麼拿到結果，給出了自己的一些建議。
公司規模
- 產研團隊1000人左右
- 團隊規模：10-30人左右
組織架構
產研團隊從200人到1000人是一個很大的跨越，領域細分、職能細分、管理職能也會上線。細說一下這幾點不同：
- 管理職級：開始出現管理職級。之前公司比較扁平，恨不得CEO下面就是員工。但是人到1000的時候就會分級了。老闆也管不了那麼多人，需要分級管理。網上的建議是一般中高層管理者一個人管理5—8人，最好是7；基層管理者一個人管理10—15個人，最好是12。
- 領域細分：200人的公司，可能產品研發測試運維都一個人擔了，但是1000人的公司很少有這種情況發生。首先一個人很難在這麼多領域知識都專精；其次都專精的人肯定價格很高，除非公司合夥人否則200人的公司很難留下這樣的大牛；最後一個人再能幹畢竟精力有限。大公司招到這樣的人也會把他放在一個很高的位置，站在更高的位置提升團隊效能，做好管理，然後讓專業的人幹專業的事。這也是我強調專業分工、協同合作理念的原因。
- 再多說一句就是，在外企可能通過技術升上去級別很高但一個人都不帶的人很多，但是在國內這種情況非常非常的少。比如在快手有幾個技術達到最高階的大佬，也都是掛了一個管理職級的。
- 專業團隊：200人的團隊可能僅有一個設計師，彙報關係可以簡單些，但是1000人規模時有10個設計師，這個時候就需要單獨成立一個UI/UE團隊，甚至是設計中心；之前零散在各個團隊中的PMO也會收攏到一個團隊；之前找個寫SQL的出出報表就可以了，現在一般會建立單獨的巨量資料團隊，資料分析團隊，AI團隊等，在200人的時候肯定會有人做類似的事情，但很少會作為一個專業團隊的形式存在。很多事情，一旦上了規模就會有很大不同，包括產品架構、實現方式、效能指標要求等。
研發效能團隊就是一個在研發基礎設施建設領域細分的專業團隊。一個可選的組織架構如下圖。
組織架構：CTO-研發效能部
- PMO團隊職責：推動戰略專案落地，支援研發專案管理和交付，確保有效執行；搭建專案管理體系，完善流程制度；促進跨部門協同；識別潛在風險並推動問題解決
- 平臺產品：產品規劃，制定產品發展策略，並推動落地；負責競品研究，行業研究，瞭解前沿的技術和產品發展思路，並能夠制定有競爭優勢的發展路徑；瞭解需求場景，抽象制定平臺需求
- 平臺研發：負責平臺產品的預研、架構、研發；負責平臺架構設計與深度優化；緊跟業界前沿，針對不斷增長的業務需求提供技術解決方案。
- 平臺運營：負責平臺產品的整體運營管理，針對平臺產品自身特點以及市場狀況制定產品運營規劃、戰略、佈局並實施；負責產品的定位、媒體宣傳、市場推廣、渠道建設和客戶服務的整體策略和計劃的制定和實施；組織產品運營資料分析和市場狀況分析，根據分析結果指導運營策略制定和實施；
這個組織架構圖和15年五八同城 TEG 情況比較相似，那個時候全公司的產研團隊就是1000人左右，把支撐企業級跨產品、跨專案的綜合能力集中在一個部門，提高人才和專業密度，互相共同作業把思想、策略、實踐注入到平臺上產品中，打造了支撐通用研發能力的實踐平臺 iWork，也就是五八同城的一站式研發管理平臺，研發效能團隊主要能力已經都集中到了這上面，功能完備，體驗一致，全流程打通，一站式解決產研工作中的大部分問題，有效提高了產研效能。在五八待過的產研小夥伴肯定知道這個平臺。
滴滴研發效能團隊和此組織架構有很大不同。17年初滴滴產研團隊已經4000+了，和本文的主要參考產研規模有很大出入。滴滴研發效能起步早、起點高，做得更專業更細分。滴滴研發效能團隊在EP部門下，EP下除了研發效能，還有體量更大的企業資訊化業務。在實際執行時會把平臺產品、平臺研發和平臺運營縱向切分成一個個特性團隊（Feature Team）負責一個個的產品。我覺得這是非常好的一種做法，後面我會專門有一篇文章來介紹FT的工作機制。有人問QA小夥伴在哪裡？其實我一直有一個觀點：負責實際業務日常交付的QA團隊單獨成為一個團隊，很難貼合業務發展，不符合FT的風格。針對業務功能測試的QA小夥伴，應該直接劃分到業務線，貼近業務保證質量，業務閉環，職能閉環，權責閉環；做工具、平臺的QA小夥伴應直接併入研發效能，形成一個產研基礎設施團隊(infra team)統一支援產研工具平臺的建設。
舉三個例子：
我加入五八同城比較晚，「據說」當初也是有個大QA部門，後來給拆了。留了一部分在TEG，其它也都劃分到業務線。
滴滴的質量部一開始也是500人+ 的大部門，後來打散，負責業務測試的直接劃分到業務線；做QA工具、平臺很大一部分直接劃分到了效能平臺部（EP）。
快手的質量與效能部人數最多的時候有700人？比很多業務部門的人數還多。實行沒兩年，直接打散，負責業務測試的直接劃分到業務線；做QA工具平臺的部分直接劃到了基礎技術部。
快手的質量與研發效能部最初有這個組織架構的影子，除了PMO是在CTO下，其它大部分相同，不過質量與研發效能部最後也被拆了。
其實我最近一直在思考PMO的位置應該在哪裡？直接彙報CTO，手持尚方寶劍，上斬業務大佬下斬小嘍囉，成為管理各個業務線的抓手；還是成為業務線老闆的業務助手，在專案管理上出謀劃策、為業務老闆分憂解難，解決產研同學做業務中遇到的實際問題？如果你有好的建議，也請告訴我，謝謝。
發展策略
在產研團隊1000人的公司，研發效能團隊的主要職能和產研團隊在200人的公司有很大的差異。產研團隊在200人的公司，研發效能團隊主要職能在維護一套用開源+商業軟體搭建的研發基礎設施，保證基礎設施可用、穩定，只能解決有無的問題。畢竟人力和資源有限，主營業務更需要多投入。但是到產研團隊在1000這個數量級，其實我們已經有資源去做更多更好的基礎設施建設了，開始做 1 到 N，這段是更有意思也更有價值的部分。為什麼呢？
- 人力成本劇增。每個網際網路公司，人力成本都是個大頭。每增加一個產研同學，人力成本線性增加，但是研發效能卻不會線性增加，還可能因為共同作業不當增加更多的溝通成本團隊產能反而下降。
- 日積月累的技術債、技術坑：攻城略地帶來業務增長的同時，也在身後留下了很多需要還的技術債、需要填的技術坑。之前靠堆人做的事情，現在該考慮下高效的做法了。
- 修煉內功，降本增效：當行業增速沒那麼大的時候，做好內部基礎設施建設也是提高公司行業競爭力的有效手段。研發效能帶來的效果和團隊規模有關，而且是一個乘法關係。團隊規模越大，做好研發效能對企業帶來的效率和質量的提升越高。
在這個規模，我建議開源+商業軟體+部分自建，雖然整體體驗有損失，但是可以在最小投入下最大程度滿足功能性需求，同時在有限的資源條件下加大自研部分佔比，提高整體水平。
研發基礎設施的建設絕非一朝一夕之功，呼嚕呼嚕招一幫人想做個幾個月就能解決基建的問題就太樂觀了。否則脈脈上也就不會出現那麼多對基礎設施的吐槽。
唯二大家都很讚的團隊是美團和阿里，證明這兩家的基礎設施建設大家都還是非常認可的。
組織架構優勢
- PMO始終在研發效能下，平臺工具+PMO一起下業務線推廣對EE的發展特別有幫助；PMO從業務線收集到的使用者訴求，部分會轉化為對效能平臺的需求
- 架構部和研發效能組織上離的比較近，所以有很多框架和技術工具方面的共建會比較好推進，比如工程規範、框架推廣等
- 運維部和研發效能部組織上離的也比較近，我們的很多基礎設施依託於運維部的支援，互相合作，比如釋出功能，重啟、灰度、資源管理等
- 統一支撐產研共同作業的基礎設施（包含QA平臺建設），資源利用最大化，邊界合理清晰。
團隊劣勢
- 研發效能團隊和運維團隊的邊界需要明確，實際上有時不是那麼清晰的，需要雙方負責人識大體，顧大局。效率工程部解決這個問題的方法比較簡單，涉及使用者部分的產品開發工作都放在研發效能團隊負責，系統管理部分運維團隊可自建。
- 因為沒有「大QA部門」，研發效能團隊對QA團隊對業務訴求感知度低，需要通過不斷合作和共建來推進工作。
實操經驗總結
- 找對人
- 人，是第一生產力。研發效能這個領域比較專精，招聘時需要好好區分。怎麼招人可以參考這篇文章「找到能做好研發效能的人」。做不出東西來方向找的不對事小，把業務做爛了影響公司發展事就大了。
- 這方面的專家一般來自專案管理、設定管理、QA、流程改進，運維，這些人都是有實際平臺操作經驗的；隨著雲端計算、雲原生的發展，應用運維、少部分架構、研發也進入了這個領域。現在可以直接招聘「研發效能」「工程效率」「DevOps」相關的人了。招就要招你能招到的最好的人，這都是寶貴的人才，尤其是一線大廠的人是很難找的。比如阿里雲效團隊、螞蟻研發效能團隊，騰訊TEG、PCG，美團研發質量與效率部、百度效率雲、滴滴EP等，實在找不到人可以去這幾個大廠挖，當然他們這些團隊也同時都在招人，感興趣的也可以去聯絡 :)
- 只要找對了人，後面就好辦了。牛人是自帶光環的，相應的團隊怎麼構建，公司需要迫切在哪方面投入、招聘什麼樣的人來做什麼事情......只要招來對的人這些事情就都能迎難而解。關鍵是招到對的人，這是破局關鍵。
- 搭好班子
- 組織架構是第二生產力。搭建好適合業務發展的組織架構才能最大限度發揮人才的作用。招來了牛人不能擺著，要給他配團隊配資源。巧婦難為無米之炊，巧婦已經讓咱給請回來，我們就要給她找洗碗的、配菜的、傳菜的，這樣才能做出一席好菜。找不到牛人做的東西爛，我們也就認了；如果找到了牛人，不會用，用不好那也是挺可惜的。
- 走正路
- 畢竟下面團隊瞭解到的資訊有限，很多時候上層可以給出更多的背景資訊，這樣大家一起找到一條可以實現的正路子。這就要因地制宜，相機而動。時機太重要了，很多時候轉瞬即逝，一旦失去，後面千辛萬苦未必能成。所以都在說天時地利人和，而不是地利人和天時，或者人和地利天時。
願各位能找到不錯的公司、不錯的領導、不錯的團隊，此生盡興、赤誠善良，做自己擅長也喜歡做的事。
推薦閱讀