如何用研發(fā)效能搞垮一個團隊

本文作者：茹炳晟 ，校對：張樂

談到研發(fā)效能，我們有著自己的獨到見解。我們看到的現(xiàn)象是：只要努力搞，沒有折騰不垮的團隊。雖然有很多大廠研發(fā)效能做的還不錯，成為了大家膜拜的對象，但是我們也看到很多“內卷”現(xiàn)象的發(fā)生。經(jīng)歷了很多故事，我們更能談談自己的理解和感悟。

研發(fā)效能是目前互聯(lián)網(wǎng)企業(yè)和傳統(tǒng)軟件企業(yè)都高度關注的領域，互聯(lián)網(wǎng)大廠希望通過“研發(fā)效能”實現(xiàn)持續(xù)的研發(fā)能力提升以應對日趨復雜的產(chǎn)品開發(fā)；腰部廠商則希望通過“研發(fā)效能”實現(xiàn)彎道超車，充分發(fā)揮后來者居上的優(yōu)勢；更多中小企業(yè)看到國內互聯(lián)網(wǎng)大廠不約而同地在這個領域重點投入，紛紛也是摩拳擦掌準備在效能領域發(fā)力。

一夜之間，似乎只有推進了研發(fā)效能，才能提升研發(fā)團隊的效率，才能讓自己在和友商的比拼中不至于輸在起跑線上。

那么現(xiàn)在企業(yè)的研發(fā)效能實踐到底為企業(yè)帶來了多大的優(yōu)勢，又幫企業(yè)解決了哪些問題呢？那些推行研發(fā)效能的企業(yè)現(xiàn)在的狀態(tài)怎么樣？研效問題到底解決了嗎？

別急，這些問題其實大多都還沒有解決，而且有些問題可能還變得更糟糕了。畢竟研發(fā)效能的實施沒有捷徑，需要摸著石頭過河，肯定不會能像電影里面演得那樣注定會有皆大歡喜的結局。經(jīng)歷了風雨，不一定能看見彩虹，更有可能會得重感冒。研發(fā)效能問題今天解決不了，不要著急，因為明天同樣也解決不了。所以就讓我們“放心大膽“地看看研發(fā)效能到底是如何搞垮一個團隊的。

要看懂研發(fā)效能如何搞垮一個團隊，我們首先需要對研發(fā)效能有一個全局的認識，需要先從正向的角度來理解研發(fā)效能。

到底什么是研發(fā)效能

和敏捷的概念類似，到底什么是研發(fā)效能很難精確定義。其實很多復雜概念也不是定義出來的，而是逐步演化出來的，是先有現(xiàn)象再找到合適的表述。其實，效率和效能也從來都不是軟件工程的專有名詞，縱觀人類發(fā)展史，就是生產(chǎn)力和生產(chǎn)效率不斷提升的發(fā)展篇章，到了數(shù)字化時代，軟件研發(fā)效能的重要性被凸顯了出來。如果要用一句話來總結研發(fā)效能的話，我們會用“更高效、更高質量、更可靠、可持續(xù)地交付更優(yōu)的業(yè)務價值”來總結。

圖1：研發(fā)效能的“第一性原理”

解釋一下其中幾個關鍵概念：

• 更高效：價值的流動過程必須高效順暢，阻力越小越好。
• 更高質量：如果質量不行，流動越快，死的也會越快。
• 更可靠：安全性和合規(guī)性要保障好。
• 可持續(xù)：輸出不能時斷時續(xù)，小步快跑才是正道，不要憋大招。
• 更優(yōu)的業(yè)務價值：這是從需求層面來說的，你的交付物是不是真正解決了用戶的本質問題。比如：“女生減肥不是本質問題，女生愛美才是”。可以體會一下。

在這個概念的引導下，我們引出持續(xù)開發(fā)，持續(xù)集成，持續(xù)測試，持續(xù)交付和持續(xù)運維的理念，它們是研發(fā)效能落地的必要實踐。與此同時，我們還需要從流動速度，長期質量，客戶價值以及數(shù)據(jù)驅動四個維度來對研發(fā)效能進行有效的度量。

為什么大廠都開始搞研發(fā)效能

阿里的云效、騰訊云的CODING、百度的工程效能白皮書都是國內研發(fā)效能領域的標桿，可是你有沒有想過，為什么最近幾年各大行業(yè)龍頭企業(yè)都紛紛開始在研發(fā)效能領域發(fā)力，而且步調如此一致，我們認為背后的原因有以下這么三點：

