互聯(lián)網(wǎng)公司研發(fā)效能/工程效率團(tuán)隊(duì)建設(shè)和規(guī)劃

這是「互聯(lián)網(wǎng)公司研發(fā)效能團(tuán)隊(duì)建設(shè)」的第二篇。為啥研發(fā)效能要是一個(gè)相對獨(dú)立的團(tuán)隊(duì)呢？獨(dú)立的研發(fā)效能團(tuán)隊(duì)是最大化行使職能的必要保障。我一直認(rèn)為組織架構(gòu)是第二生產(chǎn)力(第一是人)。搭好臺(tái)子好唱戲。臺(tái)子左右不平，前高后低，再大的角都可能崴腳跌跟頭。

最近在想一個(gè)問題：研發(fā)效能算公司業(yè)務(wù)還是算基礎(chǔ)平臺(tái)、技術(shù)中臺(tái)、技術(shù)工具？怎樣才能做得更好？

我們可以定義研發(fā)效能團(tuán)隊(duì)的工作邊界是(需求管理+任務(wù)管理+項(xiàng)目管理)平臺(tái)+devops+APM+應(yīng)用運(yùn)維，負(fù)責(zé)從用戶需求提出到上線、到應(yīng)用運(yùn)維的整個(gè)過程，它的存在就是為了打破團(tuán)隊(duì)之間割裂、各自為戰(zhàn)的情況，同時(shí)可以把各個(gè)團(tuán)隊(duì)共性的需求集中統(tǒng)籌，使整個(gè)開發(fā)活動(dòng)能夠順暢、高效的運(yùn)行。研發(fā)效能團(tuán)隊(duì)一旦和某一個(gè)團(tuán)隊(duì)在一起，卻沒有更高的視野去思考這個(gè)事情，把控好業(yè)務(wù)方向，業(yè)務(wù)可能就會(huì)跑偏。研發(fā)效能靠近哪個(gè)團(tuán)隊(duì)，就會(huì)側(cè)重哪個(gè)團(tuán)隊(duì)的業(yè)務(wù)，對哪個(gè)團(tuán)隊(duì)服務(wù)的職能就做得好，對整個(gè)研發(fā)過程的關(guān)注度就會(huì)降低，從而研發(fā)效能團(tuán)隊(duì)的定位和作用會(huì)受到影響。

研發(fā)效能+運(yùn)維團(tuán)隊(duì)

研發(fā)效能團(tuán)隊(duì)和運(yùn)維團(tuán)隊(duì)在一起，這種組織架構(gòu)我是看到過的。一開始快手的運(yùn)維小伙伴也同時(shí)負(fù)責(zé)流水線部分的建設(shè)。這個(gè)是可以理解的，因?yàn)檫\(yùn)維小伙伴負(fù)責(zé)公司的基礎(chǔ)設(shè)施，公司的服務(wù)想要上線到運(yùn)維的基礎(chǔ)設(shè)施上必然要有一個(gè)上線系統(tǒng)。順手牽羊，運(yùn)維小伙伴就把流水線也給做了，他們也只做到了流水線。流水線之前的部分就沒參與，因?yàn)槟切┖瓦\(yùn)維關(guān)系不大，同時(shí)受限于人力物力，運(yùn)維小伙伴就沒涉及流水線前面的部分。和機(jī)器運(yùn)維部分相比，產(chǎn)研場景更靠前，涉及產(chǎn)品經(jīng)理、項(xiàng)目管理、RD和QA同學(xué)部分的流程化、標(biāo)準(zhǔn)化、自動(dòng)化要難得多。這種組合優(yōu)劣勢非常明顯：

優(yōu)勢：

部署和監(jiān)控日志告警、運(yùn)維系統(tǒng)銜接得很好
部署時(shí)的各種模板也很貼心，滿足了各種「業(yè)務(wù)」的需要
從源碼到上線都可以通過流水線完成，功能集中在一個(gè)系統(tǒng)中，不像字節(jié)各種平臺(tái)間跳轉(zhuǎn)
和資源、硬件、中間件的部分都被隔離了，降低了上層建設(shè)的復(fù)雜度

劣勢：

