筆者常會被問及這樣的問題：“你之前主導的研發(fā)效能提升項目都獲得了成功，如果請你到我們公司來，幾年可以幫助我們把研發(fā)效能做好？”

這其實是一個無解的問題。

從某種程度上說，投入大，周期就會短，但是實施周期不會因為投入無限大而無限變短。我們可以避開很多曾經踩過的坑，盡量少走彎路，但是適合自己的路還是要靠自己走出來的，拔苗助長只會損害長期利益。買了一輛跑車，你就能成為賽車手嗎？

鑒于此，筆者總結了八項實踐建議，如下圖所示，供讀者參考。

圖 研發(fā)效能提升的八項實踐建議

01

從痛點入手

研發(fā)效能提升八項實踐建議的第一項，是“從痛點入手”。

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

所以在推行研發(fā)效能的早期階段，我們通常會采用自下而上的策略，從一個個工程實踐中的實際痛點（釘子）入手，從解決問題的角度打造研發(fā)效能提升的亮點，此時我們追求的是“短、平、快”，遵循的是將問題點逐個擊破的原則。

比如下面這些場景：

• 本地編譯耗時長：提供增量編譯和分布式編譯能力。
• 本地測試困難，測試環(huán)境準備復雜且耗時長：基于Kubernetes的Pod提供一鍵搭建測試環(huán)境的能力。
• 自動化測試用例數量大，執(zhí)行回歸時間過長：采用并發(fā)測試用例執(zhí)行機制，使用幾百、幾千臺測試執(zhí)行機并行執(zhí)行用例，實現(xiàn)用硬件資源換時間。
• 自動化測試用例維護成本高：測試用例采用模塊化和分層體系，實現(xiàn)低成本的自動化用例維護。
• 測試數據準備困難：引入統(tǒng)一的測試數據服務（Test Data Service）能力。
• 研發(fā)后期階段，代碼遞交集中，缺陷井噴：推行測試左移策略，鼓勵研發(fā)自測，遵循“誰開發(fā)、誰測試、誰上線、誰值班”的原則。
• 性能缺陷在研發(fā)后期發(fā)現(xiàn)，修復重測成本高居不下：從性能測試轉變?yōu)樾阅芄こ?，讓性能融入軟件研發(fā)的各個環(huán)節(jié)，而不是最后的一錘子買賣。
• 安全問題頻現(xiàn)：將安全測試能力納入研發(fā)的全生命周期，實現(xiàn)DevSecOps，而不是早期的SDL（Security Development Lifecycle，安全開發(fā)生命周期）。
• 集群規(guī)模龐大，發(fā)布過程耗時過長：各個層級的并發(fā)部署能力，集群內節(jié)點的并發(fā)、集群間的并發(fā)等。
• 項目的過程數據都是后期集中填充，失去度量意義：項目的過程數據由工具自動填充，不再依賴工程師手工輸入。比如，開發(fā)完成的時間不再依賴于開發(fā)人員手工填寫，而是由Jenkins構建完成后自動填寫，以保證所有過程數據的真實有效性，從而為后面的度量和改進提供可靠的信息輸入。

02

從全局切入

第二項是“從全局切入”。

很多時候我們會嘗試去優(yōu)化某個具體的環(huán)節(jié)，而忽略了全局優(yōu)化的可能。

舉個例子，我們去醫(yī)院看病，在掛號時經常會出現(xiàn)排隊半小時，而實際掛號可能就花費兩分鐘的情況，接下來很可能又是漫長的排隊等待醫(yī)生就診，好不容易進入了診室，可能問診不到五分鐘就又被要求去驗血……整個過程中實際有效時間的占比很小。

如果這個時候我們還試圖去優(yōu)化掛號本身的時間，而不去關注優(yōu)化各個環(huán)節(jié)的等待時間，那顯然是錯誤的方向。

因此，效率的提升既要關注單個步驟的優(yōu)化，也要專注減少步驟與步驟之間的無用等待。這一點體檢中心就比公立醫(yī)院做得好很多，我們很少會見到體檢中心每個科室門口都大排長龍的情景，因為體檢中心出于經濟利益的考慮會關注吞吐量，會通過全局排隊調度優(yōu)化來實現(xiàn)更高的盈利。

回到軟件研發(fā)領域，你會發(fā)現(xiàn)類似上面醫(yī)院這種不合理的排隊現(xiàn)象隨處可見，比如軟件缺陷的流轉，軟件需求的實現(xiàn)與交付，軟件制品包發(fā)布等待，等等。

這些也是提升研發(fā)效能需要重點關注的領域，需要從全局理清楚全流程，識別出等待浪費的時間，通過流程再造與優(yōu)化實現(xiàn)全局效率的提升。