圖2：組織層面的“谷倉困局”

01

很多企業(yè)存在大量重復造輪子

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

02

toC產(chǎn)品已經(jīng)趨向飽和

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

03

部分企業(yè)存在“谷倉困局”

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

研發(fā)效能真的能夠提高嗎

既然如此重要，那接下來的問題是研發(fā)效能是否真的能提高？

很不幸，我們的觀點比較悲觀。我們認為研發(fā)效能的絕對值隨著以下因素的增長必然會變得越來越差，就像我（聲明一下，這里沒有張樂老師）的頭發(fā)一樣，隨著時間的推移必然會越來越少一樣。

• 軟件架構本身的復雜度提升（微服務，服務網(wǎng)格等）
• 軟件規(guī)模的不斷增長（集群規(guī)模，數(shù)據(jù)規(guī)模等）
• 研發(fā)團隊人員規(guī)模不斷擴大引發(fā)溝通協(xié)作難度增長

所以，我們能做的不是提升研發(fā)效能的絕對值，而是盡可能減緩研發(fā)效能惡化的程度，使其下降的不至于太快，努力保持現(xiàn)狀就是成功。

圖3：研發(fā)效能的鴻溝

減緩研發(fā)效能惡化我們能干啥

看清了本質后，關于如何減緩研發(fā)效能的惡化，我們能做點什么呢？

可以說研發(fā)效能的涉獵面是很廣的，軟件研發(fā)的每個階段都有研發(fā)效能需要關注的問題，騰訊提出的“研發(fā)效能雙流模型”可以說很好的詮釋了這一概念。雙流模型從軟件研發(fā)的各個階段提出了研發(fā)效能提升的各種工程實踐，并且倡導需求價值流和研發(fā)工程流的自動聯(lián)動。

圖4 研發(fā)效能的雙流模型

這里我們列舉一些實踐給大家拋磚引玉一下，下期的文章我會更系統(tǒng)地來說明其中的最佳實踐。

• 可以通過All-in-one的開發(fā)環(huán)境降低每位開發(fā)人員開發(fā)環(huán)境準備的時間成本，同時又能保證開發(fā)環(huán)境的一致性。更高級的玩法是使用云端集成開發(fā)環(huán)境IDE，實現(xiàn)只要有瀏覽器就能改代碼，這一領域國內典型的代表就是騰訊云CODING旗下的Cloud Studio以及Github目前處于beta測試階段的CodeSpaces。

• 可以借助基于AI的代碼提示插件，大幅度提升IDE中代碼的開發(fā)效率。輸入一段相同的代碼，不借助AI代碼提示插件，需要敲擊鍵盤200次，啟用插件可能只需要50次鍵盤敲擊，這樣可以更容易讓開發(fā)工程師進入“心流“狀態(tài)，實現(xiàn)”人碼合一“。

• 代碼的靜態(tài)檢查沒有必要等到代碼遞交后由CI中的Sonar流程來發(fā)起，那個時候發(fā)現(xiàn)問題再修復為時已晚，完全可以通過Sonar Lint插件結合IDE實時發(fā)起本地的代碼檢查，有問題直接在IDE中提示，直接修復，這樣開發(fā)工程師會更愿意修復問題，因為成本更低，也不會引起修復后的再次發(fā)版。

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

• 對于規(guī)模較大的項目，每次修改后編譯時間比較長。可以采用增量編譯，甚至是分布式編譯（Distcc和CCache）提升效率，對于Maven項目還可以通過緩存pom依賴樹進一步降低編譯時間。

• 前端開發(fā)可以借助JRebel和Nodemon之類的工具使前端開發(fā)預覽的體驗更流暢，實現(xiàn)前端代碼的“所見即所得”，避免重復的編譯、打包、部署和重啟步驟，以此提高開發(fā)過程的流暢度。

• 選擇適合項目的代碼分支策略對提升效率也大有幫助。

• 構建高度自動化的CI和CD流水線將大幅提升價值的流轉速率。

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

• 引入DevSecOps與DevPerfOps實踐，使安全和性能不再局限在測試領域，而是形成體系化的全局工程能力，讓安全測試成為安全工程，性能測試成為性能工程。

• ...

研發(fā)效能的“羅生門”

好了，理解了研發(fā)效能的正面觀點后，我們再回來看看研發(fā)效能在實際落地過程中又是一番什么樣的景象。