正因?yàn)槟０孢^多，導(dǎo)致使用起來也需要一定的成本
流水線部分雖然有代碼掃描，但是沒有把結(jié)果更好地反饋到代碼管理中，有點(diǎn)脫節(jié)
對流水線之外的任務(wù)管理、項(xiàng)目跟蹤、代碼評審、線下環(huán)境等不涉及
對研發(fā)過程關(guān)注度不夠，沒有形成產(chǎn)研整個(gè)過程的閉環(huán)，產(chǎn)研數(shù)據(jù)不全難以全程有效度量
對QA工具和環(huán)境建設(shè)也待加強(qiáng)

研發(fā)效能+QA團(tuán)隊(duì)

研發(fā)效能團(tuán)隊(duì)和QA團(tuán)隊(duì)在一起，這種組織架構(gòu)我是看到過的。后來組織架構(gòu)調(diào)整，研發(fā)效能團(tuán)隊(duì)就和QA小伙伴在一起了。如果研發(fā)效能和QA團(tuán)隊(duì)在一起形成合力，做的事情和影響力絕對高高的，這也是我見到的能最好地發(fā)揮1+1>2的組織結(jié)構(gòu)。只可惜天時(shí)地利都占了，效果卻并不理想，非常可惜。

優(yōu)勢：

統(tǒng)一了公司內(nèi)部QA域內(nèi)的眾多工具的建設(shè)，把所有QA工具都集成到了一個(gè)平臺(tái)上
對質(zhì)量、測試用例、測試報(bào)告、測試數(shù)據(jù)、壓力測試等非常重視

劣勢：

對需求、任務(wù)管理、迭代跟進(jìn)等重視不夠
做出的平臺(tái)質(zhì)量差，用戶吐槽不斷對平臺(tái)失去了信心和耐心

根據(jù)我長期的觀察，覺得主要是用人+定位的問題；這里主要談定位的問題，研發(fā)效能+QA這個(gè)組合，其實(shí)是在兩個(gè)專業(yè)領(lǐng)域發(fā)力，然后在一起的合力產(chǎn)生更大的效果，而不是在QA平臺(tái)上長出一個(gè)研發(fā)效能平臺(tái)。快手效率工程在這一點(diǎn)上則做的不錯(cuò)，研發(fā)效能團(tuán)隊(duì)支持所有的平臺(tái)建設(shè)，通過接口和內(nèi)部的QA自動(dòng)化測試平臺(tái)進(jìn)行打通，各自業(yè)務(wù)都能按照自己的節(jié)奏走，同時(shí)還可以在「結(jié)合」的功能點(diǎn)上進(jìn)行合作、共建、互相支撐。

研發(fā)效能+PMO團(tuán)隊(duì)

研發(fā)效能團(tuán)隊(duì)和PMO團(tuán)隊(duì)在一起。這種組織架構(gòu)我也經(jīng)歷過。PMO在業(yè)務(wù)線給研發(fā)效能團(tuán)隊(duì)推廣平臺(tái)，帶來用戶訴求，研發(fā)效能支撐這些用戶訴求并在日常工作中給予支撐和支持。這種模式的關(guān)鍵點(diǎn)是研發(fā)效能團(tuán)隊(duì)要直接扎到一線人員中。否則平臺(tái)最后容易成為一個(gè)項(xiàng)目管理平臺(tái)，最大程度滿足了PMO小伙伴的管理訴求，而不是一線產(chǎn)研團(tuán)隊(duì)的小伙伴的訴求。一線團(tuán)隊(duì)在那罵平臺(tái)做得不切實(shí)際，不好用，體驗(yàn)差，都是沒做過產(chǎn)研團(tuán)隊(duì)的人臆想的需求；研發(fā)效能團(tuán)隊(duì)也很叫屈，你說的需求我都做了啊。實(shí)際上平臺(tái)做的需求都是「PMO的」需求，并沒有解決「一線實(shí)際用戶」的痛點(diǎn)。

優(yōu)勢：

PMO可以從項(xiàng)目管理的角度推廣、運(yùn)營平臺(tái)，幫平臺(tái)收集用戶反饋
PMO可以帶來高層的管理訴求和意見
研發(fā)效能團(tuán)隊(duì)對PMO的支撐也有助于平臺(tái)項(xiàng)目管理流程的平臺(tái)化、產(chǎn)品化，項(xiàng)目進(jìn)展的可視化

劣勢：

PMO收集到的用戶需求可能是偽需求，需要認(rèn)真甄別
一線用戶的訴求不能直接反饋到平臺(tái)建設(shè)方
會(huì)不自覺地提高管理訴求的優(yōu)先級，影響平臺(tái)需求的正常排期和發(fā)展

