GIAC（GLOBAL INTERNET ARCHITECTURE CONFERENCE）是長期關(guān)注互聯(lián)網(wǎng)技術(shù)與架構(gòu)的高可用架構(gòu)技術(shù)社區(qū)和msup推出的，面向架構(gòu)師、技術(shù)負(fù)責(zé)人及高端技術(shù)從業(yè)人員的年度技術(shù)架構(gòu)大會(huì)，是中國地區(qū)規(guī)模最大的技術(shù)會(huì)議之一。

第六屆GIAC，將從互聯(lián)網(wǎng)架構(gòu)最熱門的前沿技術(shù)、技術(shù)管理、系統(tǒng)架構(gòu)、大數(shù)據(jù)和人工智能、移動(dòng)開發(fā)和語言、架構(gòu)相關(guān)等領(lǐng)域，分享有典型代表的技術(shù)創(chuàng)新及研發(fā)實(shí)踐的架構(gòu)案例。

在團(tuán)隊(duì)協(xié)作專題，騰訊研發(fā)效能資深專家茹炳晟發(fā)表了題為《研發(fā)效能提升最佳實(shí)踐的探索》的主題演講。

茹炳晟，TEG-基礎(chǔ)架構(gòu)部-研發(fā)效能中心專家工程師，業(yè)界知名實(shí)戰(zhàn)派軟件質(zhì)量和研發(fā)工程效能專家，騰訊云最具價(jià)值專家TVP，中國商業(yè)聯(lián)合會(huì)互聯(lián)網(wǎng)應(yīng)用技術(shù)委員會(huì)智庫專家，暢銷書《測(cè)試工程師全棧技術(shù)進(jìn)階與實(shí)踐》和《高效自動(dòng)化測(cè)試平臺(tái)：設(shè)計(jì)與開發(fā)實(shí)戰(zhàn)》作者，InfoQ極客時(shí)間《軟件測(cè)試52講-從小工到專家的實(shí)戰(zhàn)心法》作者，曾參與DevOps能力成熟度模型國家標(biāo)準(zhǔn)的編寫，也參與設(shè)計(jì)了DevOps企業(yè)教練的國際認(rèn)證課程。

以下為演講實(shí)錄：

很榮幸受GIAC全球互聯(lián)網(wǎng)架構(gòu)大會(huì)的邀請(qǐng)擔(dān)任了本屆大會(huì)“測(cè)試前沿技術(shù)“的出品人，同時(shí)也受邀發(fā)表了研發(fā)效能提升的主題演講。這里我把本次演講的精華部分做了一個(gè)簡單的梳理，希望能夠給關(guān)注研發(fā)效能提升的同學(xué)帶了啟發(fā)和幫助。以下是主要內(nèi)容回顧，歡迎大家拍磚。

現(xiàn)代的軟件行業(yè)已經(jīng)不再是以前“大魚吃小魚“的時(shí)代了，而是轉(zhuǎn)變成了”快魚吃慢魚“的時(shí)代。對(duì)于很多大型傳統(tǒng)軟件企業(yè)，原本“大“是其優(yōu)勢(shì)，現(xiàn)在卻陷入了”大船難掉頭“的尷尬。對(duì)于大量小而美的互聯(lián)網(wǎng)軟件項(xiàng)目，當(dāng)創(chuàng)意和細(xì)分領(lǐng)域被確認(rèn)之后，各大友商比拼的就是研發(fā)能力，具體來講就是從需求轉(zhuǎn)化成軟件或者服務(wù)的能力，這其中研發(fā)效能的高低對(duì)于需求轉(zhuǎn)化速率起到了至關(guān)重要的作用。同時(shí)，如何有效降低研發(fā)和運(yùn)維的成本也是研發(fā)效能需要關(guān)注的重要課題，尤其是大型互聯(lián)網(wǎng)項(xiàng)目，當(dāng)某個(gè)環(huán)節(jié)哪怕只有少量優(yōu)化的時(shí)候，由于其規(guī)模效應(yīng)（比如集群規(guī)模，用戶流量等）的放大作用，最終節(jié)省的成本也會(huì)是相當(dāng)可觀的。

和敏捷的概念類似，到底什么是研發(fā)效能其實(shí)很難精確定義。其實(shí)很多復(fù)雜概念不是定義出來的，而是逐步演化出來的，是先有現(xiàn)象再找到合適的表述。要理解這類復(fù)雜的概念，最好的方法是理清發(fā)展脈絡(luò)，回到歷史中，回到誕生的時(shí)間，漫步一遍它的發(fā)展歷程，才能真正理解其本質(zhì)。但是由于時(shí)間關(guān)系，本次演講我們沒有足夠的時(shí)間帶著大家重走一遍歷史，所以我準(zhǔn)備先通過幾個(gè)案例讓大家能夠先直觀的感受一下“研發(fā)效能提升之美“。

