??作者簡介：茹炳晟，騰訊T4級專家，騰訊研究院特約研究員，業界知名實戰派研發效能和軟件質量雙領域專家。“軟件研發效能度量規范”團體標準的核心編寫專家，Certified DevOps Enterprise Coach，年度IT圖書最具影響力作者，多本技術暢銷書作者，極客時間《軟件測試52講》作者，新書《軟件研發效能提升之美》也即將出版。同時擔任國內各大技術峰會的技術委員會成員，出品人和keynote演講嘉賓。

優秀的度量體系設計對目標會有很強的正向牽引作用，不恰當的度量體系往往會引發一場“腥風血雨”。

前段時間我寫了一篇文章“為什么都開始搞研發效能”引起了業界同行大量的討論與關注，今天想繼續聊聊研發效能提升過程中另一個敏感話題：“度量”。討論度量的目的不是爭論對錯，而是希望能夠引發大家對這一話題的深入思考。

度量失敗的案例

首先來看一些由于度量體系設計不當而引發“內卷”等不良行為的案例。

比如以“點擊量”來度量自媒體運營的成果，那么就有可能出現點擊量顯著提升，但是公眾號的關注人數卻下降的現象。原因就是使用“標題黨”等手段誘騙讀者打開鏈接，但是實際內容名不副實，幾次之后讀者就不會繼續關注該公眾號了。

再比如以“手術成功率”來考核醫生，醫生就會刻意回避疑難雜癥和重癥病人，醫生的“手術成功率”是提高了，但重癥病人卻得不到救治。

時代變了，很多事物底層邏輯都變了

今天的度量為什么容易失敗呢？正如我在之前那篇文章中提到的，面對變革，最重要的并不是方法和技術的升級，而應該是思維模式的升級。我們身處數字化的變革之中，需要將工業化時代科學管理的思維徹底轉為數字經濟時代的全新思維。

對于軟件研發效能的度量，我們絕大多數時候還在用工業化時代形成的管理理念來試圖改進數字經濟下的研發模式。但時代變了，很多事物底層邏輯都已經變了，工業化時代形成的科學管理理念在數字經濟的今天是否還依然適用？值得深思。

本文將站在軟件研發效能的視角，來探討數字經濟時代下研發效能度量中幾個必須要回答的問題：

• 研發效能到底要不要度量？
• 研發效能到底能不能度量？
• 研發效能到底如何來度量？
• 研發效能的度量指標如何來選取？
• 研發效能度量的常見誤區有哪些？

研發效能到底要不要度量？

要。這個問題的答案不容質疑。

現代管理學之父 Peter Drucker 說過，“沒有度量就沒有改進”，這一底層邏輯自始至終都沒有變過，只是工業化時代的度量和數字經濟時代的度量在理念和方法上會有很多不同的地方。

度量對于研發流程改進的意義非常明確。?工業化時代的實體產品研發與生產，其中的風險是相對明顯的，比較容易找到防范的方法，也分得清相關的責任。但是數字經濟時代的軟件產品研發（已經沒有了生產），是通過越來越多工程師的數字化協作來推進的。參與研發的人越多，人與人之間的溝通成本越高，產生隨機偏差的概率也會越大，再加上軟件研發過程本身的可視化程度很低，風險的可見性就容易被各個環節掩蓋，但它最終會在看不見的地方積累起來。如果沒有適當的度量體系去顯性化這些風險，結果可想而知，更不用談什么持續改進和治理了。

度量對于人的公平性訴求*也是必須的。?“我雖然沒有功勞，但是我也有苦勞。” 大部分人可能只關注自己的付出，但并不關心付出所獲得的實際效果。作為管理者應該為“苦勞鼓掌，為功勞付錢”。而功勞和苦勞的體現也需要借助客觀的度量數據來體現，否則團隊中的成員會逐漸陷入碌碌無為的窘境。

研發效能到底能不能度量？

明確了研發效能必須度量之后，我們再來看看一個更實際的問題：研發效能到底能不能度量？“要不要”和“能不能”是兩個層面的問題，“要”不表示“能”，就像“我要賺錢”和“我能賺錢”是截然不同的兩個問題一樣。

關于這個問題，業界有兩派截然不同的觀點，一派是以現代管理學之父 Peter Drucker 的理論為依據，主張研發效能能夠度量的；另一派是以世界級軟件開發大師 Martin Fowler 為代表，主張研發效能不可度量的。

