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

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

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

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

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

01

從痛點入手

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

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

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

比如下面這些場景：

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

02

從全局切入

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

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

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

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

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

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

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

03

用戶獲益

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

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

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

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

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

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

04

持續(xù)改進

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

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

比如，我們需要在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è)務(wù)線有可能就等不及這個方案，從而研發(fā)效能的提升就無法如期落地。所以我們認為，研發(fā)效能的落地可以采取“先圈地、后改進”的策略。

05

全局優(yōu)化

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

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

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

06

效能平臺架構(gòu)的靈活性

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

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

07

杜絕“掩耳盜鈴”

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

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

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

那么到底什么是虛榮性指標(biāo)呢？

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

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

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

08

吃自己的“狗糧”

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

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

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

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

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

吳駿龍 茹炳晟 著

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

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

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