先來看第一個(gè)例子，很多時(shí)候我們?cè)谧霎a(chǎn)品原型設(shè)計(jì)的時(shí)候都需要借助產(chǎn)品原型工具來實(shí)現(xiàn)產(chǎn)品GUI界面的設(shè)計(jì)，以此作為溝通的基礎(chǔ)去開展后續(xù)的工作。但是你會(huì)發(fā)現(xiàn)即使已經(jīng)有了類似Axure和Modao等原型工具，但是“畫界面“的成本依然很高。這里介紹一種可以將圖片GUI設(shè)計(jì)稿，甚至是手畫GUI設(shè)計(jì)稿轉(zhuǎn)化成目標(biāo)平臺(tái)代碼的一鍵自動(dòng)化生成方案。

在上面的例子中，先手繪GUI界面設(shè)計(jì)，然后通過Sketch2Code可以直接轉(zhuǎn)換成目標(biāo)平臺(tái)的代碼，如果你指定的目標(biāo)平臺(tái)是Web，那就直接生成html，如果你指定的目標(biāo)平臺(tái)是iOS，那就會(huì)生成XCode的項(xiàng)目，通過編譯打包后就可以直接在iPhone上安裝執(zhí)行了。這種方式的引入將大幅提升原型構(gòu)建環(huán)節(jié)的效率。

再來看第二例子。API接口測(cè)試過程中，輸入?yún)?shù)臨界值沒有妥善處理的問題很常見，比如某個(gè)輸入?yún)?shù)是String類型，但是代碼實(shí)現(xiàn)中沒有考慮String變量取值為NULL等情況。這類問題通常都會(huì)在后期API集成測(cè)試或者聯(lián)調(diào)階段才會(huì)集中被發(fā)現(xiàn)，此時(shí)發(fā)現(xiàn)再去修復(fù)的成本通常都會(huì)比較高，而且修復(fù)之后還要考慮回歸測(cè)試的成本。所以我們可以引入一種機(jī)制，去主動(dòng)掃描獲取API輸入?yún)?shù)的類型，然后根據(jù)參數(shù)類型生成容易出錯(cuò)的取值，用這些取值自動(dòng)調(diào)用API，如果發(fā)生500錯(cuò)誤或者拋異常就是發(fā)現(xiàn)了問題。（比如，對(duì)于String類型的輸入?yún)?shù)就可以生成NULL，超長的字符串，包含非英語字符的字符串，SQL注入字符串等等。）進(jìn)一步我們可以把這個(gè)方案和CI流水線集成，在CI執(zhí)行過程中主動(dòng)執(zhí)行此類測(cè)試，以求問題更早地被暴露。

上面兩個(gè)例子都是由技術(shù)主導(dǎo)的。接下來的例子就和技術(shù)沒有太大關(guān)系了，而是由流程主導(dǎo)的。上面圖中廚師做三明治，左邊圖中由于各個(gè)食材擺放沒有特定的順序，造成廚師必須不斷來回走動(dòng)才能完成任務(wù)，而右邊圖中食材按使用順序擺放，廚師可以站在原地輕松完成三明治的制作，大大節(jié)省了不必要的走動(dòng)時(shí)間，從而大幅度提升了效率。由此可見，效率的提升既可以由技術(shù)來驅(qū)動(dòng)，也可以由流程來驅(qū)動(dòng)。

看完了上面的例子，我想你已經(jīng)對(duì)研發(fā)效能提升有了一個(gè)非常感性的認(rèn)識(shí)了。接下來，我們來看一下研發(fā)效能的本質(zhì)。如果要用一句話來總結(jié)研發(fā)效能的話，我會(huì)用“順暢、高質(zhì)量地持續(xù)交付有效價(jià)值的閉環(huán)“。解釋一下其中幾個(gè)關(guān)鍵概念：

• 順暢：價(jià)值的流動(dòng)過程必須順暢，沒有阻礙

• 高質(zhì)量：如果質(zhì)量不行，流動(dòng)越快，死的也會(huì)越快

• 持續(xù)：不能時(shí)斷時(shí)續(xù)，小步快跑才是正道，不要憋大招

• 有效價(jià)值：這是從需求層面來說的，你的交付物是不是真正解決了用戶的本質(zhì)問題。（關(guān)于本質(zhì)問題我想多說一句，女生減肥不是本質(zhì)問題，女生愛美才是，可以自己體會(huì)一下。）

• 閉環(huán)：強(qiáng)調(diào)快速反饋的重要性