在這個問題上，我的觀點比較中庸，我認為能夠度量，但是沒有完美的度量。原因有以下幾點：

度量本身的片面性無法避免

現實事物復雜而多面，度量正是為描述和對比這些具象事實而采取的抽象和量化措施，從某種意義上來說，度量的結果一定是片面的，只能反映部分事實。

管理者往往會把目標拆解為可度量的指標。但是，目標和指標常常并不是簡單的全局與局部的關系。目標的拆解過程看起來很順暢，是那么地理所當然，但是當把拆解完的指標合并起來的的時候，結果往往讓人哭笑不得。

有一個笑話說的是，“你問人工智能，我要找一個女朋友，像安·海瑟薇一樣的大眼睛，像朱莉婭·羅伯茨一樣的大嘴，喜愛運動，陸上運動、水上運動都會。人工智能就根據這幾個指標給出了母青蛙的答案”。所以，指標和目標常常并不是充分必要的關系。

度量過程容易陷入局部思維

指標是為了實現目標的，但是在實踐過程中，指標很多時候卻是與目標為敵的。

管理者常常把目標拆解為指標，時間久了以后，他就只知道指標，而忘了背后更重要的目標。如果目標是林，那么指標就是木，時間久了就是只見樹木，不見森林。這個時候忘記了目標是什么的管理者就會變得非常短視。那些不懂數據的人很糟糕，而最最糟糕的人是那些只看數字的人。

在福特汽車的發展史上，有一段至暗時期。那些實踐經驗豐富，但是沒有上過商學院的的老一輩管理層被干掉，取而代之的名校管理背景的數據分析師，公司試圖通過精細化的數字管理來實現業務的增長。由于這些數據分析師并不熟悉業務，所以就只能看度量數據，越是不懂業務就越依賴度量數據來做決策，最后使整個公司陷入了泥潭。

軟件研發也有類似的尷尬，為了更好地代碼質量，所以就制定了嚴格的代碼測試覆蓋率要求。時間一久，大家都機械性的追求這個指標，而忘記了當時設立這個指標的初衷，于是就出現了高覆蓋率的大量單元測試中沒有斷言這樣尷尬的局面。

度量數據的解讀具有很強的誤導性

度量數據本身不會騙人，但數據的呈現和解讀卻有很大的空間可以利用。很多時候，同樣的數據，通過不同的解讀會引導出截然不同的結果，這點很容易被人為利用來達成各自的目的。

舉個例子，有研究人員問接受調查者一個問題：假如你得了絕癥，有款新藥可以治愈，但是會有風險，20%的服用者可能因此而喪命，你吃嗎？大多數人會選擇不吃。但是如果反過來問：假如你得了絕癥，有款新藥可治愈 80%的患者，但此外的人會死，你吃嗎？絕大多數人會選擇吃。實際上這兩個問題的基本數據是一樣的，但是得到的答案卻相反。原因很簡單，在前面的問題中，強調的是“失去”，在后面的問題中，強調的是“獲得”。人的天性會更喜歡“獲得”，而不是“失去”。

研發效能領域也有很多類似的案例，相同的數據到了不同的人的嘴里就有了截然不同的解讀，由此做出的決策也會不同。

綜上所述，我認為研發效能到底能不能度量是要基于場景的，脫離了場景去談能不能度量沒有太大意義。就像沒有什么東西本質上就是臟的，是放錯了位置的東西才是臟的。飯菜，在碗里就是干凈的，潑到了衣服上才是臟的。泥土，在花園里就是干凈的，抖落到了床上就是臟的。

研發效能到底如何度量？

那么研發效能到底如何度量，以下是我的一些想法。

要傾聽管理者的度量訴求，但是不要照著做

在汽車還沒有被發明的時代，你問馬車用戶，你要一個什么樣的交通工具，很有可能得到的答案是“更快的馬車”，如果你按著這個思路去做的話，就會陷入研究馬蹄設計、馬飼料優化的誤區，就不會有汽車的發明了。很多時候用戶告訴你的需求往往都只是自以為是的“解決方案”。

當管理者告訴你我要這些度量數據、我要那些度量數據的時候，你不應該一頭扎進數據獲取的細節中，完全按管理者告訴你他想要的去做，而是應該從本質上去理解管理者想要看這些數據背后真正的動機，管理者通過這些數據到底是想解決什么樣的問題。要理解管理者的深層次需求，這才是問題的本質。只有這樣才有可能在此基礎上給出相對完美的度量方案。

