這是「互聯網公司研發效能團隊建設」的第二篇，為啥研發效能要是一個相對獨立的團隊呢？獨立的研發效能團隊是最大化行使職能的必要保障，我一直認為組織架構是第二生產力(第一是人)，搭好臺子好唱戲，臺子左右不平，前高后低，再大的角都可能崴腳跌跟頭，
最近在想一個問題：研發效能算公司業務還是算基礎平臺、技術中臺、技術工具？怎樣才能做得更好？
我們可以定義研發效能團隊的作業邊界是(需求管理+任務管理+專案管理)平臺+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%，這就是人才的力量，
相關文章：
互聯網公司研發效能團隊為啥必須獨立？何時獨立？
一二三線互聯網公司劃分標準和榜單
中小互聯網公司研發效能團隊規模、職能劃分和優劣勢分析
研發效能團隊規模、職能劃分和優劣勢分析概述
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/498943.html
標籤：其他