?在這個(gè)概念的引導(dǎo)下，我覺得五個(gè)持續(xù)（持續(xù)開發(fā)，持續(xù)集成，持續(xù)測(cè)試，持續(xù)交付和持續(xù)運(yùn)維）是這個(gè)概念能夠落地的必要實(shí)踐。與此同時(shí)，我們還需要從流動(dòng)速度，長期質(zhì)量，客戶價(jià)值以及數(shù)據(jù)驅(qū)動(dòng)四個(gè)維度來對(duì)研發(fā)效能進(jìn)行有效的度量。

上面是從概念層面描述了研發(fā)效能，是不是感覺有點(diǎn)教條，其實(shí)我也覺得。所以下面我準(zhǔn)備用通俗的例子來說說我對(duì)研發(fā)效能的理解。

左手邊的圖是所謂的“方輪子“效應(yīng)。在前面使勁拉車的是老板，在后面使勁推車的是員工，老板關(guān)注的是大趨勢(shì)和方向，是向前看的，很難發(fā)現(xiàn)車的輪子是方的，拉車的員工可能看到了方輪子，但是鑒于老板在前使勁拉，所以絲毫不敢停下腳步，只能硬著頭皮使勁推。而在邊上提議換個(gè)圓形輪子的同學(xué)被無情地忽略了，換個(gè)圓輪子的確要額外的停頓，殊不知那是為了讓后面可以跑得更快更久。（題外話：突然腦中閃過一個(gè)酒店的slogan，知停而行）。你可能已經(jīng)聯(lián)想到了，這里的圓輪子其實(shí)就是工程效能。

?右手邊的圖根據(jù)事情的重要程度和緊迫程度分成了四個(gè)象限。我們這里只討論A象限和B象限。A象限是重要但不緊迫，通常是一些基礎(chǔ)性長期重要的事情，比如搶占市場(chǎng)的新產(chǎn)品規(guī)劃，基礎(chǔ)設(shè)施建設(shè)，流程優(yōu)化，人才培養(yǎng)等，我喜歡把這個(gè)象限稱為“未雨綢繆象限“。B象限是既重要又緊迫，通常是一些必須立馬處理的事情，比如系統(tǒng)故障，線上缺陷修復(fù)等，我常把這個(gè)象限稱為“救火象限“。?

理想情況下更多的時(shí)間占比應(yīng)該放在“未雨綢繆象限“，少量的時(shí)間用于“救火象限“。

“未雨綢繆象限“做好了，“救火象限“事件的概率會(huì)變小。如果一個(gè)公司大部分時(shí)間在救火，通常說明這兩個(gè)象限的時(shí)間分配失衡或者倒掛了，需要關(guān)注投資那些長期重要但不緊迫的事情。

對(duì)于軟件研發(fā)而言，“未雨綢繆象限“中最重要的一環(huán)就是研發(fā)效能。

最后用一個(gè)更形象的例子做個(gè)比喻，相信大家都聽過鵝生金蛋的故事。是不是鵝生的金蛋越多，效能就越高呢？其實(shí)不是，一味地讓鵝全日午休地生金蛋早晚會(huì)把鵝累死，這不是可持續(xù)的長遠(yuǎn)戰(zhàn)略。真正的效能應(yīng)該是讓鵝生鵝，鵝再生鵝，讓更多的鵝一起來下金蛋。

騰訊TEG內(nèi)部快速發(fā)展中的智研平臺(tái)，阿里已經(jīng)走向產(chǎn)品化的云效平臺(tái)，百度基于工程效能白皮書來落地的效率云等等都是研發(fā)效能領(lǐng)域的標(biāo)桿，可是你有沒有想過，為什么最近幾年各大行業(yè)龍頭企業(yè)都紛紛開始在研發(fā)效能領(lǐng)域發(fā)力，而且步調(diào)如此一致，我認(rèn)為背后的原因有以下這么三點(diǎn)：

就像“中臺(tái)“概念一樣，現(xiàn)在很多大企業(yè)的產(chǎn)品線非常廣，其中存在大量重復(fù)的輪子，如果我們關(guān)注業(yè)務(wù)上的重復(fù)輪子，那么就是業(yè)務(wù)中臺(tái)；如果我們關(guān)注數(shù)據(jù)建設(shè)上的重復(fù)輪子，那么就是數(shù)據(jù)中臺(tái)；如果我們關(guān)注研發(fā)效能建設(shè)上的重復(fù)輪子，那就是研效平臺(tái)，其實(shí)研效平臺(tái)在某種程度上也可以稱之為”研發(fā)效能中臺(tái)“，其目標(biāo)是實(shí)現(xiàn)企業(yè)級(jí)夸產(chǎn)品夸項(xiàng)目的研發(fā)能力復(fù)用，避免原來每條產(chǎn)品線都在做研發(fā)效能所必須的”0到1“，沒人有精力去關(guān)注更有價(jià)值的”1到n“。現(xiàn)在的研效平臺(tái)會(huì)統(tǒng)一來打造組織級(jí)別通用研發(fā)能力的最佳實(shí)踐平臺(tái)。