度量應該是有層級結構的

高層管理者、中層管理者和一線工程師關心的度量維度肯定是不一樣的。不要試圖去提供一個看似大而全的度量體系，當你的度量體系能服務于所有人的時候，恰恰意味著它什么都不能。

比較理想的做法可以參考 OKR 的實踐。先由高層管理者制定度量體系的總目標，然后中層管理者分解成可執行可量化的指標，最后再由一線工程師分解成工程維度的的指標。各個層級只關心當前層級的指標以及上一層級的目標，不應該出現高層過多、過細地關注下層指標。

度量的設計目標是要能夠引導出正確的行為

度量從來不是目的，而應該是實現目的的手段。度量是為目的服務的，所以好的度量設計一定對目的有正向牽引的作用，如果度量對目標的負向牽引大于正向牽引的話，這樣的度量本質上就是失敗的。

舉個例子，現在國內很多軟件企業都使用 Sonar 來實現代碼靜態質量的把控，為了推進 Sonar 在團隊內的普及，不少企業會用“Sonar 項目接入率”這樣的指標，也就是有多少百分比的項目已經在持續集成 CI 中啟用了 Sonar，來衡量靜態代碼檢查的普及率。這個指標看似中肯，實際上對于實現最終目標的牽引力是比較有限的。使用 Sonar 的最終目標是提升代碼的質量，只是接入 Sonar 并不能實際改善代碼的質量，而且還容易陷入為了接入而接入的指標競賽。理解了這層邏輯，你會發現使用“Sonar 嚴重問題的平均修復時長”和“Sonar 問題的增長趨勢”其實更有實踐指導意義。

所以，一個好的度量，一定要為解決本質問題服務，并且要能夠引導出正確的行為。

切記不要基于“比較思維”而采用“追星式”的度量

我們看到一個人獲得了成功，就會立刻認為他過去所有的行為都是那么地有道理。我們看到一公司獲得了成功，就會覺得他們采取的策略和工程實踐是多么有效。這正是“比較思維”的可怕之處。實際上，沒有哪家企業是通過盯住競爭對手而獲得成功的。

OKR 在 Google 的成功應用使得很多公司對此實踐趨之若鶩，但是通過使用 OKR 取得成功的企業又有多少？這種“追星式”的度量只能讓你陷入更深的內卷。

對于研發效能的度量體系，切記不要盲目生搬硬套“大廠”所謂的最佳實踐，也不要拿自己的度量實踐去和大廠的比較，你們的上下文不同、組織生態不同，這藥給大廠吃可以治病，給你吃可能致命。

度量不要廣撒網，而應該精準捕撈

不要在沒有任何明確改進目標的前提下開展大規模的度量，因為度量是有成本的，而且這個成本還不低。很多大型組織往往會花大成本去建立研發效能度量數據中臺，指望通過研效大數據的分析來獲取改進點。這種“廣撒網”的策略雖然看似有效，實則收效甚微。事實證明，度量數據中臺的建設成本往往會大幅度高于實際取得的效果。

比較理想的做法應該是通過對研發過程的深度洞察，發現有待改定的點，然后尋找能夠證實自己觀點的度量集合并采取相應的措施，最后再通過度量數據來證實措施的實際價值，這種“精準捕撈”的策略往往更具實用價值。

研發效能的度量指標如何選取？

這個問題太大了，很難展開。但是這里想通過兩個典型案例來解釋指標選取的問題。

很多時候，當我們無法解釋什么是正確的時候，我們可以通過逆向思維嘗試著看看什么是錯誤的，以此來給我們一些啟發。

“千行代碼缺陷率”引發的血案

千行代碼缺陷率是被大家廣泛熟知并且不少企業正在使用的一個代碼質量相關的度量指標，但是這個指標真的能客觀反應代碼的質量嗎？這個指標真的是一個合格的指標嗎？這里我不直接給出結論，而是帶著大家一起來分析一下，讓你自己得出結論。

上面的圖給出了千行代碼缺陷率的定義，即每千行代碼的缺陷數量。假定一般情況下，團隊平均的千行代碼缺陷率大概是在 5-10 的范圍。

現在我們有這么三個工程師。