可以說理想很豐滿，但是現(xiàn)實很骨感，下面就我一起看看國內研發(fā)效能的各種亂象。

01

迷信單點局部能力，忽略全局優(yōu)化和拉通的重要性

研發(fā)效能的單點能力其實都不缺，各個領域都有很多不錯的垂直能力工具，但是把各個單點能力橫向集成與拉通，能夠從一站式全流程的維度設計和規(guī)劃的研發(fā)效能成熟平臺還是鳳毛麟角。現(xiàn)在國內很多在研效領域有投入的公司很多其實還在建設，甚至是重復建設單點能力的研效工具，這個思路在初期可行，但是單點改進的效果會隨著時間收益遞減，企業(yè)往往缺少從更高視角對研發(fā)效能進行整體規(guī)劃的能力。很多時候局部優(yōu)化并不能帶來全局優(yōu)化，有時候還會是全局惡化。

02

具有普適性的通用研發(fā)效能工具其實沒有專屬工具來的好用

既然打造了研發(fā)工具，那就需要到業(yè)務部門進行推廣，讓這些研效工具能夠被業(yè)務部門使用起來。其實，很多比較大的業(yè)務團隊在CI/CD、測試與運維領域都有自己的人力投入，也開發(fā)和維護了不少能夠切實滿足當下業(yè)務的研發(fā)工具體系。此時要把新打造的研效工具來替換業(yè)務部門原來的工具，肯定會遇到很強的阻力。除非新的工具能夠比老工具好10倍，用戶才可能有意愿替換，但實際情況是新打造的工具為了考慮普適性很有可能還沒有原來的工具好，再加上工具替換的學習成本，所以除非是管理層強壓，否則推廣成功的概率微乎其微。即使是管理層強壓，實際的執(zhí)行也會大打折扣，接入但不實際使用的情況不在少數(shù)。

03

用“偽”工程實踐和“面子工程”來濫竽充數(shù)

如果你去比較國內外研發(fā)效能工程實踐的差距，你會發(fā)現(xiàn)國內公司和硅谷公司的差距還是相當明顯的。但是當你逐項（比如單元測試，靜態(tài)代碼掃描，編譯加速等）比較雙方開展的具體工程實踐時，你會驚訝地發(fā)現(xiàn)從實踐條目的數(shù)量來說，國內公司的一點都不亞于硅谷公司，在某些領域甚至有過之而不及。那為什么這個差距還會如此明顯呢？我們認為這其中最關鍵的點在于，國內的很多工程實踐是為了做而做，為的是“政治上的正確”，而不是從本質上認可這一工程實踐的實際價值。這里比較典型的例子就是代碼評審和單元測試。雖然很多國內互聯(lián)網(wǎng)大廠都在推進代碼評審和單元測試的落地，但是在實際過程中往往都走偏了。代碼評審變成了一個流程，而實際的評審質量和效果無人問津，評審人的評審也不算工作量，也不擔任何責任，這樣的代碼評審能有什么效果，結果可想而知。單元測試也淪為一種口號，都說要貫徹單測，但是在計劃排期的時候壓根沒有給單測留任何的時間和人力資源，可想而知這樣的單測是否能成功開展。所以，國內公司缺的不是工程實踐的多少，而是工程實踐執(zhí)行的深度。不要用“偽”工程實踐和“面子工程”來濫竽充數(shù)。

04

忽略研發(fā)效能工具體系的長尾效應

再回到研效工具建設的話題上，很多時候管理團隊希望能夠打造一套一站式普遍適用的研發(fā)效能平臺，希望公司內大部分業(yè)務都能順利接入，這和想法的確非常好，但是不可否認的，研效平臺和工具往往具有非標準的長尾效應，我們很難打造一套統(tǒng)一的研效解決方案來應對所有的業(yè)務研發(fā)需求，各種業(yè)務研發(fā)流程的特殊性是不容忽視的。退一萬步說，即使我們通過高度可配置化的流程引擎實現(xiàn)了統(tǒng)一研效解決方案，那么這樣的系統(tǒng)會因為過于靈活，使用路徑過多而易用性變得很差。這兩者的矛盾是很難調和的。

05

盲目跟風

