為什麼說開發者指標是不可靠的?

為什麼說開發者指標是不可靠的?

作者 | Denis Stebunov

譯者 | 王者

策劃 | 萬佳

如果你曾經管理過軟體專案,你可能會問自己:我們團隊如何才能更快地前進?現在前進的速度有多快?

面對這類問題,我們傾向於依賴指標。畢竟,我們在開發軟體時經常並且已經成功地使用了指標。我們有效能、生產負載和執行時間指標,還有一些基於使用者行為的指標,如轉化率和留存率。這些指標不僅提供了可見性,更重要的是,它們創造了一個反饋迴圈。為了對一些東西加以改進,我們可以做出一個變更,並用指標來衡量改進的程度。開發者的智慧告訴我們,每一個軟體效能最佳化都必須從指標開始。

既然指標如此有用,我們就不能把它們應用到軟體開發速度中嗎?既然更好的開發過程應該要給開發輸出結果帶來改進,那麼輸出結果指標應該就可以度量開發過程是否真正得到改進。那麼,我們可以使用哪些指標呢?

在這方面,我們沒有什麼好的指標

開發速度是指單位時間內產出的工作量,所以我們需要同時衡量輸出和時間。衡量時間很簡單,但工作量如何衡量呢?工作量的衡量跟軟體本身一樣古老。多年來,每當我們決定用一個指標來衡量工作產出時,一些意想不到的事情就會出現。考慮以下這些例子:

程式碼行數——這可能是最古老的一種指標,但如今幾乎沒有人把它當回事。把程式碼行數作為衡量指標只會讓程式碼變得臃腫,而且開發者只會專注於完成簡單的任務;

提交次數——這樣會鼓勵開發者將程式碼提交分解為多個部分。同樣,開發者會更關注簡單的任務,避免去解決複雜的問題;

完成任務的數量——這樣會導致任務被分割成更小的子任務。每一個問題,即使是小問題,都是作為任務提交的。這也會促使你走捷徑,以最快的速度完成任務;

bug 的數量或 bug 的百分比——這不是工作輸出指標,而是工作質量指標。這樣會阻止開發者做出變更,並讓他們不願意報告自己發現的 bug;

工時或故事點數——當估算變成衡量團隊表現的手段,那麼很容易就可以猜到接下來會發生什麼——誇大的估算;

……

開發者很聰明,他們擅長解決複雜的問題。對於指定的指標,他們都會找到最簡單的改進方法,但很可能與工作質量或期望的專案結果不相關。但這並不意味著開發者就一定會這麼做,我認為這取決於具體環境以及動機有多強。但有一件事是確定的——開發者將意識到他們的生產力衡量方式與重要的事情是相脫節的。這不僅令人感到沮喪,也會讓他們在做真正的工作時分心。

為什麼會這樣?

為什麼指標對於軟體產品如此有效,而對於開發者的輸出卻不適用呢?這是開發者的陰謀嗎?實際上,如果你觀察一下軟體開發之外的領域,你會發現更多例子,它們可以說明指標適用於哪些方面以及不適用於哪些方面。

指標適用的地方:製造和銷售。以杯子的製造和銷售為例。你可以測量產量(比如每單位時間生產的杯子數量)和質量(無法透過質檢的不合格杯子的百分比)。在銷售方面,你可以衡量銷售額和利潤率。這些指標對管理來說都非常有用。例如,製造部門的目標可以是提高成功透過質檢的杯子的百分比,同時保持較低的單位成本。銷售主管的目標可以是增加銷量或提高利潤率。這些指標的改進對業務是有好處的,因此我們也可以將其作為相應部門效率的衡量標準。

指標不適用的地方:科學產出。科學家們透過論文來發布他們的研究結果。現在科學界也有了一些衡量工作產出和質量的指標:發表論文的數量、被引用的次數、研究結果的統計學顯著性。我們可以說發表 10 篇論文的科學家創造的價值是發表 5 篇論文的科學家的兩倍嗎?這是不太可能的,因為研究成果的價值是有差別的。即使不使用這些數字,通常也很難說哪項研究成果更有價值。因為論文數量和引文次數造假在科學界是一個眾所周知的問題,它們並不被認為是衡量工作效率的可靠指標。統計學顯著性也有問題——P 值篡改(p-hacking)是一個廣泛存在的問題。

兩個關鍵標準

在任何情況下,有效的指標都應該符合兩個重要的標準:

它們與價值直接相關;

這些價值具有一致性,即可以用可互換的單位來表示,並具有可數的數量。

讓我們來看看上面的例子:

製造和銷售的指標符合這兩個標準。在杯子的例子中,價值用杯子來表示。因為是大批次生產,所以杯子是一樣的。在銷售的例子中,價值是以美元來衡量的。業務目標是賺錢,所以錢與業務價值具有直接的關係。因為一美元可以等價其他任何一樣東西,所以基於金錢的指標可以衡量恆定的價值。

科學產出的指標不符合這兩個標準。我們找不到一個可以直接衡量科學研究結果價值的指標。我們只有間接的指標,比如論文和引用的數量,但這些都可能被篡改。無論如何,這些指標也不具有一致性,因為所有出版物都不是由可互換單位組成的。

開發者指標不符合這兩個標準

我們需要用什麼來衡量開發者的輸出?程式碼行數、提交次數、完成任務的數量、工時、故事點數……如果將這些指標與上述兩個關鍵標準對照一下,你會發現:

它們都與價值沒有直接關係。我們不會向客戶交付程式碼行數、工時或故事點數。他們不關心我們提交了多少次程式碼或完成了多少任務;

