這些年，由于一直在擁有數(shù)萬名研發(fā)人員的大型互聯(lián)網(wǎng)公司做DevOps和研發(fā)效能的相關(guān)工作，做過敏捷和持續(xù)交付實(shí)踐的大規(guī)模推廣，組建并帶領(lǐng)團(tuán)隊(duì)從零開始建設(shè)服務(wù)于全公司的、一體化的、一站式的DevOps平臺(tái)，發(fā)起公司級效能度量委員會(huì)并制定度量指標(biāo)體系；而且在技術(shù)社區(qū)持續(xù)活躍，在各類綜合性/專業(yè)性技術(shù)大會(huì)中擔(dān)任出品人等角色，對互聯(lián)網(wǎng)大廠的研發(fā)效能提升思路和做法有一定的理解，因此，把這些經(jīng)驗(yàn)總結(jié)起來，形成了一個(gè)具有增強(qiáng)回路效果的研發(fā)效能提升體系，我們稱之為研發(fā)效能的“黃金三角”，如圖1所示。

研發(fā)效能的“黃金三角”由三部分組成，分別是效能實(shí)踐、效能平臺(tái)和效能度量，它們彼此獨(dú)立，又相互關(guān)聯(lián)。

其關(guān)聯(lián)關(guān)系如下。

圖1?研發(fā)效能的“黃金三角”

效能實(shí)踐中的優(yōu)秀實(shí)踐可以固化、沉淀到效能平臺(tái)；反過來，效能平臺(tái)支撐效能實(shí)踐的落地。
效能平臺(tái)產(chǎn)生的大量研發(fā)數(shù)據(jù)形成了效能度量中的效能洞察；反過來，效能度量可以持續(xù)觀測效能平臺(tái)中產(chǎn)生的數(shù)據(jù)，進(jìn)行下鉆和深入分析。
效能度量中的洞察和分析結(jié)果可用于針對性地優(yōu)化效能實(shí)踐；反過來，效能實(shí)踐可以給效能度量更多的輸入，幫助其完善度量指標(biāo)集和分析方法。

因此，效能實(shí)踐、效能平臺(tái)和效能度量形成了一個(gè)彼此增強(qiáng)、迭代優(yōu)化的回路，有效利用好這個(gè)增強(qiáng)回路可以幫助企業(yè)持續(xù)提升研發(fā)效能。

下面我們分別從目標(biāo)、價(jià)值主張、實(shí)踐分類和實(shí)施建議幾個(gè)維度展開討論。

效能實(shí)踐

研發(fā)效能實(shí)踐地圖如圖2所示。

圖2 ?研發(fā)效能實(shí)踐地圖

目標(biāo)：提煉和采納與上下文匹配的DevOps及效能提升實(shí)踐。

價(jià)值主張：產(chǎn)品導(dǎo)向+工程卓越。

產(chǎn)品導(dǎo)向：區(qū)別于項(xiàng)目導(dǎo)向的交付模式（在特定時(shí)間內(nèi)，以相對確定的預(yù)算和人力交付預(yù)先計(jì)劃的內(nèi)容），我們更傾向于以產(chǎn)品導(dǎo)向的交付模式組織相關(guān)效能實(shí)踐。產(chǎn)品導(dǎo)向可以讓我們面向長期的業(yè)務(wù)價(jià)值，組織長期穩(wěn)定的敏捷團(tuán)隊(duì)，持續(xù)迭代和優(yōu)化產(chǎn)品。我們承認(rèn)需求的不確定性，要持續(xù)改進(jìn)產(chǎn)品，而不是簡單地遵從既定計(jì)劃；我們要考慮長期產(chǎn)品和團(tuán)隊(duì)能力的建設(shè)，而不是把短期項(xiàng)目做完了事；我們要考慮持續(xù)為客戶創(chuàng)造價(jià)值，而不是看項(xiàng)目有沒有超過預(yù)算；我們要面向工作結(jié)果進(jìn)行響應(yīng)，而不是盯著一些局部的工作產(chǎn)出。
工程卓越：我們必須持續(xù)關(guān)注工程和技術(shù)的卓越性，而不僅僅是交付了多少需求或特性。比起多完成幾個(gè)小功能，也許工程和技術(shù)上的提升所帶來的價(jià)值會(huì)更大。就像微軟CEO薩蒂亞·納德拉所說：“每一天我都在開發(fā)新特性和提升我們的生產(chǎn)力之間進(jìn)行權(quán)衡。”我們要追求用工程化的方法持續(xù)把確定性、重復(fù)性、機(jī)械性的任務(wù)自動(dòng)化，從而在提升效率的同時(shí)讓工程師有更多時(shí)間花在有創(chuàng)造性的事情上。用工程化的思路解決問題，追求工程卓越就是一種“反內(nèi)卷”的表現(xiàn)。

