從3-5年前直至現在，度量的概念在IT領域持續火爆。隨著業務場景愈發熵增，產品線愈發復雜，大家都想做度量，也都在做度量，但度量的效果怎么樣，往往因組織而異。

其實度量本身并不是一個新的概念，自工業革命以來，我們就不斷在工業領域里面應用諸如燃盡圖、甘特圖和看板等度量工具，來幫助我們工業生產更具標準化、信息化和規?；?。

然而在IT領域、在軟件開發領域，如何更好地建設度量卻變成了令業界頭疼的命題。

今天，我將嘗試以效能作為一個系統工程出發，圍繞如何在一個組織里面去開展、去落地，以及獲得我們所預期的效果，來談一談度量這件事情，希望給關注度量領域的諸位帶來一定的參考價值。

*注：以下內容整理自：嘉為科技DevOps產品負責人 彭一寬 于 嘉為藍鯨2022研運一體創新峰會的精彩分享——《效能的持續度量、持續分析與持續落地》。

01. 我們度量什么

過往，我們在軟件工程內已經引入了很多在工業生產環境里面已經實踐過的度量方法論，諸如項目管理、精益管理等。但就大部分企業的落地效果而言，軟件開發領域的度量仍舊是個極具困難性的命題。

這是由于在IT行業里面想推動度量建設，就不可忽視IT領域本身的場景獨特性和業務復雜性：

• 場景獨特性是指，在IT軟件研發的過程中，每一個人他所做的事情實際上都是非標的，難以被標準化的；
• 業務復雜性是指，即使都是做IT，或者都是做軟件研發，不同的組織、不同的企業甚至不同的產品，它所面臨的業務復雜性甚至是研發流程都會存在不同。

以上2點就導致了，即使我們把目光聚焦在一個組織內部，也會發現難以找到一份統一的、一致性的、標準化的度量指標、度量體系以及度量框架。

而時至今日，IT行業的建設重點，也逐漸從對研發效能的度量轉移至對組織效能的度量，也就是從工程領域逐步演進至組織效能領域。

因此，以上想要說明的觀點就是，在IT領域的度量，局部優化并不等于全局優化，發現的問題也并不代表提升效能的解決方案。

當我們一個組織想要去做度量，甚至引入度量的體系和方法論的時候，我們常常會面對一個誤區就是：“我需要什么樣的指標，來解決我的度量問題？”

這里其實是存在矛盾點的，因為每個度量指標，它通常只是關注了問題的一個細小領域，而局部的一個問題往往并不是效能改進需要去處理的最大問題。此外，即使通過引入一組指標并從指標上發現了問題，也不代表組織就能很好地解決效能改進問題。

因此當我們嘗試去建設度量時，最先做的事情并不是去引入一組業界成熟的指標，然后盡快在組織內部推動落地。一旦這樣做，結果往往會適得其反。

相反，我們應該以系統工程的角度、以全局的角度出發，去尋找合適自己組織的度量方案：

• 從全局定義目標，到每個細分目標領域、每個業務場景的問題拆解。
• 從通過度量指標體系發現問題，到對問題的根因分析。
• 從知道原因是什么，再到我們找到對應的解決方案，最后進行持續地落地。

展開來講就是，對于在組織內部落地效能度量，可以先從定義組織級的目標，然后推演到具體業務場景里面可能存在的問題。

從發現問題，到有一組指標體系可以去支持分析出問題的根因，然后再通過專家體系、知識庫，甚至是一些大數據的處理方式，可以知道出現的問題，最適合什么樣的解決方案。

同時，在我們組織級的效能度量體系建立起來之后，在實際的運行過程中，我們還需要關注的是：從結果性指標發現的問題，如何落到縱向的每一個細分業務場景內，如何去定位到具體的問題。

02. 度量，做報時人還是造鐘人

報時人和造鐘人，其實是一個相對的概念。這兩種角色在任何一個組織內部，甚至在任何一個業務場景里面都是存在的。

報時人更多地是告訴我們出現了問題，但是造鐘人在我們度量場景里面其實是更重要的。因為造鐘人代表了我們的一套體系、一套方法論、一套規則。

在任何一個組織場景內落地的時候，報時人角色會告訴目標人群、度量消費者：“我們現在指標出問題了”、“我們問題點是什么”以及“我們應該怎么樣去解決”。

但是在我們做到這一步之前，更重要的是需要去建立度量的造鐘人體系，也就是要建立效能的組織級體系，這其中包括了方法論、指標體系、解決方案、后續一系列跟蹤閉環措施以及對應關鍵角色。