從商業(yè)視角來看，現(xiàn)在toC產(chǎn)品已經(jīng)趨向飽和，過去大量閑置時(shí)間等待被APP填滿的紅利時(shí)代已經(jīng)一去不復(fù)返了，以前業(yè)務(wù)發(fā)展極快，那么用燒錢的方式（粗放式研發(fā)，人海戰(zhàn)術(shù)）換取更快的市場(chǎng)占有率達(dá)到贏家通吃是最佳選擇，那個(gè)時(shí)代關(guān)心的是軟件產(chǎn)品輸出，研發(fā)的效率都可以用錢填上。而現(xiàn)在toC已經(jīng)逐漸走向紅海，同時(shí)研發(fā)的規(guī)模也比以往任何時(shí)候都要大，是時(shí)候要勒緊褲腰帶過日子了，當(dāng)開源（開源節(jié)流中的開源）遇到瓶頸了，節(jié)流就應(yīng)該發(fā)揮作用。這個(gè)節(jié)流就是研發(fā)效能的提升，同樣的資源，同樣的時(shí)間來獲得更多的產(chǎn)出。

從組織架構(gòu)層面看，很有企業(yè)都存在“谷倉困局“，就像上面第二張圖展示的，研發(fā)各個(gè)環(huán)節(jié)內(nèi)部可能已經(jīng)做了優(yōu)化，但是光環(huán)節(jié)的協(xié)作可能就會(huì)有大量的流轉(zhuǎn)與溝通成本，從而影響全局效率。基于流程優(yōu)化，打破各個(gè)環(huán)節(jié)看不見的墻，去除不必要的等待，提升價(jià)值流動(dòng)速度正是研發(fā)效能試圖解決的一大類問題。

這頁Slides是從軟件開發(fā)、測(cè)試和發(fā)布的視角羅列了各個(gè)階段研發(fā)效能提升需要關(guān)注的問題。其主線是圍繞CI/CD的一些列實(shí)踐。由于篇幅原因，我這里就不一一展開了，只舉幾個(gè)例子讓大家有個(gè)感性的認(rèn)識(shí)。

可以通過All-in-one的開發(fā)環(huán)境降低每位開發(fā)人員開發(fā)環(huán)境準(zhǔn)備的時(shí)間成本，同時(shí)又能保證開發(fā)環(huán)境的一致性。更高級(jí)的玩法是使用云端IDE，實(shí)現(xiàn)只要有瀏覽器就能改代碼。

可以借助基于AI的代碼提示插件，大幅度提升IDE中代碼的開發(fā)效率。同樣輸入一段代碼，不借助AI代碼提示插件，需要敲擊鍵盤200次，啟用插件可能只需要50次鍵盤敲擊。

代碼的靜態(tài)檢查沒有必要等到代碼遞交后由CI中的Sonar流程來發(fā)起，那個(gè)時(shí)候發(fā)現(xiàn)問題再修復(fù)為時(shí)已晚，完全可以通過Sonar Lint插件結(jié)合IDE實(shí)時(shí)發(fā)起本地的代碼檢查，有問題直接在IDE中提示，直接修復(fù)。

單元測(cè)試比較耗費(fèi)時(shí)間，可以借助EvoSuite之類的工具降低單元測(cè)試的開發(fā)工作量。

對(duì)于規(guī)模較大的項(xiàng)目，每次修改后編譯時(shí)間比較長。可以采用增量編譯，甚至是分布式編譯（Distcc和CCache）提升效率。

前端開發(fā)可以借助JRebel和Nodemon之類的工具使前端開發(fā)預(yù)覽的體驗(yàn)更流暢。

選擇適合項(xiàng)目的代碼分支策略對(duì)提升效率也大有幫助。

構(gòu)建高度自動(dòng)化的CI和CD流水線將大幅提升價(jià)值的流轉(zhuǎn)速率。

選擇合適的發(fā)布策略也會(huì)對(duì)效能和風(fēng)險(xiǎn)之間的平衡起到積極的作用。比如架構(gòu)相對(duì)簡單，但是集群規(guī)模龐大，優(yōu)選金絲雀，如果架構(gòu)比較復(fù)雜，但是集群規(guī)模不是太大，可能藍(lán)綠發(fā)布更占優(yōu)勢(shì)。