• 工程師 A 的技術能力比較差，實現需求 X 用了 20000 行代碼，同時引入了 158 個缺陷，由此計算出工程師 A 的千行代碼缺陷率=7.9，這個值正好在 5-10 這個平均范圍內，所以從千行代碼缺陷率來看，工程師 A 屬于正常水平，并不會引起大家的注意，屬于無功也無過。

• 工程師 B 是一個技術大牛，實現相同的需求 X 只用了 3000 行代碼，但是也引入了 10 個缺陷，由此計算出工程師 B 的千行代碼缺陷率=3.3，這個值明顯低于 5-10 這個平均范圍，你以為工程師 B 會因此受到表揚？大錯特錯，工程師 B 很有可能會被判定為沒有進行充分的測試，被責令加強測試。

• 工程師 C 是一個有技術追求、努力想讓自己成為技術大牛的人，他實現相同的需求 X 用了 4000 行代碼，但是由于目前的技術能力有限，所以引入了 58 個缺陷，由此計算出工程師 C 的千行代碼缺陷率=14.5，這個值明顯高于 5-10 這個平均范圍，所以毫無疑問，工程師 C 必然會遭受批評，被責令改進代碼質量。

由此看出，基于千行代碼缺陷率對這三個工程師的評價顯然是有失公允的。

更糟糕的是，之后的需求有可能會發變化。這個時候工程師 B 和工程師 C 的代碼具有較好的可維護性，可以方便地變更，所以可以很快完成變更任務，并且基本不會引入新缺陷。而工程師 A 的代碼由于缺乏設計模式的支持，大量代碼需要重寫，同時還會引入了很多新缺陷。但是由于代碼量夠大，工程師 A 的千行代碼缺陷率依舊在平均范圍內。所以在現有的度量體系下，工程師 A 依然無功也無過，而工程師 B 和工程師 C 則繼續得到差評，因為他們的工作看起來太簡單了，明顯工作量“不飽滿”。

由此可見，千行代碼缺陷率的度量體系是失敗的，其所傳達的價值觀與我們所期望的背道而馳。從工程師 B 的遭遇可以看出“我們不相信你能夠寫出高質量的代碼”，從工程師 C 的遭遇可以看出“我們不鼓勵技術提升階段的陣痛”，而從工程師 A 那邊我們看到的是“我們歡迎那些平庸的程序員”，這些都直接違背了我們實際的價值觀。

上述的分析還是在沒有人為“粉刷”指標的前提下進行的，在實際工作中，工程師往往會采取稀釋代碼的方式來降低千行代碼缺陷率，而不是實際去減少缺陷數量。因為與減少缺陷數量相比，直接稀釋代碼（比如：一行寫成多行、括弧必須換行、多寫注釋、多加空行等）的難度更低，而且更可控。所以我一直說，永遠不要低估工程師面對度量指標時的“創造性”。

此時度量體系的設計者可能很快會意識到工程師們的小手段，所以全新的“開發當量缺陷率”指標應運而生，這個指標用開發當量去替代千行代碼數。開發當量是對開發工作量的一種合理估計，可以理解為源代碼編譯成的抽象語法樹 AST 的復雜度。與代碼行數這類淺層統計相比，開發當量不易受到編程習慣或特定行為的干擾（比如換行、注釋等），這樣一來，想通過稀釋代碼來降低代碼缺陷率的路就走不通了。

乍一看，用開發當量似乎可以解決問題，但是當你深入思考后會發現，用開發當量可能會讓情況更糟糕。因為工程師依舊可以通過人為增加開發當量（比如減少封裝等）來降低代碼缺陷率，只不過增加開發當量的難度比直接稀釋代碼要大，這將直接導致“粉刷”指標的難度變大，進而陷入“算法對抗”的窘境。最后的結果是工程師為了降低代碼缺陷率，在錯誤的地方花費了更多時間和精力，而最終代碼質量依舊沒有任何改善。

那么到底是什么地方出了問題呢？你靜下心來仔細想一下，代碼行數和代碼質量到底有沒有關系？如果有關系，兩者之間到底是因果關系還是僅僅是相關性？這時你可能會恍然大悟，原來代碼行數和代碼質量之間僅僅是相關性，根本不是因果性，代碼質量不會因為代碼行數變多而變差，所以試圖用千行代碼缺陷率來對代碼質量進行度量的大前提根本就是不成立的，從源頭上就錯了。這就好像森林火災率和冰淇淋銷量之間就是相關性，這個相關性是由天熱而發生關聯的，兩者之間不存在任何因果性。換言之，想通過降低冰淇淋銷量來降低森林火災率是完全行不通的。迷信千行代碼缺陷率就好像扔磚頭還要看風向一樣自欺欺人。

