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

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

雖然不存在一個(gè)萬(wàn)能的衡量指標(biāo)，但仍然有一些可遵循的指南，以及一些可以避免的常見(jiàn)錯(cuò)誤。我們?cè)谂cJez Humble和Gene Kim共同撰寫(xiě)的新書(shū)“Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations”中概述了什么才是好的衡量指標(biāo)。這兩個(gè)規(guī)則非常簡(jiǎn)單，可以幫助我們理解我們?cè)谶M(jìn)行績(jī)效考量時(shí)所犯下的驚人錯(cuò)誤。

兩個(gè)簡(jiǎn)單的衡量指南

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

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

僅此而已。軟件開(kāi)發(fā)績(jī)效考量中的很多問(wèn)題通常是因?yàn)椴捎昧瞬蛔裱鲜鰞蓚€(gè)準(zhǔn)則的衡量指標(biāo)。衡量指標(biāo)形成了我們的激勵(lì)機(jī)制，繼而影響我們的行，所以我們需要使用正確的衡量指標(biāo)。

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

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

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

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

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

將速度作為生產(chǎn)力衡量指標(biāo)也違反了我們的指導(dǎo)原則，因?yàn)樗P(guān)注局部指標(biāo)而非全局指標(biāo)。為了優(yōu)化自己的速度，團(tuán)隊(duì)通常不會(huì)與其他團(tuán)隊(duì)合作。這通常會(huì)導(dǎo)致組織采用次優(yōu)的解決方案，因?yàn)樗麄儧](méi)有關(guān)注全局指標(biāo)。

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

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

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

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

軟件。”Accelerate“一書(shū)把我們?cè)谲浖_(kāi)發(fā)和交付方面使用的度量叫作軟件交付績(jī)效。它可以分為兩個(gè)類別，每個(gè)類別包含兩項(xiàng)指標(biāo)：

• 節(jié)奏:

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

  • 部署頻率：團(tuán)隊(duì)部署代碼的頻率。

• 穩(wěn)定性

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

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

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

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

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

這就是為什么我會(huì)喜歡Laine Campbell和Charity Majors在”Database Reliability Engineering“一書(shū)中提出的的指導(dǎo)原則。他們?cè)陉P(guān)于操作可視性的章節(jié)中指出了兩個(gè)關(guān)鍵問(wèn)題：你的服務(wù)是否在運(yùn)行？消費(fèi)者是否感到痛苦？他們非常巧妙地解釋說(shuō)，“端到端檢查是你工具庫(kù)中最強(qiáng)大的工具，因?yàn)樗鼈冏钅芊从衬愕目蛻趔w驗(yàn)”。

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

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

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



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

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

關(guān)于作者

Nicole?Forsgren?是一位IT影響力專家，指導(dǎo)領(lǐng)導(dǎo)者和技術(shù)專家如何釋放技術(shù)變革的潛力。她是DevOps、IT采用和影響力以及知識(shí)管理方面的顧問(wèn)、專家和研究員。她是DevOps Research and Assessment（DORA，與Gene Kim和Jez Humble合）的聯(lián)合創(chuàng)始人、首席執(zhí)行官兼首席科學(xué)家。她是ACM Queue編輯委員會(huì)成員，也是克萊姆森大學(xué)和佛羅里達(dá)國(guó)際大學(xué)的學(xué)術(shù)合作伙伴。Nicole擁有管理信息系統(tǒng)博士學(xué)位和會(huì)計(jì)碩士學(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ū)新聞，深度好文，歡迎訪問(wèn)公眾號(hào)文章匯總 http://www.csharpkit.com

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

總結(jié)

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

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