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

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

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

兩個簡單的衡量指南

使用專注于結(jié)果而不是輸出的衡量指標(biāo)。

使用針對全局或整個團隊成果而不是局部或個人成果而進行優(yōu)化的衡量指標(biāo)。

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

常見的不良衡量指標(biāo)

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

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

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

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

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

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

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

技術(shù)考量的正面例子

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

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

• 節(jié)奏:

  • 交付周期：從提交代碼到代碼在生產(chǎn)環(huán)境中成功運行所需的時間。

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

• 穩(wěn)定性

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

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

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

我們的研究發(fā)現(xiàn)，通過關(guān)注這些指標(biāo)可以提升組織績效，高績效企業(yè)可成倍實現(xiàn)盈利能力、生產(chǎn)力和市場份額，以及效率和客戶滿意度。

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

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

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

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

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



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

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

關(guān)于作者

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

參考

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

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

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

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。