再來看看一些中小型研發(fā)團隊，他們看到國內大廠在研效領域不約而同的重兵投入，所以也會跟風。他們往往試圖通過引進大廠工具和大廠人才來作為研效的突破口，但實際的效果可能差強人意。大廠的研效工具體系固然有其先進性，但是是否能夠適配你的研發(fā)規(guī)模和流程是有待商榷的，同樣的藥給大象吃可以治病，而給你吃可能直接喪命。很多時候研效工具應該被視為起點，而不是終點，就像你買了一輛跑車，你依舊不能成為賽車手。

06

迷信外部專家

引入大廠專家其實也是類似的邏輯，我常常會被問及這樣的問題：“你之前主導的研效提升項目都獲得了成功，如果請你過來，多久能搞定”？這其實是一個無解的問題。一定程度上，投入大，周期就會短，但是，實施周期不會因為投入無限大而無限變短。我可以幫你避開很多曾經(jīng)踩過的坑，盡量少走彎路，犯過的錯誤不再次犯，但是，適合自己的路子還是要靠自己走出來，拔苗助長只會損害長期利益。

07

研效度量的罪與罰

最后再來看看度量。研發(fā)效能的度量一直以來都是很敏感的話題。科學管理時代我們奉行“沒有度量就沒有改進”，但是數(shù)字時代這一命題是否依然成立需要我們的反思。現(xiàn)實事物復雜而多面，度量正是為描述和對比這些具象事實而采取的抽象和量化措施，從某種意義上來說，度量的結果一定是片面的，反映部分事實。但沒有銀彈，也沒有完美的效能度量。數(shù)據(jù)本身不會騙人，但數(shù)據(jù)的呈現(xiàn)和解讀卻有很大的空間值得探索。那些不懂數(shù)據(jù)的人是糟糕的，而最最糟糕的人是那些只看數(shù)字的人。當把度量變成一個指標游戲的時候，永遠不要低估人們在追求指標方面“創(chuàng)造性”，總之我們不應該純粹面向指標去開展工作，而應該看到指標背后更大的目標，或者是制定這些指標背后的真正動機。

總體來看，對于研發(fā)效能，我認為最重要的不是技術升級，而應該是思維升級，我們身處數(shù)字化的變革之中，需要轉換的是自己的思維方式，我們需要將科學管理時代的思維徹底轉為字節(jié)經(jīng)濟時代的思維。

研發(fā)效能的“冷思考”

最后，回到工程師層面，研發(fā)效能的提升對我們而言又意味著什么？

01

工具效率的提升并沒有減少我們的工作時長

新工具新平臺在幫助我們提升效率的同時，也不斷增加著我們學習的成本。用前端開發(fā)來舉例子，以全家桶為基礎的前端工程化大幅度提高了前端開發(fā)的效率，但與此同時前端開發(fā)工程師的學習成本卻在成倍增加，“又更新了，實在學不動了”一定程度反映了前端同開發(fā)的悲哀和無奈。

02

技術的升級正在不斷模糊工作和生活的邊界

早年時候的工作溝通除了面聊以外主要靠郵件，非工作時段老板給你發(fā)郵件你有各種正當理由不用及時回復，可是現(xiàn)在及時通訊工具IM（那個消息已讀提示，你懂的）再結合各種ChatOps實踐，已經(jīng)讓工程師已經(jīng)無法區(qū)分什么是工作什么是生活了，這難道是我們想要的嗎？

隨著在研發(fā)效能領域的不斷投入，會有越來越多的研效工具誕生，所有這些工具都使人與工作之間的鏈接更加緊密，人越來越像工具，而工具越來越像人。我們之所以創(chuàng)造工具是想減輕我們自己的工作，但現(xiàn)實卻很可能發(fā)展成，我們最終淪為被親手創(chuàng)造的工具奴役。我們致力于的研發(fā)效能，究竟會成就我們，還是毀了我們？值得我們深入思考。

對于研發(fā)效能，實施的思路不對，方法不對會搞垮一個團隊，我們需要的是體系化的方法論和相應的工程實踐。請期待我們的下篇文章對此作出解讀，讓我們拭目以待！

作者：茹炳晟

簡介：騰訊T4 級專家，騰訊研究院特約研究員，業(yè)界知名實戰(zhàn)派研發(fā)效能和軟件質量雙領域專家。騰訊云、阿里云、華為云最具價值專家，Certified DevOps Enterprise Coach ，年度 IT 圖書最具影響力作者，暢銷書《測試工程師全棧技術進階與實踐》和《高效自動化測試平臺：設計與開發(fā)實戰(zhàn)》作者，極客時間《軟件測試 52 講—從小工到專家的實戰(zhàn)心法》作者。