03

用戶獲益

對于研發(fā)效能的提升，有一點我們必須牢記，那就是成功的標準不是研發(fā)效能平臺的成功，而是客戶的成功。只有客戶獲益才是檢驗研發(fā)效能項目成功的唯一標準，下面我們再總結一些要點。

偽需求：偽需求是指研發(fā)效能團隊自己臆想出來的需求，是屬于典型的“手里拿著錘子，看什么都像釘子”的典型案例。那么如何識別偽需求呢？識別標準其實很簡單，就看用戶是不是愿意和你分攤成本，如果業(yè)務線已經開始做了，或者想要開始做，那就說明那是業(yè)務線的剛需，如果研發(fā)效能平臺能幫助用戶提供方案，那么研發(fā)效能平臺的接入就是水到渠成的事情。筆者見過很多這類剛需的例子，比如微服務架構下集成測試環(huán)境的搭建就是其中的典型。

結構問題：著名商業(yè)顧問劉潤說過“結構不對，什么都不對”。比如，兩個和尚分粥的故事想必大家都聽過，一碗粥兩個和尚要均分，但是分粥的和尚總想多喝點粥，那怎么才能做到無監(jiān)管情況下的公平呢？教育分粥的和尚說出家人“以少吃為懷”嗎？顯然一旦沒有了監(jiān)管，他就會給自己多分點，解決這個問題的最好辦法就是一個和尚分粥，另一個和尚選粥——這個體制就決定了分粥的均勻性。

因此，好的策略是承認每個人都是自私的，但是我們制定的策略要能夠在人人都是自私的基礎上獲得全局利益的最大化。

如果全局利益最大化是建立在要求每個人都是大公無私的基礎上，那就是失敗的設計，因為這必然會導致失敗?；氐窖邪l(fā)效能提升這個問題上，我們必須抱著“不是我們的研發(fā)效能平臺有多好，而是業(yè)務線用了以后有什么提升”的態(tài)度來定位自己，才能從結構上獲得成功的籌碼。

服務意識：理解了上面的觀點，再來理解服務意識就很容易了。在研發(fā)效能平臺落地的過程中，我們需要和業(yè)務線互助以實現(xiàn)雙贏，業(yè)務線收獲現(xiàn)成可用的方案，研發(fā)效能平臺收獲最佳實踐的沉淀，這些最佳實踐的沉淀是至關重要的，為后期的批量成功復制提供了技術基礎。

04

持續(xù)改進

持續(xù)改進是研發(fā)效能平臺自身發(fā)展的必經之路。

很多問題在開始時，我們的關注點是如何快、速簡單地解決問題，但是當用戶量和接入團隊日益增長后，我們更需要關注解決方案的普適性和通用性。如果一開始就試圖尋找完美的方案，那么必然會得不償失。

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

更好的做法是引入研發(fā)效能的消息中心，通過下游操作的訂閱模式來實現(xiàn)未來的可擴展性。

但是，如果我們從一開始就創(chuàng)建消息中心，實現(xiàn)的難度和成本都會大增，業(yè)務線有可能就等不及這個方案，從而研發(fā)效能的提升就無法如期落地。所以我們認為，研發(fā)效能的落地可以采取“先圈地、后改進”的策略。

05

全局優(yōu)化

研發(fā)效能提升的落地，光靠自下往上和光靠自上往下都是行不通的，而是應該雙管齊下，“從兩邊往中間擠”才是切實可行的方案。

研發(fā)效能提升的初期，主要是靠“自下往上”的工程實踐來實現(xiàn)各種痛點問題的各個擊破，比如通過分布式編譯來降低編譯的時長，通過AI技術來自動生成單元測試的用例，通過分析代碼遞交歷史自動推薦最合適的代碼評審者等。通過這些專項的效率提升逐漸向管理層證明研發(fā)效能提升的實際價值，由此引起管理層對研發(fā)效能的重視，進而為管理層從上往下推進研發(fā)效能的提升打下基礎。

隨著研發(fā)效能實踐逐漸進入深水區(qū)，單一領域效能提升的邊際效應會逐漸遞減，此時基于橫向拉通的全局優(yōu)化變得非常關鍵，自上往下的推動在此時將會起到關鍵的作用。很多橫向跨部門的流程優(yōu)化和整合必須借助管理層的力量才能有效地向前推進。

06

效能平臺架構的靈活性