實(shí)踐分類：業(yè)務(wù)敏捷創(chuàng)新實(shí)踐、敏捷精益協(xié)作實(shí)踐、持續(xù)交付工程實(shí)踐、云原生技術(shù)實(shí)踐、組織和團(tuán)隊(duì)拓?fù)涞取?/p>

實(shí)施建議：業(yè)界一致認(rèn)為，DevOps領(lǐng)域和研發(fā)效能領(lǐng)域從來沒有“一刀切”的解決方案，不要迷信某個(gè)成熟模型或某種規(guī)模化框架就一定能對你有幫助。正確的實(shí)踐選擇一定要基于上下文，找出價(jià)值流中最大的障礙，選取工具箱中適當(dāng)?shù)膶?shí)踐，從小范圍開始，縱向進(jìn)行實(shí)驗(yàn)，應(yīng)用敏捷思維來提升組織效能，逐個(gè)解決瓶頸問題，循環(huán)往復(fù)。

效能平臺(tái)

效能平臺(tái)框架如圖3所示。

圖3 ?效能平臺(tái)框架

目標(biāo)：打造一站式、一體化的效能平臺(tái)，支撐軟件交付全生命周期。

價(jià)值主張：自動(dòng)化+自助化、場景化+生態(tài)化。

自動(dòng)化：自動(dòng)化很好理解，DevOps講究“自動(dòng)化一切”，這正是DevOps的精髓“CALMS”中的A（Automation），研究表明高效能的企業(yè)在自動(dòng)化構(gòu)建、自動(dòng)化測試、自動(dòng)化環(huán)境創(chuàng)建和部署、自動(dòng)化監(jiān)控和可觀測性等方面要遠(yuǎn)遠(yuǎn)好于中低效能的企業(yè)。
自助化：自助化代表上下游角色可以通過平臺(tái)緊密銜接，在工具平臺(tái)被某種角色創(chuàng)建出來之后，上下游的其他角色應(yīng)該都可以按需、自助地使用，降低了對某種角色或者某個(gè)人的依賴，這樣組織協(xié)作效率才能提升。
場景化：我們經(jīng)常看到很多所謂的“一站式、一體化”，是按功能領(lǐng)域進(jìn)行劃分并展現(xiàn)相關(guān)能力的，或者說是一個(gè)“拼湊”起來的平臺(tái)。而真正讓管理者和工程師使用順手的、易用的平臺(tái)一定是按研發(fā)場景進(jìn)行組織的。比如，以某一產(chǎn)品為主線貫穿DevOps流程，方便用戶管理產(chǎn)品的相關(guān)需求，創(chuàng)建特性分支，迭代開發(fā)和交付。同樣，以應(yīng)用為主線對運(yùn)維人員來講會(huì)更加友好。
生態(tài)化：在互聯(lián)網(wǎng)大廠搭建效能平臺(tái)時(shí)，遇到的普遍難點(diǎn)是業(yè)務(wù)復(fù)雜、規(guī)模龐大、業(yè)務(wù)獨(dú)特、場景眾多，很難通過一個(gè)團(tuán)隊(duì)的努力滿足整個(gè)公司的需求。但是如果各個(gè)業(yè)務(wù)部門什么都自己做、重復(fù)造“輪子”，甚至相互進(jìn)行惡性競爭就更不好了。因此，平臺(tái)建設(shè)者應(yīng)該更加開放，分離平臺(tái)底座和原子能力的建設(shè)，即通過生態(tài)合作伙伴關(guān)系，促進(jìn)公司效能平臺(tái)的良性發(fā)展。從公司角度來看，減少重復(fù)建設(shè)和避免內(nèi)耗，也都是“反內(nèi)卷”的表現(xiàn)。

實(shí)施建議：效能平臺(tái)的建設(shè)切忌開始就追求“大而全”，所謂的“一站式、一體化”只是手段，不是目的，最終以能滿足研發(fā)場景的訴求為主。尤其是在平臺(tái)建設(shè)初期，不妨以支持To B客戶的思維來運(yùn)營平臺(tái)，深度綁定和跟進(jìn)種子團(tuán)隊(duì)，深刻理解業(yè)務(wù)痛點(diǎn)和需求，這樣做出來的平臺(tái)馬上就會(huì)有人用，然后收集反饋，像滾雪球一樣越做越完善。另外，還要注重需求價(jià)值流和工程價(jià)值流之間的聯(lián)動(dòng)，而不要將其分裂成毫無關(guān)聯(lián)的兩個(gè)系統(tǒng)。

效能度量

目標(biāo)：在正確的方向上開展研發(fā)效能度量和數(shù)據(jù)洞察，指導(dǎo)和驅(qū)動(dòng)效能改進(jìn)和提升。

