互聯網公司研發效能/工程效率團隊建設和規劃

這是「互聯網公司研發效能團隊建設」的第二篇。為啥研發效能要是一個相對獨立的團隊呢？獨立的研發效能團隊是最大化行使職能的必要保障。我一直認為組織架構是第二生產力(第一是人)。搭好臺子好唱戲。臺子左右不平，前高后低，再大的角都可能崴腳跌跟頭。

目前累計服務客戶成百上千家，積累了豐富的產品開發及服務經驗。以網站設計水平和技術實力，樹立企業形象，為客戶提供網站設計制作、成都網站設計、網站策劃、網頁設計、網絡營銷、VI設計、網站改版、漏洞修補等服務。創新互聯始終以務實、誠信為根本，不斷創新和提高建站品質，通過對領先技術的掌握、對創意設計的研究、對客戶形象的視覺傳遞、對應用系統的結合，為客戶提供更好的一站式互聯網解決方案，攜手廣大客戶，共同發展進步。

最近在想一個問題：研發效能算公司業務還是算基礎平臺、技術中臺、技術工具？怎樣才能做得更好？

我們可以定義研發效能團隊的工作邊界是(需求管理+任務管理+項目管理)平臺+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的小伙伴不傳二手信息，直接幫團隊間拉通、跟進需求進度，更有助于問題的解決和方案落地。（后面我們會有單獨的文章詳細說）