…

從上面的描述我們可以看到，研發(fā)效能的提升涉及的面很廣，既有基于技術(shù)的，也有基于流程的，那么在實(shí)際工程實(shí)踐中，我們又該如何來落地研發(fā)效能提升呢？我主張的觀點(diǎn)是“用MVP（Minimum Viable Product）的思想來提升研發(fā)效能“。

MVP這個(gè)概念來自于Eric Rise的《精益創(chuàng)業(yè)》一書，核心思想是是指以最低成本盡可能展現(xiàn)核心概念的產(chǎn)品策略，即是指用最快、最簡明的方式建立一個(gè)可用的產(chǎn)品原型，這個(gè)原型要表達(dá)出你產(chǎn)品最終想要的效果，然后通過迭代來完善細(xì)節(jié)。

這個(gè)思想特別適用于研效平臺(tái)的建設(shè)，我們必須在識(shí)別出待解決的研效問題之后，先給出最簡單的解決方案，然后在后面的實(shí)踐中不斷優(yōu)化和迭代，如果我們?cè)噲D關(guān)起門來打造一個(gè)研效平臺(tái)，指望等所有功能都完美了再推給業(yè)務(wù)線團(tuán)隊(duì)使用，那必然是死路一條。

還有必要特別指出一下MVP的常見誤區(qū)。實(shí)現(xiàn)了某一個(gè)功能但是暫時(shí)對(duì)客戶沒有實(shí)際價(jià)值，而要等后面功能出來后才能對(duì)客戶有用，這個(gè)不是MVP。MVP追求的是“麻雀雖小五臟俱全“，也就是實(shí)現(xiàn)的功能點(diǎn)可以很小，可以比較簡陋，但是對(duì)客戶有價(jià)值是必需的。用上圖的兩個(gè)三角形來說的話，”橫切“不是MVP，”豎切“才是MVP。

所以放到研發(fā)效能這個(gè)領(lǐng)域，我們要保證我們的做的研效工具一定是能解決實(shí)際痛點(diǎn)的，雖然一開始的方法可以比較簡陋。從產(chǎn)品的視角來看，研發(fā)平臺(tái)本身和一般的軟件產(chǎn)品沒有本質(zhì)區(qū)別，也需要不斷迭代和持續(xù)改進(jìn)。

這里開始是本次分享最硬核的部分，這也是我自己對(duì)如何推行研發(fā)效能提升的一個(gè)階段性總結(jié)。

常有人問我說，你之前主導(dǎo)的研效提升項(xiàng)目都獲得了成功，如果請(qǐng)你過來，幾年可以做好？這個(gè)其實(shí)是一個(gè)無解的問題。一定程度上，投入大，周期就會(huì)短，但是，實(shí)施周期不會(huì)因?yàn)橥度霟o限大而無限變短。我們可以避開很多曾經(jīng)踩過的坑，盡量少走彎路，但是，適合自己的路子還是要靠自己走出來，拔苗助長只會(huì)損害長期利益，買了一輛跑車，你就能成為賽車手嗎？鑒于此，我結(jié)合自己繳過的學(xué)費(fèi)、踩過的坑總結(jié)了上圖中的8個(gè)建議供大家參考。接下來我會(huì)挨個(gè)做解讀。

?第一點(diǎn)是“從痛點(diǎn)入手“。很多時(shí)候，當(dāng)我們手上拿著錘子的時(shí)候，看什么都像釘子。但是研發(fā)效能提升恰好是反過來了，我們要先找到哪些是最礙眼的釘子，然后用體系化的方法論去打造合適的錘子。

所以在推行研發(fā)效能的早期階段，我們通常會(huì)采用自下而上的策略，從一個(gè)個(gè)工程實(shí)踐中的實(shí)際痛點(diǎn)（釘子）入手，從解決問題的角度打造研效提升的亮點(diǎn)，此時(shí)我們追求的是”短平快“，問題點(diǎn)逐個(gè)擊破的原則。比如下面這些場(chǎng)景：

• 本地編譯耗時(shí)長：提供增量編譯和分布式編譯能力

• 本地測(cè)試?yán)щy，測(cè)試環(huán)境準(zhǔn)備復(fù)雜且耗時(shí)：基于K8S的Pod提供一鍵搭建測(cè)試環(huán)境的能力

• 自動(dòng)化測(cè)試用例數(shù)量大，執(zhí)行回歸時(shí)間過長：采用并發(fā)測(cè)試用例執(zhí)行機(jī)制，使用幾百幾千臺(tái)測(cè)試執(zhí)行機(jī)并行執(zhí)行用例，實(shí)現(xiàn)用硬件資源換時(shí)間

