歡迎來到通向卓越之路！我們或許都陷入了這樣的困境，我們努力成為卓越的企業，我們進行績效考量，并在此過程中找到正確的OKR、KPI或ABC。

但這可能是一件很困難的事情，特別是當我們所在的組織非常復雜并從技術幽靈（Ghosts of Technology Past）和管理幽靈（Ghosts of Management Past）中繼承了它們的衡量指標。

雖然不存在一個萬能的衡量指標，但仍然有一些可遵循的指南，以及一些可以避免的常見錯誤。我們在與Jez Humble和Gene Kim共同撰寫的新書“Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations”中概述了什么才是好的衡量指標。這兩個規則非常簡單，可以幫助我們理解我們在進行績效考量時所犯下的驚人錯誤。

兩個簡單的衡量指南

使用專注于結果而不是輸出的衡量指標。

使用針對全局或整個團隊成果而不是局部或個人成果而進行優化的衡量指標。

僅此而已。軟件開發績效考量中的很多問題通常是因為采用了不遵循上述兩個準則的衡量指標。衡量指標形成了我們的激勵機制，繼而影響我們的行，所以我們需要使用正確的衡量指標。

常見的不良衡量指標

大多數軟件績效考量都把注意力放在了生產力上，他們通常忽略上述的兩個指導原則。或許我有一點幸災樂禍的意思，不過，先讓我們從“不應該做什么”開始講：

代碼行數。一直以來，我們試圖使用代碼行數來衡量生產力。有些公司甚至要求開發人員記錄每周承諾的代碼行數（Apple Lisa團隊的管理層發現將代碼行數作為衡量生產力的指標是毫無意義的，這里是他們的故事）。如果1000行代和10行代碼都能解決同一個問題，我當然喜歡后者。獎勵開發人員編寫額外的代碼只會讓軟件變得更加臃腫，這會帶來更高的維護成本和變更成本。那么另一個極端呢？最小化代碼行數也不行。雖然有時候可以用一行代碼來完成一個任務，但這樣的代碼別人不好理解，所以很難維護。理想情況下，我們應該獎勵開發人員用最少的代碼來解決業務問題——如果我們可以在不編寫代碼或刪除代碼的情況下解決問題（或許是通過修改業務流程），那就更好了。

將代碼行數作為生產力衡量指標違反了我們的指導原則，因為這樣關注的是產出而非成果。它只衡量了人們做了什么（代碼行數）——通常是因為這樣做更容易——但通常忽略了真正的目標，因為目標難以表達和衡量。但目標不是我們應該真正關心的嗎？

速度。將速度作為衡量指標是源自敏捷運動——問題被分解為故事（story）點數，然后開發人員為故事點數分配相應的工作量。在截止工作時，完成的故事點數就是團隊的速度。但是，這只是團隊的容量規劃工具。使用速度作為生產力衡量指標有幾個不足。首先，速度是一種依賴于團隊的度量，具有相對性。團隊通常具有不同的背景，所以在團隊間進行速度比較并不合適。其次，當速度被用作生產力衡量標準時，團隊很可能會做出一些與事實不符的事情：他們會夸大他們的估算，并想盡可能多地完成故事點數，疏于與其他團隊合作（這可能會降低他們自己的速度并加快其他團隊的速度，反而會讓他們看起來很糟糕）。這不僅會破壞速度原本的意義，還會抑制團隊之間的協作。

將速度作為生產力衡量指標也違反了我們的指導原則，因為它更關注局部指標而非全局指標。為了優化自己的速度，團隊通常不會與其他團隊合作。這通常會導致組織采用次優的解決方案，因為他們沒有關注全局指標。

利用率。很多組織將利用率作為生產力的衡量指標。不幸的是，數學在這里不起作用。疲于處理待辦事項列表的人都應該能夠理解我將要描述的內容：一旦利用率超過一定水平，就沒有多余的容量用于容納計劃外的工作、計劃的變更或改進工作。這導致完成工作的時間變長。數學中的隊列理論告訴我們，當利用率接近100％時，交付周期就接近于無窮大——換句話說，一旦達到非常高的利用水平，團隊就需要指數級的時間來完成任務。由于交付周期——衡量完成工作的速度——不會與其他指標一樣存在某些弊端，因此我們可以通過管理利用率以一種相對經濟的方式做出平衡。

將利用率作為生產力衡量指標違反了我們的指導原則，因為它側重于產出而非結果。它還側重于個人而非局。這讓我們看起好像在壓榨員工，實際上，我們正把自己推向無法完成任何工作的境地。

技術考量的正面例子

事情還是有它好的一面。我們確實有一些很好的例子，可以用來說明如何衡量技術的生產力，我將在這里概述其中的一些。

