互聯網公司研發效能/工程效率團隊建設和規劃
這是「互聯網公司研發效能團隊建設」的第二篇。為啥研發效能要是一個相對獨立的團隊呢？獨立的研發效能團隊是最大化行使職能的必要保障。我一直認為組織架構是第二生產力(第一是人)。搭好檯子好唱戲。檯子左右不平，前高後低，再大的角都可能崴腳跌跟頭。
最近在想一個問題：研發效能算公司業務還是算基礎平台、技術中台、技術工具？怎樣才能做得更好？
我們可以定義研發效能團隊的工作邊界是(需求管理+任務管理+項目管理)平台+devops+APM+應用運維，負責從用戶需求提出到上線、到應用運維的整個過程，它的存在就是為了打破團隊之間割裂、各自為戰的情況，同時可以把各個團隊共性的需求集中統籌，使整個開發活動能夠順暢、高效的運行。研發效能團隊一旦和某一個團隊在一起，卻沒有更高的視野去思考這個事情，把控好業務方向，業務可能就會跑偏。研發效能靠近哪個團隊，就會側重哪個團隊的業務，對哪個團隊服務的職能就做得好，對整個研發過程的關注度就會降低，從而研發效能團隊的定位和作用會受到影響。
研發效能+運維團隊
研發效能團隊和運維團隊在一起，這種組織架構我是看到過的。一開始快手的運維小夥伴也同時負責流水線部分的建設。這個是可以理解的，因為運維小夥伴負責公司的基礎設施，公司的服務想要上線到運維的基礎設施上必然要有一個上線系統。順手牽羊，運維小夥伴就把流水線也給做了，他們也只做到了流水線。流水線之前的部分就沒參與，因為那些和運維關係不大，同時受限於人力物力，運維小夥伴就沒涉及流水線前面的部分。和機器運維部分相比，產研場景更靠前，涉及產品經理、項目管理、RD和QA同學部分的流程化、標準化、自動化要難得多。這種組合優劣勢非常明顯：
優勢：
- 部署和監控日誌告警、運維繫統銜接得很好
- 部署時的各種模板也很貼心，滿足了各種「業務」的需要
- 從源碼到上線都可以通過流水線完成，功能集中在一個系統中，不像位元組各種平台間跳轉
- 和資源、硬體、中間件的部分都被隔離了，降低了上層建設的複雜度
劣勢：
- 正因為模版過多，導致使用起來也需要一定的成本
- 流水線部分雖然有程式碼掃描，但是沒有把結果更好地回饋到程式碼管理中，有點脫節
- 對流水線之外的任務管理、項目跟蹤、程式碼評審、線下環境等不涉及
- 對研發過程關注度不夠，沒有形成產研整個過程的閉環，產研數據不全難以全程有效度量
- 對QA工具和環境建設也待加強
研發效能+QA團隊
研發效能團隊和QA團隊在一起，這種組織架構我是看到過的。後來組織架構調整，研發效能團隊就和QA小夥伴在一起了。如果研發效能和QA團隊在一起形成合力，做的事情和影響力絕對高高的，這也是我見到的能最好地發揮1+1>2的組織結構。只可惜天時地利都佔了，效果卻並不理想，非常可惜。
優勢：
- 統一了公司內部QA域內的眾多工具的建設，把所有QA工具都集成到了一個平台上
- 對品質、測試用例、測試報告、測試數據、壓力測試等非常重視
劣勢：
- 對需求、任務管理、迭代跟進等重視不夠
- 做出的平台品質差，用戶吐槽不斷對平台失去了信心和耐心
根據我長期的觀察，覺得主要是用人+定位的問題；這裡主要談定位的問題，研發效能+QA這個組合，其實是在兩個專業領域發力，然後在一起的合力產生更大的效果，而不是在QA平台上長出一個研發效能平台。快手效率工程在這一點上則做的不錯，研發效能團隊支援所有的平台建設，通過介面和內部的QA自動化測試平台進行打通，各自業務都能按照自己的節奏走，同時還可以在「結合」的功能點上進行合作、共建、互相支撐。
研發效能+PMO團隊
研發效能團隊和PMO團隊在一起。這種組織架構我也經歷過。PMO在業務線給研發效能團隊推廣平台，帶來用戶訴求，研發效能支撐這些用戶訴求並在日常工作中給予支撐和支援。這種模式的關鍵點是研發效能團隊要直接扎到一線人員中。否則平台最後容易成為一個項目管理平台，最大程度滿足了PMO小夥伴的管理訴求，而不是一線產研團隊的小夥伴的訴求。一線團隊在那罵平台做得不切實際，不好用，體驗差，都是沒做過產研團隊的人臆想的需求；研發效能團隊也很叫屈，你說的需求我都做了啊。實際上平台做的需求都是「PMO的」需求，並沒有解決「一線實際用戶」的痛點。
優勢：
- PMO可以從項目管理的角度推廣、運營平台，幫平台收集用戶回饋
- PMO可以帶來高層的管理訴求和意見
- 研發效能團隊對PMO的支撐也有助於平台項目管理流程的平台化、產品化，項目進展的可視化
劣勢：
- PMO收集到的用戶需求可能是偽需求，需要認真甄別
- 一線用戶的訴求不能直接回饋到平台建設方
- 會不自覺地提高層理訴求的優先順序，影響平台需求的正常排期和發展
項目管理專家型的意見和建議，需要認真對待和評估，同時千萬不能忽視一線實際用戶的訴求。當然這裡也有合作正向的例子可以參考。
舉個：
第一個例子是五八同城的PMO團隊和平台建設團隊是在一個大團隊下。PMO遇到一線小夥伴的問題，通常會拉著平台建設團隊的小夥伴一起解決，所以做平台的小夥伴能直接接觸到這些訴求，然後進行獨立的評估和出解決方案，而不是加工過的「二手資訊」。滴滴EP在這一點上做的更進一步，通常是建立合作專項，PMO的小夥伴不傳二手資訊，直接幫團隊間拉通、跟進需求進度，更有助於問題的解決和方案落地。（後面我們會有單獨的文章詳細說）
不同組織架構效果不同
此表格為服務端研發效能涉及的部分工作。從上面的表格，我們就可以看到每個角色關注不同的研發效能域，即便是同一研發效能域，不同角色的關注度程度也不一樣。有的公司覺得研發效能和運維團隊都是公司的「成本中心」，都是支撐團隊，於是把研發效能和運維團隊放到一起，組成一個大的「infra」、「基礎平台」或者「平台架構」團隊，實際上應該從用戶的角度出發，把研發效能團隊推向他的客戶身邊。運維團隊並不是研發效能服務的第一用戶，我們的主要用戶是產品經理、項目經理、RD和QA小夥伴，只是運維團隊支撐研發效能團隊，離我們最近經常打交道，我們是運維資源的大客戶而已。
所以我更趨向於成立獨立的研發效能團隊、行使職能。如果非要和其它團隊在一起，那麼和研發團隊在一起，這是第二選擇；只不過因為RD小夥伴通常以業務線/產品線進行閉環到一個獨立的團隊，而研發效能團隊作為公共資源又很難劃分到某一業務線/產品線。第四選擇是和QA組成一個大團隊，這種組合有利於品質保證平台的建設，最後是研發效能和運維在一起。
而快手效率工程走了另外一條路，我們把以上所有支撐平台的產研（包含部分運維平台的建設）都劃分到一個團隊去支撐，相當於研發效能+QA平台支撐+基礎架構平台+運維平台(部分），避免了重複建設、同時資源利用最大化。最後取得的結果和效果也很不錯，我個人認為在1000人以下的規模可以採取這種組織架構。千人以上可以參考我下篇文章的內容，主要講了產研團隊在2000人左右，研發效能團隊的組織架構和團隊建設。
插播一則小感悟，近日新東方老師董宇輝中英雙語穿插歷史文化+才藝式帶貨，讓新東方帶貨平台「東方甄選」短短几日粉絲數量狂增數百萬。港股新東方在線也立刻給予了響應，兩個交易日累漲95.08%。這就是人才的力量。
相關文章：
