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

目前累計(jì)服務(wù)客戶(hù)成百上千家，積累了豐富的產(chǎn)品開(kāi)發(fā)及服務(wù)經(jīng)驗(yàn)。以網(wǎng)站設(shè)計(jì)水平和技術(shù)實(shí)力，樹(shù)立企業(yè)形象，為客戶(hù)提供網(wǎng)站設(shè)計(jì)制作、成都網(wǎng)站設(shè)計(jì)、網(wǎng)站策劃、網(wǎng)頁(yè)設(shè)計(jì)、網(wǎng)絡(luò)營(yíng)銷(xiāo)、VI設(shè)計(jì)、網(wǎng)站改版、漏洞修補(bǔ)等服務(wù)。創(chuàng)新互聯(lián)始終以務(wù)實(shí)、誠(chéng)信為根本，不斷創(chuàng)新和提高建站品質(zhì)，通過(guò)對(duì)領(lǐng)先技術(shù)的掌握、對(duì)創(chuàng)意設(shè)計(jì)的研究、對(duì)客戶(hù)形象的視覺(jué)傳遞、對(duì)應(yīng)用系統(tǒng)的結(jié)合，為客戶(hù)提供更好的一站式互聯(lián)網(wǎng)解決方案，攜手廣大客戶(hù)，共同發(fā)展進(jìn)步。

最近在想一個(gè)問(wèn)題：研發(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é)從用戶(hù)需求提出到上線、到應(yīng)用運(yùn)維的整個(gè)過(guò)程，它的存在就是為了打破團(tuán)隊(duì)之間割裂、各自為戰(zhàn)的情況，同時(shí)可以把各個(gè)團(tuán)隊(duì)共性的需求集中統(tǒng)籌，使整個(gè)開(kāi)發(fā)活動(dòng)能夠順暢、高效的運(yùn)行。研發(fā)效能團(tuán)隊(duì)一旦和某一個(gè)團(tuán)隊(duì)在一起，卻沒(méi)有更高的視野去思考這個(gè)事情，把控好業(yè)務(wù)方向，業(yè)務(wù)可能就會(huì)跑偏。研發(fā)效能靠近哪個(gè)團(tuán)隊(duì)，就會(huì)側(cè)重哪個(gè)團(tuán)隊(duì)的業(yè)務(wù)，對(duì)哪個(gè)團(tuán)隊(duì)服務(wù)的職能就做得好，對(duì)整個(gè)研發(fā)過(guò)程的關(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)我是看到過(guò)的。一開(kāi)始快手的運(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)維小伙伴就把流水線也給做了，他們也只做到了流水線。流水線之前的部分就沒(méi)參與，因?yàn)槟切┖瓦\(yùn)維關(guān)系不大，同時(shí)受限于人力物力，運(yùn)維小伙伴就沒(méi)涉及流水線前面的部分。和機(jī)器運(yùn)維部分相比，產(chǎn)研場(chǎng)景更靠前，涉及產(chǎn)品經(jīng)理、項(xiàng)目管理、RD和QA同學(xué)部分的流程化、標(biāo)準(zhǔn)化、自動(dòng)化要難得多。這種組合優(yōu)劣勢(shì)非常明顯：

優(yōu)勢(shì)：

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

劣勢(shì)：

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

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

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

優(yōu)勢(shì)：

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

劣勢(shì)：

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

根據(jù)我長(zhǎng)期的觀察，覺(jué)得主要是用人+定位的問(wèn)題；這里主要談定位的問(wèn)題，研發(fā)效能+QA這個(gè)組合，其實(shí)是在兩個(gè)專(zhuān)業(yè)領(lǐng)域發(fā)力，然后在一起的合力產(chǎn)生更大的效果，而不是在QA平臺(tái)上長(zhǎng)出一個(gè)研發(fā)效能平臺(tái)。快手效率工程在這一點(diǎn)上則做的不錯(cuò)，研發(fā)效能團(tuán)隊(duì)支持所有的平臺(tái)建設(shè)，通過(guò)接口和內(nèi)部的QA自動(dòng)化測(cè)試平臺(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)歷過(guò)。PMO在業(yè)務(wù)線給研發(fā)效能團(tuán)隊(duì)推廣平臺(tái)，帶來(lái)用戶(hù)訴求，研發(fā)效能支撐這些用戶(hù)訴求并在日常工作中給予支撐和支持。這種模式的關(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)差，都是沒(méi)做過(guò)產(chǎn)研團(tuán)隊(duì)的人臆想的需求；研發(fā)效能團(tuán)隊(duì)也很叫屈，你說(shuō)的需求我都做了啊。實(shí)際上平臺(tái)做的需求都是「PMO的」需求，并沒(méi)有解決「一線實(shí)際用戶(hù)」的痛點(diǎn)。

優(yōu)勢(shì)：

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

劣勢(shì)：

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

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

舉個(gè)：

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

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

當(dāng)前題目：互聯(lián)網(wǎng)公司研發(fā)效能/工程效率團(tuán)隊(duì)建設(shè)和規(guī)劃
分享地址：http://fisionsoft.com.cn/article/dschgdc.html