那么正確的做法是什么呢？我們知道，只要缺陷可以很快被修復，那么有缺陷就并不可怕，缺陷多也不可怕，我們怕的是每個缺陷的修復難度都很高，一個缺陷幾天都修不了，我們更怕缺陷修復對原有代碼的改動會“傷筋動骨”。

所以我們完全可以采用平均缺陷修復時間(Mean Time To Repair)?來衡量代碼的質量。平均缺陷修復時間能夠更好地反映代碼本身的質量狀況，以及團隊的技術成熟度。往往平均修復時間較長的代碼都是復雜度高、耦合度高的代碼。而平均修復時間短的代碼則是結構相對清晰、命名規范、容易理解、擴展和變更的代碼。相比千行代碼缺陷率，平均缺陷修復時間對代碼質量會有更強的正向牽引作用。

敏捷模式下工作量估算的是是非非

在敏捷模式下的工作量度量，到底應該用“故事點”作為單位呢，還是應該用“人天”作為單位？很多人可能覺得都可以，他們認為這個主要還是看團隊的使用習慣。其實這個答案是完全錯誤的，正確的做法是用“故事點”，而不應該用“人天”。

要理解其中的緣由其實并不復雜，因為工作量是量的概念，而人天是時間的概念。

要搬一千塊磚，這一千塊磚就是工作量的概念。搬得快，它是一千塊磚，搬得慢，還是一千塊磚。工作量本身的大小和時間是沒有關系的。

工作量與時間產生關系是通過速率這個概念。同樣搬一千塊磚，你每分鐘搬 10 塊，100 分鐘搬完；我每分鐘只能搬 5 塊，那就 200 分鐘搬完。所以，只有當速率確定了，才能把工作量換算成時間。

問題是當我們在計劃迭代的時候，我們是沒有辦法明確知道速率值的，速率會隨著很多因素動態變化，并不是一定不變量。比如工程師的熟練程度、是否之前處理過同類型的問題、需要參加會議的多少、家里的各種瑣事都會對速率產生直接影響。因此我們無法將代表工作量的“故事點”和代表時間的“人天”等同起來。

為什么很多團隊依然會直接使用時間來估算工作量，并認為“故事點”和“人天”沒區別呢？因為在他們的觀念中，下意識把速率認為是常量，所以工作量與時間就可以線性換算，所以這個想當然的假設，背后其實是一個巨大的邏輯錯誤。

研發效能度量的常見誤區有哪些？

研發效能度量的過程往往是對軟件研發全流程進行抽象和簡化的過程，但簡化就會帶來失真和扭曲，那些具有感性色彩、意味深長、需要反復斟酌的地方消失了，只剩下言之鑿鑿的度量指標，稍有不慎，就會讓我們產生手握真理的幻覺，關于這部分內容我把其總結成了“研發效能度量十宗罪”，由于篇幅限制我們這里只討論前五項。

使用容易獲得的量化指標

度量數據收集的難易程度不同，容易收集的數據往往實用價值低（比如代碼行），難收集的數據往往度量價值更高（比如：產品用戶價值，NPS 等）。我們通常有一種天然傾向，就是把焦點放在最容易量化的目標上，把它作為解決復雜問題的抓手。用不了多久，人們就只重視那些可量化的目標，而忽略那些不可量化的目標。

首先，那些容易量化的次要目標（比如：代碼行人天），會逐漸排擠掉那些難以量化但非常重要的目標（比如：代碼影響力）。

其次，容易量化的目標（比如：個人工作時長）往往是局部目標，而難以量化的目標（比如：項目價值交付）往往是整體目標。局部目標更容易達成，時間久了以后，局部目標就會排擠掉整體目標。

最后，容易量化的目標（比如：缺陷數量）往往是短期目標，而難以量化的目標（比如：長期質量）往往是長期目標。短期目標往往關注當下的績效，屬于“救火”的范疇，而長期目標則屬于“未雨綢繆”的范疇，人的短視很容易讓短期目標排擠掉長期目標。

試圖通過單一維度進行度量