所有這些衡量結果都不具有一致性。這一次提交併不等於另一次提交,這一行程式碼的價值與另一行程式碼的價值不一樣,所有的任務也都是不一樣的,工時和故事點數都是估算出來的,具有不準確性。

毫無疑問,這些指標都不能很好地發揮作用。

為什麼我們沒有與價值直接相關的開發者指標?同樣的,我們也沒有給科學家用的指標。開發者就像科學家一樣,總是在創造新的東西。他們不會一遍又一遍地寫同樣的程式碼——那樣沒有意義。程式碼可以被重用——可以將它們提取到模組或庫中,或者直接複製貼上。每個開發者的工作都是獨一無二的。即使他們解決了相似的問題,也都是在不同的環境中或使用新的方法解決的。

是否有新的研究發現?

當然,現在沒有人會真的用程式碼行數來衡量開發者的輸出,但應該會有一些新的研究發現,對吧?

2018 年出版的“Accelerate”一書呈現了對 2000 個不同規模的組織進行研究的結果。研究的目標是確定哪些指標可以用來區分高績效和低績效。他們的發現如下所示:

我們可以看到四個指標。接下來讓我們來看看這些指標是如何與價值聯絡在一起的,以及它們是否具有一致性:

部署頻率——我可以理解為什麼它會出現在這裡。你越頻繁地交付,交付過程就越可靠。高效的團隊往往更頻繁地釋出程式碼。然而,相關性並不一定意味著因果關係。部署頻率與客戶價值並沒有直接的關係。人們想要一個能夠滿足他們需求的產品,而不是一個儘可能頻繁變化的產品。這個指標也不具備一致性,因為一個變更並不等於另一個變更。

交付時間——滿足客戶請求的時間。這一點與價值更加靠近一些,但它不具備一致性,因為客戶請求是不一樣的,有些可能很簡單,有些可能極具挑戰性。

平均恢復時間(MTTR)——發生故障後恢復的速度。當軟體出現故障時,客戶會不高興,所以這個指標與價值是有關係的,但也有不好的地方。首先,它沒有考慮到故障頻率。如果軟體經常出現故障並迅速恢復,儘管指標看起來不錯,但客戶仍然會不滿意。第二,它不具備一致性,因為各種故障也是不一樣的。如果是整個系統出現故障,那就很嚴重了。如果只是一個小功能不能正常工作,大多數客戶可能不會注意到。

變更故障率——導致故障變更的百分比。如果是使用者自己安裝的更新,那麼這個指標確實與價值有關。如果使用者在安裝更新時體驗不佳,他們就會害怕安裝後續的更新。對於 SaaS 產品,這種關係就不那麼直接了,因為客戶不太關心服務為什麼出現故障,可能是由於變更,可能是你的一個供應商出了問題,可能是服務無法處理負載,或者是服務受到了攻擊。不管是什麼原因,如果服務不正常,顧客都會不高興。這個指標也不具備一致性,因為一個變更不等於另一個變更。有些變更是微不足道的,有些則可能很重要。

底線——所有四個指標都不具備一致性,而且並不總是與價值有直接關係。如果儘可能頻繁地釋出一些不重要的變更,那麼除交付時間之外,其他指標看起來都不錯。

至於交付時間,即使我們忽略了它不具備一致性的事實,將這個指標作為目標會導致我們優先考慮客戶的簡單請求,卻忽略了客戶沒有說出的請求。這通常包括重構、測試和所有其他客戶沒有考慮到的改進。

這就是為什麼我不推薦使用這些指標作為開發目標。

或許我們可以找到更好的指標?

你可能會說:等等,雖然我們還沒有找到好的指標,但這並不意味著它們不存在,人們很聰明,他們會找到更好的方法。但我恐怕他們是找不到的。我們找不到好的開發者指標是有根本原因的。好的指標應該滿足兩個關鍵標準:

它們與價值直接相關;

它們具有一致性,即基於某些相等值的可數數量。

我們不能直接度量開發者的輸出,因為他們的產出結果總是不一樣的。每個任務和專案都有獨特的要求,所以不存在重複的結果。如果沒有重複的結果,就沒有一個可靠的度量基礎。我們所擁有的只是間接指標,這些指標並不總是與價值相關,將它們作為目標最終帶來的傷害將大於好處。

無法被度量的東西可以得到改進嗎?

指標很方便,因為它們為我們提供了一個反饋迴圈——你可以瞭解你做出的改變是否改進了某些東西。如果沒有指標,反饋迴圈就不會那麼簡單了。有時候你甚至會覺得自己像瞎子一樣。彼得·德魯克有句名言:

如果你不能度量它,就不能管理它。

但這不是真理。根據德魯克研究所的說法,彼得·德魯克並沒有幻想可以為所有事情找到一個度量標準。事實上,他從來沒這麼說過。並不是所有重要的東西都可以被度量,也不是所有被度量的東西都很重要。

沒有好的指標並不意味著我們不能提高開發速度。有些公司的軟體開發速度肯定比其他公司更快,而且不會因為速度更快而導致質量下降,因此,改進是可能的。

底線

你可以並且應該使用指標來改進軟體產品。你可以考慮使用效能指標(如延遲或 CPU 負載)、可靠性指標(如正常執行時間)和使用者行為指標(如轉化率或留存率)。

但是,當你想要提高軟體開發速度,不應該依賴指標,因為我們沒有合適的可用指標。我們可以度量很多東西,但不幸的是,我們可以度量的所有東西都與價值沒有直接聯絡,或者沒有足夠的價值一致性,或者兩者都不具備。如果你基於這樣的指標設定目標,就不會有什麼好結果。

頂部