如何度量研發效能？

簡介： 現在，研發效能愈來愈受到重視。那麼效能的本質是什麼？效能度量的終極目標是什麼？如何讓「專家經驗」產品化、標準化，從「過後覆盤」發展爲「風險管控」？本文從度量的分類、效能本質、模型的存儲等方面聊一聊效能度量，並分享一種研發度量領域模型。

沒有可靠的度量就沒法有效的改進，高度數字化的軟件研發領域一直是進行各種效能度量嘗試的創新重地。

阿里雲·雲效服務的內部版本「Aone」承載着阿里集團數百個BU協同研發和持續交付的職責，筆者在數月前短暫的參與了該平臺的效能透視鏡板塊建設，於是得以從平臺的「上帝視角」從新審視效能度量這件事，隨着項目開展，略微摸索了些門道。此文中觀點源於這段時間裏筆者在團隊內以及與周邊相關團隊的討論和我的思考，且做拋磚引玉之用。

度量的分類

度量的分類方式有不少，其中比較有意思的一種角度，是根據目標意圖將度量劃分爲「針對人的度量」和「針對事的度量」。

任何協做系統都離不開人的參與，加之可與績效、考覈等事情牽上關係，即便相關指標的分析每每伴隨着爭議，針對人的度量在企業裏有時依然被視爲一種「剛需」。譬如「代碼量」、「代碼質量」、「工做時長」等數據評判都是常見的依據指標。從產品實現而言，因爲對結果可解釋性要求高，這類度量的單因素指標居多，計算方案一般不會太複雜，宜採用小範圍同維度橫向比較，防止過分泛化。

相比之下，針對事度量的範疇和方法更加靈活。既包括簡單的數值指標，譬如產研中的發佈頻率、需求交付時長；也包括須要對比分析的多元指標，譬如需求在各階段的停留時長、缺陷在各環境的漏測率等。在就事論事的基礎上，爲了更全面的理解事實的客觀規律，還常常須要將一組數據向上聚合（譬如整個部門、整個項目的狀況）或者跨領域關聯（譬如業務領域需求關聯到相關代碼提交狀況），從而得到更寬的觀察視角。因爲涉及的度量主體更多，有時爲了肯定哪一個主體是主要的影響因素，還須要進行額外的歸因斷定。相較於以人爲目標的度量，對事進行度量時，能夠包含更多的經驗和推理因素。

對人或對事主要是針對度量目的而言，在實際運用時，二者採用的具體指標會有許多共同之處，並不能一律而論。根據管理學中的「平衡計分卡（The Balanced ScoreCard）」理論，度量活動要遵循「目標-度量-指標-行動」的規則，指標最終服務於目標的達成，好的度量產品不只應當反映「發生了什麼」，還應當能根據目標提供「該怎麼作」的輔助建議。所以度量類產品的成敗，不只是對指標設計者的領域理解、抽象能力的挑戰，並且對產品自身的業務目標清晰度也會提出很高的要求。

效能的本質

歸根究底而言，效能的本質是對價值流動速度和質量的評價。

「價值流」的概念伴隨着精益思想的傳播，被愈來愈多行業所接納。不過不多有其餘哪一個行業可以像軟件研發行業這樣，可以讓價值交付的各個環節幾乎徹底在線數字化，從而提供大量可分析的過程數據樣本。

所謂價值流動過程能夠表示爲，「價值原料」在可被度量的價值加工活動之間有序傳遞，不斷疊加價值增量，最終造成可被消費的「價值產物」。下圖將這一過程的度量抽象爲一種很是簡潔的表示結構，可稱爲效能度量的「元模型」。

度量中所用的各種「領域特徵」則是由在此元模型之上的領域對象，以及基於這些對象的「領域指標」來定義的。

譬如在研發領域，「價值原料」能夠是一個業務方的需求，或是一個開發者突發奇想的創意。可被度量的活動包括需求拆解、任務指派、代碼編寫、測試、部署、驗證、發佈等等。每一個活動自己都具備可被觀測的屬性，實體之間也具備可被量化的關係。這些實體、屬性、關係就組成了特定領域的模型，下圖展現了一種簡化的研發度量領域模型（爲了美觀省略掉不少實體關係鏈接，僅做示意）。

有了領域模型，就能夠基於規則制定指標。指標一般被描述爲各類量化特徵和實體屬性的數值計算。有些指標是領域無關的，譬如端到端流通時長；有些指標是多個領域之間能夠複用的，譬如許多行業都會有單位時間任務吞吐量、任務按時完成率這樣的指標；有些指標是領域特有的，譬如研發領域的千行代碼缺陷率等等。

在指標之上，還須要有與具體運用場景相匹配的工具或平臺來將度量結果轉換爲便於觀察分析的表現形式。譬如各類圖表、報表，以及事件通知。

元模型和領域對象的分離，彷佛可以造成一種足夠抽象的通用度量產品，經過領域相關的指標規則、展現規則、通知告警規則，快速適配不一樣目標和場景，然而現實狀況其實更復雜。一方面受制於計算能力，有些指標實際沒法根據模型+規則實時計算出來，必須單獨預先算好，以空間換時間。另外一方面受限於價值增值過程的可觀測性，並不是全部行爲的結果都能當即被簡單量化（不然說服人們堅持鍛鍊身體就容易多了），即便在高度數字化的軟件研發領域，依然存在數據質量和時效性問題，在使用數據時須要加以考慮。所以各類效能的場景雖然具備十分類似的流動特徵，實際產品依然會不可避免的根據業務定製化，萬能的度量工具或公式是不存在的。

模型的存儲

對於度量模型的存儲，圖數據庫多是最好的選擇，沒有之一。