這里我們先來講兩個概念：“唱戲的”和“搭臺的”。剛開始做研發(fā)效能的時候，我們既是搭臺的又是唱戲的，在研發(fā)效能平臺（搭臺）的基礎上提供各業(yè)務線的解決方案（唱戲）。但是，當業(yè)務線的接入規(guī)模不斷擴大的時候，各個垂直領域的多樣化需求越來越多，我們已經很難應對各家的個性化非通用需求了（每家要唱的戲都不同）。此時，研發(fā)效能平臺的開放能力就成為關鍵，它必須能夠應對這種多樣性，讓業(yè)務線能夠在平臺上實現(xiàn)各自的個性化需求，所以研發(fā)效能平臺本身的技術架構設計必須考慮可擴展性和靈活性。

比如，我們可以Jenkins持續(xù)集成工具視為一個平臺，在這個平臺上支持安裝各種插件，以增強平臺功能，從而實現(xiàn)平臺架構的靈活性。

07

杜絕“掩耳盜鈴”

“掩耳盜鈴”是我們在落地研發(fā)效能過程中經常會犯的錯誤。下面給出了一些研發(fā)效能的“最差實踐”，讀者可以在心里默默數一數被砸中幾條。

• 代碼質量門禁Sonar設而不卡。
• 單元測試只是執(zhí)行，不寫斷言Assert。
• 代碼覆蓋率形同虛設。
• Peer Review走過場。
• 代碼遞交過于隨意。
• 監(jiān)控超配，有報警但無人認領。

另一種掩耳盜鈴的錯誤實踐是普遍采用虛榮性指標來做度量效能。

那么到底什么是虛榮性指標呢？

虛榮性指標是指那些不能直接用來指導后續(xù)行動的指標，我們需要的是可以指導我們行動的可執(zhí)行指標，可以參考以下內容。

• “接入Sonar的工程數”就是虛榮性指標，與之對應的可執(zhí)行指標是“Sonar問題的增長趨勢”和“Sonar問題的修復時長”。
• “系統(tǒng)用戶數”就是虛榮性指標，與之對應的可執(zhí)行指標是“DAU單日活躍用戶數”和“MAU月活躍用戶數”。
• “接入研發(fā)效能平臺的項目數”就是虛榮性指標，與之對應的可執(zhí)行指標是“百分之多少的項目使用過研發(fā)效能平臺來完成開發(fā)測試和發(fā)布流程”。

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

08

吃自己的“狗糧”

最后一點，吃自己的“狗糧”，意為“做自己研發(fā)效能平臺的第一個用戶”，研發(fā)效能平臺本身的研發(fā)流程必須通過自己的平臺來執(zhí)行，這樣才能站在用戶的角度看待自己的方案，才能和業(yè)務線用戶“共情”。

如果我們作為效能工具平臺的研發(fā)團隊，自己都不用自己的工具平臺來完成研發(fā)過程，就很難要求別人也來使用我們的研發(fā)效能平臺。

基于這項理念，我們始終踐行的做法是，研發(fā)效能團隊主持開發(fā)的產品和解決方案，自己必須是第一個用戶，同時我們自己必須認可其帶來的價值，只有這樣才能站在用戶的視角來客觀地評價我們的產品和方案，不至于出現(xiàn)“王婆賣瓜自賣自夸”的現(xiàn)象。

* 本文節(jié)選自《軟件研發(fā)效能提升之美》一書，歡迎閱讀此書了解更多內容！

▊《軟件研發(fā)效能提升之美》

吳駿龍 茹炳晟 著

如果你想了解更多軟件研發(fā)效能的系統(tǒng)知識和趣聞軼事，或正在從事軟件研發(fā)效能相關工作，希望進一步深造學習，請不要錯過這本《軟件研發(fā)效能提升之美》。

本書由兩位行業(yè)知名專家聯(lián)袂編寫，匯聚了行業(yè)前沿的研發(fā)效能提升實踐與案例，同時提煉出大量方法論和經驗反思，以詼諧幽默而又不失嚴謹詳實的風格，全方位多角度覆蓋研發(fā)效能領域的核心知識，深入淺出，發(fā)人深思。收錄作者行業(yè)知名大會熱門演講精華內容，集合研發(fā)效能提升的前沿技術與理念，40余名行業(yè)專家與企業(yè)高管傾情推薦。

做好研發(fā)效能提升是不容易的，我們需要的不僅僅是前沿技術的加持，更重要的是理念的更新?lián)Q代和優(yōu)秀實踐的傳承，而這些，正是本書所希望帶給讀者的核心價值。我們不僅會告訴你“怎么做”，還會告訴你這么做的“緣由和故事”，呈現(xiàn)所有人都能學得會且?guī)У米叩难邪l(fā)效能實踐。這樣，也許若干年后你重讀本書，依然能夠時讀時新，有全新的收獲。