• 自動(dòng)化測(cè)試用例維護(hù)成本高：測(cè)試用例采用模塊化和分層體系，實(shí)現(xiàn)低成本的自動(dòng)化用例維護(hù)

• 測(cè)試數(shù)據(jù)準(zhǔn)備困難：引入統(tǒng)一測(cè)試數(shù)據(jù)服務(wù)（Test Data Service）能力

• 研發(fā)后期階段，代碼遞交集中，缺陷井噴：推行測(cè)試左移，鼓勵(lì)研發(fā)自測(cè)，推行”誰開發(fā)，誰測(cè)試，誰上線，誰Oncall“

• 性能缺陷在研發(fā)后期發(fā)現(xiàn)，修復(fù)重測(cè)成本高居不下：從性能測(cè)試轉(zhuǎn)變?yōu)樾阅芄こ?#xff0c;讓性能融入軟件研發(fā)的各個(gè)環(huán)節(jié)，而不是最后的一錘子買賣

• 安全問題頻現(xiàn)：將安全測(cè)試能力納入研發(fā)的全生命周期，實(shí)現(xiàn)DevSecOps，而不是早期的SDL

• 集群規(guī)模龐大，發(fā)布過程耗時(shí)過長：各個(gè)層級(jí)的并發(fā)部署能力，集群內(nèi)節(jié)點(diǎn)的并發(fā)，集群間的并發(fā)等

• 項(xiàng)目的過程數(shù)據(jù)都是后期集中填充，失去度量意義：項(xiàng)目過程數(shù)據(jù)由工具自動(dòng)填充，不再依賴工程師手工輸入。比如開發(fā)完成時(shí)間不再依賴于開發(fā)人員手工填寫，而是由Jenkins構(gòu)建完成后自動(dòng)填寫，以保證所有過程數(shù)據(jù)的真實(shí)有效性，從而為后面的度量和改進(jìn)提供可靠的信息輸入。

• …

第二條是“從全局切入“。很多時(shí)候我們會(huì)嘗試去優(yōu)化某個(gè)具體的環(huán)節(jié)，而忽略了全局優(yōu)化的可能。

?舉個(gè)例子，我們?nèi)メt(yī)院看病，通常是掛號(hào)排隊(duì)半小時(shí)，實(shí)際掛號(hào)可能就兩分鐘，接下來又是漫長的排隊(duì)等待等待醫(yī)生就診，好不容易排到了進(jìn)去可能不到五分鐘就被要求去驗(yàn)血…。整個(gè)過程中實(shí)際有效時(shí)間的占比很小。如果這個(gè)時(shí)候我們還試圖去優(yōu)化掛號(hào)本身的時(shí)間，而不去關(guān)注優(yōu)化各個(gè)環(huán)節(jié)的等待時(shí)間顯然是錯(cuò)誤的方向，所以效率提升既要關(guān)注單個(gè)步驟的優(yōu)化，也要專注減少步驟與步驟之間的無用等待。這一點(diǎn)體檢中心就比公立醫(yī)院做的好太多了，你很少會(huì)見到體檢中心每個(gè)科室門口都大排長龍的情景，因?yàn)轶w檢中心出于經(jīng)濟(jì)利益的考慮會(huì)關(guān)注吞吐量，會(huì)通過全局排隊(duì)調(diào)度優(yōu)化來實(shí)現(xiàn)更高的盈利。

回到軟件研發(fā)領(lǐng)域，你會(huì)發(fā)現(xiàn)類似上面醫(yī)院這種不合理的排隊(duì)現(xiàn)象隨處可見，比如軟件缺陷的流轉(zhuǎn)，軟件需求的實(shí)現(xiàn)與交付，軟件制品包發(fā)布等待等等。這些也是研發(fā)效能提升需要重點(diǎn)關(guān)注的領(lǐng)域，需要從全局理清楚全流程，識(shí)別出等待浪費(fèi)的時(shí)間，通過流程再造與優(yōu)化實(shí)現(xiàn)全局效率提升。

第三條是“用戶獲益“。對(duì)于研效提升，有一點(diǎn)我們必須牢記，那就是成功的標(biāo)準(zhǔn)不是研發(fā)效能平臺(tái)的成功，而是客戶成功。只有客戶獲益才是檢驗(yàn)研效項(xiàng)目成功的唯一標(biāo)準(zhǔn)。這里我談以下三點(diǎn)：