相比結構化的SQL數據庫和文檔型的NoSQL數據庫，圖數據庫屬於比較小衆的一種偏門奇術，主要用在知識圖譜和基於關係的信息搜索領域。從基本特徵而言，圖數據庫一般具有NoSQL的非結構化KV存儲能力，容許同一類實體具備不一樣屬性項的實例，這對於處理來自多種數據源或多個子類型的實體信息帶來很大便利。同時，圖數據庫一般能像SQL數據庫那樣支持事務和多實體關聯查詢。不只如此，圖數據庫對複雜關係的檢索性能遠高於SQL數據庫，對於判斷、循環查詢的支持也比SQL存儲過程更加優雅。

然而這些基礎能力上的差別，並不是我推薦將圖數據庫用於效能度量的主要緣由。

好的技術選型應該可以充分適應潛在的業務需求變更，避免過早將技術實現耦合到局部的應用場景。在基於SQL表的開發模式裏，「表結構設計」是在軟件詳細設計階段裏很是重要的一個環節，由於它不只是對總體業務領域的建模，還關係着將來數據查詢的效率和便利性。熟悉SQL表設計的同窗應該知道，1對一、1對N、N對N關係，數據表的處理方法是徹底不一樣的：N對N關係須要額外設計關聯表，1對N關係一般是在後者的實體上設計外鍵，而1對1關係的外鍵設計就更有講究了，要根據實際場景來決定該在哪一個實體上放另外一者的外鍵，而後在使用的時候順着這個關聯方向來查詢。對於聚合的設計也是如此，須要事先在被聚合表上提早設計好用於聚合的外鍵，所以會有「事實表」、「維度表」的區分。數據的查詢規則，在數據庫表結構設定的時候就被肯定下來了。

對業務模式比較固定的場景而言，提早考慮好數據的使用方法並作針對性優化顯得合情合理，然而效能度量業務並不屬於此類。在度量領域裏，關聯、級聯、聚合都是十分常見的指標計算操做，因爲指標的做用在於發現潛藏於表面之下的問題，事先不該當提早規定只能從哪一類實體做爲關聯查詢的起點，或者必須以哪些維度作聚合觀察。

就圖數據庫的存儲模型來講，全部業務實體都是平等的，任何類型的關係都由實體間的關聯來表示。這就像是在SQL表設計時，不管是1對1仍是N對N關係，老是額外增長一張關聯表，卻無需顧慮多表JOIN帶來的性能影響。這樣一來，至關於將查詢和聚合方式的決策推遲到實際使用的時候再作，從而有效解耦建模和查詢時的相互制約，再也不須要爲優化查詢而返工改表。

此外，因爲關聯直接創建於實體之間，當刪除實體的時候，實體間的關聯也將自動斷開。這就像有垃圾回收機制的Java語言不用本身管理內存指針同樣。圖數據庫毫不會產生因爲關係修改時的不對稱清除而致使的數據不一致狀況。

那圖數據庫會不會有坑？確定有。不過在咱們目前有限的探索裏，遇到比較大的麻煩主要來自它不夠完善的周邊工具配套、阿里雲圖數據庫服務的某些配置限制，以及市場上稀缺具有相關技能的專業工程師。

專家經驗

在研發效能領域，度量的終極目標是DevOps文化所提倡的識別和消除系統性瓶頸。

經過各式各樣的過程數據，經驗豐富的項目經理和管理教練每每可以準確判斷出項目的潛在問題和交付風險。

在經濟學領域有個十分有趣的「古德哈特定律」，即「當決策者試圖以一個事物的客觀測度指標做爲指針來施行政策時，這一指標就不再能有效測度事物了」。

然而效能度量並非玄學，價值生產活動中的風險應當是有章可循的。古德哈特式的此消彼長現象其實來源於經濟領域的範圍太過寬廣，任何實用指標每每只能是局部度量的結果。效能透視鏡產品的提出者嵩華老師曾經分享過一種識別研發項目系統性風險的思路，即有的放矢的關注四種典型的全局現象：

• 流動阻滯
• 返工
• 落後的工程能力
• 技術債務

這幾種現象不太容易在局部進行遮掩，且在必定條件下可以相互疊加，成爲「爛項目」的標配。

透過整個研發過程當中的種種現象，找到反映這些全局性問題的蛛絲馬跡，不只能在必定程度上讓「專家經驗」產品化、標準化，也有助於將效能數據的使用方法從當前廣泛的「過後覆盤」式向以全局流動速率和質量做爲關注點的「風險管控」式發展，從而在可靠性和時效性兩個方面都獲得提高。

總結

數據不會騙人，但數據的呈現和解讀依然有很大的空間值得探索。現實事物複雜而多面，度量正是爲描述和對比這些具象事實而採起的抽象和量化措施，從某種意義上來講，度量的結果必定是片面的，反映部分事實。沒有銀彈，也沒有完美的效能度量。

對於企業研發效能的提高，開發者工具、效能方法理論、效能度量指標都是缺一不可、環環相扣的幾個重要板塊，相信隨着數據價值被愈來愈多的挖掘，咱們終將實現更有效的反饋和更精確的賦能，讓研發協做真正變得透明、簡單、高效。

最後

分享十條前人總結的經驗觀點。

• 任何指標一旦用於管控，就再也不可靠（古德哈特定律）。
• 測量的對象與人越近，越不可靠。
• 「凡可度量，皆可改造」是錯的。
• 變化趨勢的價值高於指標絕對值。
• 選擇適當的而非「標準的」指標，若發現指標沒用，果斷捨棄。
• 務必瞭解指標的獲取成本，明確指標意圖和針對的企業目標。
• 設計「北極星指標」，指標數量越多，邊際收益遞減。
• 不要將指標對全部人透明。
• 讓一線人員參與指標制定。
• 若是可能，合理縮短度量週期。