軟件。”Accelerate“一書把我們在軟件開發和交付方面使用的度量叫作軟件交付績效。它可以分為兩個類別，每個類別包含兩項指標：

• 節奏:

  • 交付周期：從提交代碼到代碼在生產環境中成功運行所需的時間。

  • 部署頻率：團隊部署代碼的頻率。

• 穩定性

  • 恢復服務的時間：當服務發生服務事故（例如計劃外中斷、服務損害）時，恢復服務通常需要多長時間。

  • 變更失敗率：他們對主要應用程序或服務做出的變更有多少（百分比）會導致服務降級或隨后需要進行修復（例如導致服務受損或中斷，需要修補程序、回滾或補丁）。

這些衡量指標遵循我們的指導原則，因為它們既是面向結果的指標又是全局的指標——也就是說，它們專注于讓軟件對組織和客戶產生價值，而不是把注意力放在無法給整體目標帶來幫助的局部問題上。我們發現節奏和穩定性可以放在一起實現，高績效企業在兩個方面都表現良好。

我們的研究發現，通過關注這些指標可以提升組織績效，高績效企業可成倍實現盈利能力、生產力和市場份額，以及效率和客戶滿意度。

數據庫。另一個很好的例子是數據庫性能的考量。做到這一點其實不容易，因為我們經常會陷入細節之中：數據輸入、數據輸出、數據安全、我們的遙測是什么樣的、我們選擇什么樣的聚合等等。所有這些都要求我們對數據和數據庫有充分的了解。但是，如果我們想要考量數據庫性能，我們應該退后一步，看看全局的衡量標準和結果。

這就是為什么我會喜歡Laine Campbell和Charity Majors在”Database Reliability Engineering“一書中提出的的指導原則。他們在關于操作可視性的章節中指出了兩個關鍵問題：你的服務是否在運行？消費者是否感到痛苦？他們非常巧妙地解釋說，“端到端檢查是你工具庫中最強大的工具，因為它們最能反映你的客戶體驗”。

我喜歡他們給出的明確的指導原則并專注于這些指標，因為在這種情況下，你可以通過將數據庫和開發團隊聚集在一起來產生價值并確保交付高質量的軟件（應用程序和數據庫代碼）。順便說一下，專注于這些指標也有助于將數據庫納入到你的技術和產品的價值對話中。如果你的客戶感到痛苦，因為你的跨職能開發團隊在開發應用程序時忽略了你的數據庫團隊，他們只能手動部署數據庫變更，以便跟上應用程序的更新速度，那么這就到了一起坐下來解決問題的時候了。

質量。關注質量對于所有的組織來說都很重要，但這也是最難的指標之一。為什么？這是因為，用軟件質量專家Jerry Weinberg的話說，“質量對某些人來說就是價值”【1】。眾所周知，不同的組織有不同的環境，提供不同的職能和服務不同的人。

但是，“質量”——無論在什么樣的背景下——通常都是一種良好的生產力衡量標準，因為它側重于全局指標和結果。我們通常會考慮我們的最終用戶或客戶，或者我們產品的最終狀態。在我們的研究中，我們發現了一個質量指標，也就是是返工或計劃外工作所花時間的百分比，包括中斷或修復工作、緊急軟件部署和補丁、響應緊急審計文檔請求等等。我們發現，在新工作、計劃外工作或返工以及其他工作上花費的時間在高績效者和低績效者之間存在顯著差異。換句話說，高績效者要提升質量，因此必須花更少的時間來修復錯誤。看看下圖。



通過專注于這兩件事——全局指標和結果——你就可以很好地設計出可以幫助你取得成功的重要指標。

當你專注于全局成果（如質量）時，生產力就會隨之而來。其他一些人也發現了這一點。John Seddon說得很好：“矛盾的是，當管理者關注生產力時，很少能實現長期改善。而當他們關注質量時，生產力反而會不斷提升。“

關于作者

Nicole?Forsgren?是一位IT影響力專家，指導領導者和技術專家如何釋放技術變革的潛力。她是DevOps、IT采用和影響力以及知識管理方面的顧問、專家和研究員。她是DevOps Research and Assessment（DORA，與Gene Kim和Jez Humble合）的聯合創始人、首席執行官兼首席科學家。她是ACM Queue編輯委員會成員，也是克萊姆森大學和佛羅里達國際大學的學術合作伙伴。Nicole擁有管理信息系統博士學位和會計碩士學位，已發表多篇期刊論文，并獲得公共和私人研究資助（資助者包括NASA和NSF）。

參考

【1】Weinberg，Gerald M，質量軟件管理，第1卷：系統思考。紐約：多塞特郡出版社，1992年。

原文地址：http://www.infoq.com/cn/articles/measuring-tech-performance-wrong

.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的技术绩效考量：你们可能都做错了的全部內容，希望文章能夠幫你解決所遇到的問題。

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