試圖通過單一維度去做度量也是非常不可取的，因為事物往往具有多面性，事物本身的復雜度就決定了度量也必須是全方位，多維度的。因此，我們更應該建立度量的雷達圖，從事物的多個維度來進行度量。雷達圖中度量矩陣的設計要做讓各個度量指標之間有相互牽制的作用，比如當你人為“粉刷”其中某個度量值的時候，其他的度量值將會“出賣”你。圖中的度量雷達圖就是一個很好的例子。

• 當你的“缺陷數量”低的時候，不能直接得出你寫代碼質量高的結論，而要結合“完成的需求點數”來做綜合判斷。

• 當你的“加班時長”長的時候，不能直接得出你是高績效員工的結論，而要結合“完成的需求點數”、“代碼影響力”和“缺陷數量”來做綜合判斷。

由此可見，如果你想同時人為優化所有指標，那幾乎是不可能的，這正是度量雷達圖的魅力所在。

研發過程數據采集需要依賴人工錄入

在企業中，度量數據的獲取一定要實現自動化，如果你的度量數據都依賴于工程師的手工錄入來獲取，一方面工程師會對此種工作模式十分反感，另一方面會讓后續的度量分析完全失去意義，因為人工錄入的數據或多或少已經存在了很多失真，而且很多數據的錄入時間是有很大參考價值的，如果數據不是實時獲取，而是人工填充的，那么數據本身就失去了度量的意義。

在 Scrum 團隊，有個很好的例子可以說明這點。燃盡圖是用來反應迭代任務完成情況的全局視圖，理想中的燃盡圖應該是下圖中的上半部分，但是實際項目中的燃盡圖往往看起來更像下圖中的下半部分。原因很簡單，因為工程師不會實時去更新任務的完成狀態，而是等到迭代快要結束的時候，批量集中地人工更新任務狀態，所以燃盡圖就成為了這種到了最后一天斷崖式下降的樣子。試想一下，這樣的過程度量是不是就完全失去了原本的意義，而且這些獲取的數據也不能用來做進一步的分析，因為時間維度嚴重失真了。

要解決這一問題，必須讓研發過程數據采集通過工具平臺自動完成，而不能依賴人工錄入，騰訊的“研發效能雙流模型”就提供了很好的思路。比如在雙流模型的支持下，當 feature 分支成功合并到 master 的時候，就會主動觸發需求狀態的流轉，從原來的“開發中”轉到“待測試”，可以完美實現了“需求價值流”和“研發工程流”兩者之間的聯動。

將度量與個人 KPI 綁定

關于度量有一句名言是這么說的，你度量什么，就會得到什么，而且往往是以你所不期待的方式得到的。我一直說一句話，當你把度量變成了個人考核的時候，永遠不要低估人們在追求指標方面“創造性”，當然這個創造性是打了引號的。所以我一直反對將度量與個人 KPI 綁定，因為度量本身很難做到客觀和公正，如果直接作用于個人，而且強綁定個人績效可能反而會適得其反，容易導致工程師純粹面向指標去開展工作，而不是面向結果。

雖說不建議將度量和個人績效綁定，但是將度量和團隊績效綁定還是很有必要的，通過度量能夠反饋團隊宏觀層面問題，進而可以采取有效措施去改進。要注意的是，團隊度量依然無法做到客觀和公正，但是這些不夠客觀和不夠公正的因素可以在團隊 lead 層面進行補償和調整。然后在團隊內部消化掉。

盲目建立度量數據中臺

不要在沒有任何明確改進目標的前提下開展大規模的度量，因為度量是有成本的，而且這個成本還不低。很多大型組織往往會花大成本去建立研發效能度量數據中臺，指望通過研效大數據的分析來獲取改進點。這種“廣撒網”的策略雖然看似有效，實則收效甚微。事實證明，度量數據中臺的建設成本往往會大幅度高于實際取得的效果。

比較理想的做法應該是通過對研發過程的深度洞察，發現有待改定的點，然后尋找能夠證實自己觀點的度量集合并采取相應的措施，最后再通過度量數據來證實措施的實際價值，這種“精準捕撈”的策略往往更具實用價值。

好了，不知不覺已經寫了萬字長文，如果你還意猶未盡，可以關注我的新書《軟件研

總結

以上是生活随笔為你收集整理的来自腾讯相当好的文章：研发效能度量实践指南的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。