以下文章來源於 msup
校對：張樂
作者：茹炳晟
簡介：騰訊 T4 級專家，騰訊研究院特約研究員，業界知名實戰派研發效能和軟體質量雙領域專家。騰訊雲、阿里雲、華為雲最具價值專家，Certified DevOps Enterprise Coach ，年度 IT 圖書最具影響力作者，暢銷書《測試工程師全棧技術進階與實踐》和《高效自動化測試平臺：設計與開發實戰》作者，極客時間《軟體測試 52 講—從小工到專家的實戰心法》作者。
談到研發效能，我們有著自己的獨到見解。我們看到的現象是：只要努力搞，沒有折騰不垮的團隊。雖然有很多大廠研發效能做的還不錯，成為了大家膜拜的物件，但是我們也看到很多“內卷”現象的發生。經歷了很多故事，我們更能談談自己的理解和感悟。
研發效能是目前網際網路企業和傳統軟體企業都高度關注的領域，網際網路大廠希望通過“研發效能”實現持續的研發能力提升以應對日趨複雜的產品開發；腰部廠商則希望通過“研發效能”實現彎道超車，充分發揮後來者居上的優勢；更多中小企業看到國內網際網路大廠不約而同地在這個領域重點投入，紛紛也是摩拳擦掌準備在效能領域發力。
一夜之間，似乎只有推進了研發效能，才能提升研發團隊的效率，才能讓自己在和友商的比拼中不至於輸在起跑線上。
那麼現在企業的研發效能實踐到底為企業帶來了多大的優勢，又幫企業解決了哪些問題呢？那些推行研發效能的企業現在的狀態怎麼樣？研效問題到底解決了嗎？
別急，這些問題其實大多都還沒有解決，而且有些問題可能還變得更糟糕了。畢竟研發效能的實施沒有捷徑，需要摸著石頭過河，肯定不會能像電影裡面演得那樣註定會有皆大歡喜的結局。經歷了風雨，不一定能看見彩虹，更有可能會得重感冒。研發效能問題今天解決不了，不要著急，因為明天同樣也解決不了。所以就讓我們“放心大膽“地看看研發效能到底是如何搞垮一個團隊的。
要看懂研發效能如何搞垮一個團隊，我們首先需要對研發效能有一個全域性的認識，需要先從正向的角度來理解研發效能。
到底什麼是研發效能
和敏捷的概念類似，到底什麼是研發效能很難精確定義。其實很多複雜概念也不是定義出來的，而是逐步演化出來的，是先有現象再找到合適的表述。其實，效率和效能也從來都不是軟體工程的專有名詞，縱觀人類發展史，就是生產力和生產效率不斷提升的發展篇章，到了數字化時代，軟體研發效能的重要性被凸顯了出來。如果要用一句話來總結研發效能的話，我們會用“更高效、更高質量、更可靠、可持續地交付更優的業務價值”來總結。
研發效能的“第一性原理”
解釋一下其中幾個關鍵概念：
- 更高效：價值的流動過程必須高效順暢，阻力越小越好。
- 更高質量：如果質量不行，流動越快，死的也會越快。
- 更可靠：安全性和合規性要保障好。
- 可持續：輸出不能時斷時續，小步快跑才是正道，不要憋大招。
- 更優的業務價值：這是從需求層面來說的，你的交付物是不是真正解決了使用者的本質問題。比如：“女生減肥不是本質問題，女生愛美才是”。可以體會一下。
在這個概念的引導下，我們引出持續開發，持續整合，持續測試，持續交付和持續運維的理念，它們是研發效能落地的必要實踐。與此同時，我們還需要從流動速度，長期質量，客戶價值以及資料驅動四個維度來對研發效能進行有效的度量。
為什麼大廠都開始搞研發效能
阿里的雲效、騰訊雲的 CODING、百度的工程效能白皮書都是國內研發效能領域的標杆，可是你有沒有想過，為什麼最近幾年各大行業龍頭企業都紛紛開始在研發效能領域發力，而且步調如此一致，我們認為背後的原因有以下這麼三點：
組織層面的“穀倉困局”
01
很多企業存在大量重複造輪子
就像“中臺”概念一樣，現在很多大企業的產品線非常廣，其中存在大量重複的輪子，如果我們關注業務上的重複輪子，那麼就是業務中臺；如果我們關注資料建設上的重複輪子，那麼就是資料中臺；如果我們關注研發效能建設上的重複輪子，那就是研效平臺，其實研效平臺在某種程度上也可以稱之為“研發效能中臺”，其目標是實現企業級跨產品跨專案的研發能力複用，避免原來每條產品線都在做研發效能所必須的“0 到 1”，沒人有精力去關注更有價值的“1 到 n”。現代化的研效平臺會統一來打造組織級別通用研發能力的最佳實踐平臺。
02
toC 產品已經趨向飽和
從商業視角來看，現在 toC 產品已經趨向飽和，過去大量閒置時間等待被 APP 填滿的紅利時代已經一去不復返了，以前業務發展極快，那麼用燒錢的方式（粗放式研發，人海戰術）換取更快的市場佔有率達到贏家通吃是最佳選擇，那個時代關心的是軟體產品輸出，研發的效率都可以用錢填上。而現在 toC 已經逐漸走向紅海，同時研發的規模也比以往任何時候都要大，是時候要勒緊褲腰帶過日子了，當開源（開源節流中的開源）遇到瓶頸了，節流就應該發揮作用。這個節流就是研發效能的提升，同樣的資源，同樣的時間來獲得更多的產出。
03
部分企業存在“穀倉困局”
從組織架構層面看，很多企業都存在“穀倉困局”，研發各個環節內部可能已經做了優化，但是跨環節的協作可能就會有大量的流轉與溝通成本，從而影響全域性效率。基於流程優化，打破各個環節看不見的牆，去除不必要的等待，提升價值流動速度正是研發效能在流程優化層面試圖解決的一大類問題。
研發效能真的能夠提高嗎
既然如此重要，那接下來的問題是研發效能是否真的能提高？
很不幸，我們的觀點比較悲觀。我們認為研發效能的絕對值隨著以下因素的增長必然會變得越來越差，就像我（宣告一下，這裡沒有張樂老師）的頭髮一樣，隨著時間的推移必然會越來越少一樣。
- 軟體架構本身的複雜度提升（微服務，服務網格等）
- 軟體規模的不斷增長（叢集規模，資料規模等）
- 研發團隊人員規模不斷擴大引發溝通協作難度增長
所以，我們能做的不是提升研發效能的絕對值，而是儘可能減緩研發效能惡化的程度，使其下降的不至於太快，努力保持現狀就是成功。
研發效能的鴻溝
減緩研發效能惡化我們能幹啥
看清了本質後，關於如何減緩研發效能的惡化，我們能做點什麼呢？
可以說研發效能的涉獵面是很廣的，軟體研發的每個階段都有研發效能需要關注的問題，騰訊提出的“研發效能雙流模型”可以說很好的詮釋了這一概念。雙流模型從軟體研發的各個階段提出了研發效能提升的各種工程實踐，並且倡導需求價值流和研發工程流的自動聯動。
研發效能的雙流模型
這裡我們列舉一些實踐給大家拋磚引玉一下，下期的文章我會更系統地來說明其中的最佳實踐。
- 可以通過 All-in-one 的開發環境降低每位開發人員開發環境準備的時間成本，同時又能保證開發環境的一致性。更高階的玩法是使用雲端整合開發環境 IDE，實現只要有瀏覽器就能改程式碼，這一領域國內典型的代表就是騰訊雲 CODING 旗下的 Cloud Studio 以及 Github 目前處於 beta 測試階段的 CodeSpaces。
- 可以藉助基於 AI 的程式碼提示外掛，大幅度提升 IDE 中程式碼的開發效率。輸入一段相同的程式碼，不借助 AI 程式碼提示外掛，需要敲擊鍵盤 200 次，啟用外掛可能只需要 50 次鍵盤敲擊，這樣可以更容易讓開發工程師進入“心流”狀態，實現“人碼合一”。
- 程式碼的靜態檢查沒有必要等到程式碼遞交後由 CI 中的 Sonar 流程來發起，那個時候發現問題再修復為時已晚，完全可以通過 Sonar Lint 外掛結合 IDE 實時發起本地的程式碼檢查，有問題直接在 IDE 中提示，直接修復，這樣開發工程師會更願意修復問題，因為成本更低，也不會引起修復後的再次發版。
- 單元測試比較耗費時間，可以藉助 EvoSuite 之類的工具降低單元測試的開發工作量。
- 對於規模較大的專案，每次修改後編譯時間比較長。可以採用增量編譯，甚至是分散式編譯（Distcc 和 CCache）提升效率，對於 Maven 專案還可以通過快取 pom 依賴樹進一步降低編譯時間。
- 前端開發可以藉助 JRebel 和 Nodemon 之類的工具使前端開發預覽的體驗更流暢，實現前端程式碼的“所見即所得”，避免重複的編譯、打包、部署和重啟步驟，以此提高開發過程的流暢度。
- 選擇適合專案的程式碼分支策略對提升效率也大有幫助。
- 構建高度自動化的 CI 和 CD 流水線將大幅提升價值的流轉速率。
- 選擇合適的釋出策略也會對效能和風險之間的平衡起到積極的作用。比如架構相對簡單，但是叢集規模龐大，優選金絲雀，如果架構比較複雜，但是叢集規模不是太大，可能藍綠髮布更佔優勢。
- 引入 DevSecOps 與 DevPerfOps 實踐，使安全和效能不再侷限在測試領域，而是形成體系化的全域性工程能力，讓安全測試成為安全工程，效能測試成為效能工程。
- ...
研發效能的“羅生門”
好了，理解了研發效能的正面觀點後，我們再回來看看研發效能在實際落地過程中又是一番什麼樣的景象。
可以說理想很豐滿，但是現實很骨感，下面就我一起看看國內研發效能的各種亂象。
01
迷信單點區域性能力，忽略全域性優化和拉通的重要性
研發效能的單點能力其實都不缺，各個領域都有很多不錯的垂直能力工具，但是把各個單點能力橫向整合與拉通，能夠從一站式全流程的維度設計和規劃的研發效能成熟平臺還是鳳毛麟角。現在國內很多在研效領域有投入的公司很多其實還在建設，甚至是重複建設單點能力的研效工具，這個思路在初期可行，但是單點改進的效果會隨著時間收益遞減，企業往往缺少從更高視角對研發效能進行整體規劃的能力。很多時候區域性優化並不能帶來全域性優化，有時候還會是全域性惡化。
02
具有普適性的通用研發效能工具其實沒有專屬工具來的好用
既然打造了研發工具，那就需要到業務部門進行推廣，讓這些研效工具能夠被業務部門使用起來。其實，很多比較大的業務團隊在 CI/CD、測試與運維領域都有自己的人力投入，也開發和維護了不少能夠切實滿足當下業務的研發工具體系。此時要把新打造的研效工具來替換業務部門原來的工具，肯定會遇到很強的阻力。除非新的工具能夠比老工具好10倍，使用者才可能有意願替換，但實際情況是新打造的工具為了考慮普適性很有可能還沒有原來的工具好，再加上工具替換的學習成本，所以除非是管理層強壓，否則推廣成功的概率微乎其微。即使是管理層強壓，實際的執行也會大打折扣，接入但不實際使用的情況不在少數。
03
用“偽”工程實踐和“面子工程”來濫竽充數
如果你去比較國內外研發效能工程實踐的差距，你會發現國內公司和矽谷公司的差距還是相當明顯的。但是當你逐項（比如單元測試，靜態程式碼掃描，編譯加速等）比較雙方開展的具體工程實踐時，你會驚訝地發現從實踐條目的數量來說，國內公司的一點都不亞於矽谷公司，在某些領域甚至有過之而不及。那為什麼這個差距還會如此明顯呢？我們認為這其中最關鍵的點在於，國內的很多工程實踐是為了做而做，為的是“政治上的正確”，而不是從本質上認可這一工程實踐的實際價值。這裡比較典型的例子就是程式碼評審和單元測試。雖然很多國內網際網路大廠都在推進程式碼評審和單元測試的落地，但是在實際過程中往往都走偏了。程式碼評審變成了一個流程，而實際的評審質量和效果無人問津，評審人的評審也不算工作量，也不擔任何責任，這樣的程式碼評審能有什麼效果，結果可想而知。單元測試也淪為一種口號，都說要貫徹單測，但是在計劃排期的時候壓根沒有給單測留任何的時間和人力資源，可想而知這樣的單測是否能成功開展。所以，國內公司缺的不是工程實踐的多少，而是工程實踐執行的深度。不要用“偽”工程實踐和“面子工程”來濫竽充數。
04
忽略研發效能工具體系的長尾效應
再回到研效工具建設的話題上，很多時候管理團隊希望能夠打造一套一站式普遍適用的研發效能平臺，希望公司內大部分業務都能順利接入，這和想法的確非常好，但是不可否認的，研效平臺和工具往往具有非標準的長尾效應，我們很難打造一套統一的研效解決方案來應對所有的業務研發需求，各種業務研發流程的特殊性是不容忽視的。退一萬步說，即使我們通過高度可配置化的流程引擎實現了統一研效解決方案，那麼這樣的系統會因為過於靈活，使用路徑過多而易用性變得很差。這兩者的矛盾是很難調和的。
05
盲目跟風
再來看看一些中小型研發團隊，他們看到國內大廠在研效領域不約而同的重兵投入，所以也會跟風。他們往往試圖通過引進大廠工具和大廠人才來作為研效的突破口，但實際的效果可能差強人意。大廠的研效工具體系固然有其先進性，但是是否能夠適配你的研發規模和流程是有待商榷的，同樣的藥給大象吃可以治病，而給你吃可能直接喪命。很多時候研效工具應該被視為起點，而不是終點，就像你買了一輛跑車，你依舊不能成為賽車手。
06
迷信外部專家
引入大廠專家其實也是類似的邏輯，我常常會被問及這樣的問題：“你之前主導的研效提升專案都獲得了成功，如果請你過來，多久能搞定”？這其實是一個無解的問題。一定程度上，投入大，週期就會短，但是，實施週期不會因為投入無限大而無限變短。我可以幫你避開很多曾經踩過的坑，儘量少走彎路，犯過的錯誤不再次犯，但是，適合自己的路子還是要靠自己走出來，拔苗助長只會損害長期利益。
07
研效度量的罪與罰
最後再來看看度量。研發效能的度量一直以來都是很敏感的話題。科學管理時代我們奉行“沒有度量就沒有改進”，但是數字時代這一命題是否依然成立需要我們的反思。現實事物複雜而多面，度量正是為描述和對比這些具象事實而採取的抽象和量化措施，從某種意義上來說，度量的結果一定是片面的，反映部分事實。但沒有銀彈，也沒有完美的效能度量。資料本身不會騙人，但資料的呈現和解讀卻有很大的空間值得探索。那些不懂資料的人是糟糕的，而最最糟糕的人是那些只看數字的人。當把度量變成一個指標遊戲的時候，永遠不要低估人們在追求指標方面“創造性”，總之我們不應該純粹面向指標去開展工作，而應該看到指標背後更大的目標，或者是制定這些指標背後的真正動機。
總體來看，對於研發效能，我認為最重要的不是技術升級，而應該是思維升級，我們身處數字化的變革之中，需要轉換的是自己的思維方式，我們需要將科學管理時代的思維徹底轉為位元組經濟時代的思維。
研發效能的“冷思考”
最後，回到工程師層面，研發效能的提升對我們而言又意味著什麼？
01
工具效率的提升並沒有減少我們的工作時長
新工具新平臺在幫助我們提升效率的同時，也不斷增加著我們學習的成本。用前端開發來舉例子，以全家桶為基礎的前端工程化大幅度提高了前端開發的效率，但與此同時前端開發工程師的學習成本卻在成倍增加，“又更新了，實在學不動了”一定程度反映了前端同開發的悲哀和無奈。
02
技術的升級正在不斷模糊工作和生活的邊界
早年時候的工作溝通除了面聊以外主要靠郵件，非工作時段老闆給你發郵件你有各種正當理由不用及時回覆，可是現在及時通訊工具 IM（那個訊息已讀提示，你懂的）再結合各種 ChatOps 實踐，已經讓工程師已經無法區分什麼是工作什麼是生活了，這難道是我們想要的嗎？
隨著在研發效能領域的不斷投入，會有越來越多的研效工具誕生，所有這些工具都使人與工作之間的連結更加緊密，人越來越像工具，而工具越來越像人。我們之所以創造工具是想減輕我們自己的工作，但現實卻很可能發展成，我們最終淪為被親手創造的工具奴役。我們致力於的研發效能，究竟會成就我們，還是毀了我們？值得我們深入思考。
對於研發效能，實施的思路不對，方法不對會搞垮一個團隊，我們需要的是體系化的方法論和相應的工程實踐。請期待我們的下篇文章對此作出解讀。同時我們也熱忱邀請你，參加騰訊雲 CIF 工程效能峰會 —— CODING DevOps 高階架構師王煒將帶你走進論壇 - 雲原生加持下的研發效能升級，6 位業內專家將從工具到實踐，深入淺出分析並解決業務接入雲原生過程的痛點與難點，幫助團隊實現需求實時響應，業務快速開發上線。
本次峰會將於 2021 年 10 月 19 - 20 日以線上會議的形式召開，以“雲上開發，化繁為簡”為主題，聚焦雲原生加持下的研發效能升級，與數字化風潮下的企業轉型實踐。
掃描海報二維碼
更多精彩議程等你開啟