偽需求：偽需求是指研效團(tuán)隊(duì)自己臆想出來的，是屬于典型的“手里拿著錘子，看什么都像釘子”的典型案例。那么如何識(shí)別偽需求呢？識(shí)別標(biāo)準(zhǔn)其實(shí)很簡單，就看客戶是不是愿意和你分?jǐn)偝杀?#xff0c;如果業(yè)務(wù)線已經(jīng)開始做了，或者想要開始做，那就說明那是業(yè)務(wù)線的剛需，如果研效平臺(tái)能幫助提供方案，那研效平臺(tái)的接入就是水到渠成的事情。我就見到過很多這類剛需的例子，比如微服務(wù)架構(gòu)下集成測(cè)試環(huán)境的搭建就是其中的典型。?

結(jié)構(gòu)問題：著名商業(yè)顧問劉潤說過“結(jié)構(gòu)不對(duì)，什么都不對(duì)“。比如兩個(gè)和尚分粥的故事想必大家都聽過，一碗粥兩個(gè)和尚要均分，但是分粥的和尚總想多喝點(diǎn)粥，那怎么才能做到無監(jiān)管情況下的公平呢？教育分粥的和尚說出家人“以少吃為懷”嗎，顯然一旦沒有了監(jiān)管，他就會(huì)給自己多分點(diǎn)，解決這個(gè)問題的最好辦法就是一個(gè)和尚分粥，另一個(gè)和尚選粥，那么這個(gè)體制就決定了分粥的均勻性。所以好的策略是承認(rèn)每個(gè)人都是自私的，但是你的策略能夠在人人都是自私的基礎(chǔ)上獲得全局利益的最大化，如果你的全局利益最大化是建立在要求每個(gè)人都是大公無私的，那就是失敗的設(shè)計(jì)，因?yàn)檫@必然會(huì)導(dǎo)致失敗。回到研效提升這個(gè)問題上，我們必須抱著”不是我們的研效平臺(tái)有多好，而是業(yè)務(wù)線用了以后有什么提升“來定位自己，才能從結(jié)構(gòu)上獲得成功的籌碼。

服務(wù)意識(shí)：理解了上面的觀點(diǎn)，理解服務(wù)意識(shí)就很自然了。在研效平臺(tái)落地過程中我們需要和業(yè)務(wù)線互助實(shí)現(xiàn)雙贏，業(yè)務(wù)線收獲現(xiàn)成可用的方案，研效平臺(tái)收獲最佳實(shí)踐的沉淀，這些最佳實(shí)踐的沉淀是至關(guān)重要的，為后期的批量成功復(fù)制提供了技術(shù)基礎(chǔ)。

另外還有一個(gè)小經(jīng)驗(yàn)可以和大家分享，有時(shí)候?yàn)榱俗屟行脚_(tái)盡快能夠在業(yè)務(wù)線落地，讓業(yè)務(wù)線愿意成為我們的研效平臺(tái)的試驗(yàn)田，我們有時(shí)還必須能承擔(dān)起主動(dòng)背鍋的義務(wù)，這點(diǎn)如果大家感興趣也可以和我私下交流。

持續(xù)改進(jìn)是研效平臺(tái)自身發(fā)展的必經(jīng)之路。很多問題的解決在一開始的時(shí)候，我們關(guān)注的是如何快速簡單地解決問題，但是當(dāng)規(guī)模起來之后，我們還更需要關(guān)注解決方案的普適性和通用性。如果一開始就試圖尋找完美方案，必然會(huì)讓得不償失。

這里舉個(gè)具體的例子，比如我們需要在Jenkins中通過hook機(jī)制去觸發(fā)一些操作（比如代碼靜態(tài)掃描，單元測(cè)試等），最簡單的做法就是在hook中實(shí)現(xiàn)操作的具體步驟，這種實(shí)現(xiàn)在一開始效率很高，也非常容易實(shí)現(xiàn)，但卻不是最優(yōu)的方案，因?yàn)閔ook中的代碼只會(huì)被執(zhí)行一次，而且hook越來越多以后，各種實(shí)現(xiàn)都散落在各個(gè)地方，難以維護(hù)，同時(shí)但凡有新的需要（比如要加入慢SQL掃描），都需要改hook實(shí)現(xiàn)，而且這種做法也違背了IaC（Infrastructure as Code）原則。

更好的做法是引入研發(fā)效能的消息中心（MQ）通過下游操作的訂閱模式來實(shí)現(xiàn)未來的可擴(kuò)展性。但是如果你從一開始就是建MQ，實(shí)現(xiàn)的難度和成本都會(huì)大增，業(yè)務(wù)線有可能就等不及你的方案，從而研效提升就無法如期落地。所以我的觀點(diǎn)是研效落地可以遵循“先圈地，后改進(jìn)“的策略。