只有當我們建立好這樣一套完整的度量造鐘人體系以后，我們的度量產品才能做好一個高效的、有用的、對大家能夠起到效果的報時人角色。

現如今在業界，我們也已經能看到度量的很多指標集及指標。但無論這些指標來源于國內渠道還是國外研究機構，在做計劃引入前，我們都需要思考這些指標、指標集，以及它們背后的計算邏輯、計算口徑以及計算模型，是否真的適用于自身的業務場景。

在引入適合自身的指標體系后，度量體系建設的節奏、步驟以及推進方式，也都會極大地影響著度量的最終落地效果。

此外，對于一個想要去引入度量的組織來說，如果引入的指標落地困難，同時不能反映我們的具體問題，那即使引入了100個、甚至是1000個指標，很有可能都無法解決在效能提升和組織改進上遇到的難題。

相反，如果組織發現一個指標就能解決自身的問題，那說明，要么組織的業務場景太簡單，暫時還不需要復雜的指標體系來作體系化的呈現，要么就是組織還沒定義清楚度量需要去解決的問題。

所以，在我們聊指標之前，需要先清晰定義度量的目標，確定每個具體的細分場景里面需要去解決什么問題。

這也就是前面提及的：組織度量，不如先做造鐘人，再做報時人。

03. 效能度量的持續性vs持續性的效能度量

為什么要聊效能度量的持續性呢？

我們有些時候會希望效能度量體系落地之后，會有一個比較快的效果能夠反映出組織內部現在急需解決的問題，同時有一套方法論可以很好地閉環解決問題。

但是在實際的經驗和眾多的效能落地的場景中，我們會發現，效能度量能夠看到效果以及能夠有持續地改進的閉環，實際上是需要一個比較長期的過程。

這個過程是多久呢？短的話，可能是1-2年；長的話，3-5年都有可能。這取決于我們業務的復雜度和組織架構的復雜度。

這里希望去說明的是，其實度量這件事情，在效能提升的整個閉環中，它可能只占到很小的一部分，可能是1/4，甚至可能是更少。

因為度量本質上是不解決問題的，它實際上只提供了發現問題的線索。

只有當度量幫我們發現了線索，然后我們經過分析確定它是問題，經過后續一系列最佳實踐、一系列方法論的優化和落地，做到一個持續的閉環，組織才有可能真正地去做到效能的提升。

而提升組織級效能，才是去做效能提升這件事情的核心。

那現在我們來看效能度量，其實關注點已經從研發過程擴展到了整個組織的度量，甚至拓展到了組織的資源管理、人才管理和組織的商業成功，然后也會更多地去關注基礎設施、算力、人力資源和協作等成本。

同時，我們也需要更多的專家經驗和數據分析的能力結合，幫助組織從指標體系里面能夠更快地定義出根因，通過后面的專家經驗庫和數據分析，為根因提供最有效的解決方案。

那如何持續性地建設效能度量呢？

在嘉為藍鯨，我們希望通過一套產品化的方式，去幫企業解決度量建設的一系列問題，其中包括：

• 數據的聚合和治理
• 基于數據搭建多層模型
• 基于模型快速創建指標
• 將指標高效落地和實踐
• 靈活地實現校準和調優
• 規范敏捷高效地建立指標體系

在嘉為藍鯨的DevOps度量產品里面，我們將上面所提到的數據處理、數據模型、指標模型、指標的可視化素材、指標的體系化儀表展示、上層的產品化服務，以及一套幫助企業落地到具體業務場景解決實際問題的解決方案，有機整合形成一個完整的產品，幫助企業從最底層的數據治理，到最上面的解決方案呈現和落地，能夠在產品內實現高效地處理和閉環，同時也能保證良好的用戶體驗。

嘉為的DevOps度量產品，從組織級的數據處理能力，到組織級的效能模型建立能力，到IT研發流程中各個不同業務場景、各種不同領域的指標模型，再到上層的指標展示，以及一些針對組織特性的復雜指標的開發能力，都有非常好的支持。

經過我們的實踐，嘉為的DevOps度量產品可以著實有效地幫助組織建立一套有效的度量指標體系、度量模型體系，同時幫助用戶高效地去定位根因和解決問題，對于服務我們組織級的效能提升可以起到一個極大的促進作用。

今后，嘉為藍鯨也將持續發力，致力于通過多樣化的服務以及全場景的解決方案，為企業打造最有效的、最高效的效能度量實踐落地效果。