項(xiàng)目管理專家型的意見和建議，需要認(rèn)真對待和評估，同時(shí)千萬不能忽視一線實(shí)際用戶的訴求。當(dāng)然這里也有合作正向的例子可以參考。

舉個(gè)：

第一個(gè)例子是五八同城的PMO團(tuán)隊(duì)和平臺(tái)建設(shè)團(tuán)隊(duì)是在一個(gè)大團(tuán)隊(duì)下。PMO遇到一線小伙伴的問題，通常會(huì)拉著平臺(tái)建設(shè)團(tuán)隊(duì)的小伙伴一起解決，所以做平臺(tái)的小伙伴能直接接觸到這些訴求，然后進(jìn)行獨(dú)立的評估和出解決方案，而不是加工過的「二手信息」。滴滴EP在這一點(diǎn)上做的更進(jìn)一步，通常是建立合作專項(xiàng)，PMO的小伙伴不傳二手信息，直接幫團(tuán)隊(duì)間拉通、跟進(jìn)需求進(jìn)度，更有助于問題的解決和方案落地。（后面我們會(huì)有單獨(dú)的文章詳細(xì)說）

不同組織架構(gòu)效果不同

互聯(lián)網(wǎng)公司研發(fā)效能/工程效率團(tuán)隊(duì)建設(shè)和規(guī)劃

此表格為服務(wù)端研發(fā)效能涉及的部分工作。從上面的表格，我們就可以看到每個(gè)角色關(guān)注不同的研發(fā)效能域，即便是同一研發(fā)效能域，不同角色的關(guān)注度程度也不一樣。有的公司覺得研發(fā)效能和運(yùn)維團(tuán)隊(duì)都是公司的「成本中心」，都是支撐團(tuán)隊(duì)，于是把研發(fā)效能和運(yùn)維團(tuán)隊(duì)放到一起，組成一個(gè)大的「infra」、「基礎(chǔ)平臺(tái)」或者「平臺(tái)架構(gòu)」團(tuán)隊(duì)，實(shí)際上應(yīng)該從用戶的角度出發(fā)，把研發(fā)效能團(tuán)隊(duì)推向他的客戶身邊。運(yùn)維團(tuán)隊(duì)并不是研發(fā)效能服務(wù)的第一用戶，我們的主要用戶是產(chǎn)品經(jīng)理、項(xiàng)目經(jīng)理、RD和QA小伙伴，只是運(yùn)維團(tuán)隊(duì)支撐研發(fā)效能團(tuán)隊(duì)，離我們最近經(jīng)常打交道，我們是運(yùn)維資源的大客戶而已。

所以我更趨向于成立獨(dú)立的研發(fā)效能團(tuán)隊(duì)、行使職能。如果非要和其它團(tuán)隊(duì)在一起，那么和研發(fā)團(tuán)隊(duì)在一起，這是第二選擇；只不過因?yàn)镽D小伙伴通常以業(yè)務(wù)線/產(chǎn)品線進(jìn)行閉環(huán)到一個(gè)獨(dú)立的團(tuán)隊(duì)，而研發(fā)效能團(tuán)隊(duì)作為公共資源又很難劃分到某一業(yè)務(wù)線/產(chǎn)品線。第四選擇是和QA組成一個(gè)大團(tuán)隊(duì)，這種組合有利于質(zhì)量保證平臺(tái)的建設(shè)，最后是研發(fā)效能和運(yùn)維在一起。

而快手效率工程走了另外一條路，我們把以上所有支撐平臺(tái)的產(chǎn)研（包含部分運(yùn)維平臺(tái)的建設(shè)）都劃分到一個(gè)團(tuán)隊(duì)去支撐，相當(dāng)于研發(fā)效能+QA平臺(tái)支撐+基礎(chǔ)架構(gòu)平臺(tái)+運(yùn)維平臺(tái)(部分），避免了重復(fù)建設(shè)、同時(shí)資源利用最大化。最后取得的結(jié)果和效果也很不錯(cuò)，我個(gè)人認(rèn)為在1000人以下的規(guī)模可以采取這種組織架構(gòu)。千人以上可以參考我下篇文章的內(nèi)容，主要講了產(chǎn)研團(tuán)隊(duì)在2000人左右，研發(fā)效能團(tuán)隊(duì)的組織架構(gòu)和團(tuán)隊(duì)建設(shè)。