這頁Slides說的是研發(fā)效能提升的落地，光靠自下往上和光靠自上往下都是行不通的，而是應(yīng)該雙管齊下，兩邊從中間擠才是切實(shí)可行的方案，由于篇幅原因，這里就不詳細(xì)展開了。

這里我提出來兩個(gè)概念：“唱戲的“和”搭臺(tái)的“。剛開始做研發(fā)效能的時(shí)候，我們既是搭臺(tái)的又是唱戲的，在研效平臺(tái)（搭臺(tái)）的基礎(chǔ)上提供各業(yè)務(wù)線的解決方案（唱戲），但是當(dāng)業(yè)務(wù)線接入規(guī)模不斷擴(kuò)大的時(shí)候，各個(gè)垂直領(lǐng)域的多樣化需求越來越多，此時(shí)我們已經(jīng)很難應(yīng)對(duì)各家的個(gè)性化非通用需求了（每家要唱的戲都不同），所以此時(shí)研效平臺(tái)的開放能力就成為了關(guān)鍵，研效平臺(tái)的建設(shè)必須能夠應(yīng)對(duì)這種多樣性，研效平臺(tái)的職責(zé)轉(zhuǎn)變成搭建規(guī)范的平臺(tái)，讓業(yè)務(wù)線能夠在此平臺(tái)上實(shí)現(xiàn)各自的個(gè)性化需求，所以研效平臺(tái)本身的技術(shù)架構(gòu)設(shè)計(jì)必須考慮可擴(kuò)展性和靈活性。

?舉個(gè)例子，平臺(tái)就是Jenkins，靈活性就是上面各種plugin。

掩耳盜鈴是我們?cè)诼涞匮行н^程中經(jīng)常會(huì)犯的錯(cuò)誤。上圖給出了研發(fā)效能的“最差實(shí)踐“，你可以心里默默數(shù)數(shù)被砸中幾條。

另一種掩耳盜鈴的例子是普遍采用虛榮性指標(biāo)來做度量效能。那到底什么是虛榮性指標(biāo)呢？虛榮性指標(biāo)是指那些不能直接用來指導(dǎo)后續(xù)行動(dòng)的指標(biāo)，我們需要的是可以指導(dǎo)我們行動(dòng)的可執(zhí)行指標(biāo)。這么說還是比較抽象，我舉幾個(gè)例子你就很容易明白了。?

• “接入Sonar的工程數(shù)“就是虛榮性指標(biāo)，與之對(duì)應(yīng)的可執(zhí)行指標(biāo)是” Sonar問題的增長趨勢(shì)“和” Sonar問題的修復(fù)時(shí)長“；

• “系統(tǒng)用戶數(shù)“就是虛榮性指標(biāo)，與之對(duì)應(yīng)的可執(zhí)行指標(biāo)是” DAU單日活躍用戶數(shù)“和” MAU月活躍用戶數(shù)“；

• “接入研效平臺(tái)的項(xiàng)目數(shù)“就是虛榮性指標(biāo)，與之對(duì)應(yīng)的可執(zhí)行指標(biāo)是”百分之多少的項(xiàng)目使用過研效平臺(tái)來完成開發(fā)測(cè)試和發(fā)布流程的；

我們需要的是雪中送炭，而不是錦上添花。

最后一點(diǎn)大家都容易理解“做自己研效平臺(tái)的第一個(gè)用戶“，研效平臺(tái)本身的研發(fā)必須通過自己的平臺(tái)走，這樣才能站在用戶的角度看待自己的方案，才能和業(yè)務(wù)線用戶”共情“。

最后是對(duì)研發(fā)效能行業(yè)未來發(fā)展方向的展望，由于篇幅原因就不再一一展開闡述了，我后續(xù)計(jì)劃會(huì)專門寫篇文章來談?wù)勥@塊的內(nèi)容，敬請(qǐng)期待吧！?

推薦一些衍生閱讀，其中《測(cè)試工程師全棧技術(shù)進(jìn)階與實(shí)踐》和《高效自動(dòng)化測(cè)試平臺(tái)設(shè)計(jì)與開發(fā)實(shí)戰(zhàn)》分別是我2019年和2020年寫的書，主要關(guān)注在軟件測(cè)試效能的提升上，同時(shí)也推薦朱少民教授的《全程軟件測(cè)試（第3版）》。

預(yù)熱一下我和吳駿龍老師正在寫的《軟件研發(fā)效能提升之美》，如果一切順利會(huì)在2021年和大家見面。

后臺(tái)回復(fù)關(guān)鍵詞【GIAC】可獲取本次大會(huì)嘉賓PPT。

總結(jié)

以上是生活随笔為你收集整理的研发效能提升最佳实践的探索的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。