價(jià)值主張：數(shù)據(jù)驅(qū)動(dòng)+實(shí)驗(yàn)思維。

數(shù)據(jù)驅(qū)動(dòng)：我們經(jīng)常遇到的現(xiàn)象是，一個(gè)組織或者團(tuán)隊(duì)在消耗了大量的“變革”時(shí)間成本和人力資源后，卻無法回答一些看似本質(zhì)的問題。比如，你們的研發(fā)效能到底怎么樣？比別的公司或團(tuán)隊(duì)的好還是差？瓶頸和問題是什么？采納了敏捷或DevOps實(shí)踐之后有沒有效果？下一步應(yīng)該采取什么行動(dòng)？我認(rèn)為，效能度量的目標(biāo)就是讓效能可量化、可分析、可提升，通過數(shù)據(jù)驅(qū)動(dòng)的方式更加理性地評估和改善效能，而不要總是憑直覺感性地說“我覺得……”。用真實(shí)和有效的數(shù)據(jù)說話，勇于挑戰(zhàn)現(xiàn)有流程和規(guī)則，直指研發(fā)痛點(diǎn)和根本原因，也是一種“反內(nèi)卷”的表現(xiàn)。
實(shí)驗(yàn)思維：研發(fā)效能提升沒有“一招鮮，吃遍天”的萬能招式，而是要基于上下文進(jìn)行有針對性的實(shí)驗(yàn)和探索。比如，想提升線上質(zhì)量，降低缺陷密度，經(jīng)驗(yàn)告訴我們應(yīng)該去加強(qiáng)單元測試的覆蓋，完善代碼評審機(jī)制，做好自動(dòng)化測試案例的補(bǔ)充。但是，這真的有效嗎？我們通過數(shù)據(jù)來看，很可能沒有任何效果！并不是說這些實(shí)踐不該做，而是可能做得不到位。比如，只是為了指標(biāo)好看，編寫缺少斷言的單元測試，找熟人走過場通過代碼評審，覆蓋一些非熱點(diǎn)代碼來硬湊測試覆蓋率目標(biāo)等。因此，我們需要實(shí)驗(yàn)思維，找到真正有用的改進(jìn)活動(dòng)及其與結(jié)果之間的因果關(guān)系，有的放矢才會(huì)更有效率和效果。

實(shí)施建議：效能度量本身也是一個(gè)比較復(fù)雜的體系，包含自動(dòng)采集效能數(shù)據(jù)、度量指標(biāo)體系、度量分析模型、度量產(chǎn)品建設(shè)、數(shù)據(jù)驅(qū)動(dòng)和實(shí)驗(yàn)思維等多個(gè)方面，將它們整理后，稱為“研發(fā)效能度量的五項(xiàng)精進(jìn)”，如圖4所示。圖4 ?研發(fā)效能度量的五項(xiàng)精進(jìn)

1.構(gòu)建自動(dòng)采集效能數(shù)據(jù)的能力。
通過系統(tǒng)分層處理好數(shù)據(jù)接入、存儲(chǔ)計(jì)算和數(shù)據(jù)分析。
2.設(shè)計(jì)效能度量指標(biāo)體系。
選取結(jié)果指標(biāo)用于評估能力，選取過程指標(biāo)用于指導(dǎo)分析改進(jìn)。
3.建立效能度量分析模型。
這里的模型是指對研發(fā)效能問題、規(guī)律進(jìn)行抽象后的一種形式化的表達(dá)方式。
模型有很多種，如組織效能模型（戰(zhàn)略資源投入分布和合理性）、產(chǎn)品/團(tuán)隊(duì)效能模型、工程師效能模型等。
我們還要合理采用趨勢分析、相關(guān)性分析、診斷分析等方法，分析效能問題，指導(dǎo)效能改進(jìn)。
4.設(shè)計(jì)和實(shí)現(xiàn)效能度量產(chǎn)品。
首先將數(shù)據(jù)轉(zhuǎn)化為信息，然后將信息轉(zhuǎn)化為知識(shí)，讓用戶可以自助消費(fèi)數(shù)據(jù)，主動(dòng)進(jìn)行分析和洞察。
5.實(shí)現(xiàn)有效的效能數(shù)據(jù)運(yùn)營體系。
要避免不正當(dāng)使用度量而產(chǎn)生的負(fù)面效果，避免將度量指標(biāo)KPI化而導(dǎo)致“造數(shù)據(jù)”的短視行為。
效能改進(jìn)的運(yùn)作模式也很重要，如果只是把數(shù)據(jù)報(bào)表放在那里，效能不會(huì)自己變好，需要有團(tuán)隊(duì)或?qū)Ｈ素?fù)責(zé)推動(dòng)改進(jìn)。