譯者 | 王者
策劃 | 萬佳
如果你曾經管理過軟件項目，你可能會問自己：我們團隊如何才能更快地前進？現在前進的速度有多快?
面對這類問題，我們傾向於依賴指標。畢竟，我們在開發軟件時經常並且已經成功地使用了指標。我們有性能、生產負載和運行時間指標，還有一些基於用户行為的指標，如轉化率和留存率。這些指標不僅提供了可見性，更重要的是，它們創造了一個反饋循環。為了對一些東西加以改進，我們可以做出一個變更，並用指標來衡量改進的程度。開發者的智慧告訴我們，每一個軟件性能優化都必須從指標開始。
既然指標如此有用，我們就不能把它們應用到軟件開發速度中嗎？既然更好的開發過程應該要給開發輸出結果帶來改進，那麼輸出結果指標應該就可以度量開發過程是否真正得到改進。那麼，我們可以使用哪些指標呢？
在這方面，我們沒有什麼好的指標
開發速度是指單位時間內產出的工作量，所以我們需要同時衡量輸出和時間。衡量時間很簡單，但工作量如何衡量呢？工作量的衡量跟軟件本身一樣古老。多年來，每當我們決定用一個指標來衡量工作產出時，一些意想不到的事情就會出現。考慮以下這些例子：
代碼行數——這可能是最古老的一種指標，但如今幾乎沒有人把它當回事。把代碼行數作為衡量指標只會讓代碼變得臃腫，而且開發者只會專注於完成簡單的任務；
提交次數——這樣會鼓勵開發者將代碼提交分解為多個部分。同樣，開發者會更關注簡單的任務，避免去解決複雜的問題；
完成任務的數量——這樣會導致任務被分割成更小的子任務。每一個問題，即使是小問題，都是作為任務提交的。這也會促使你走捷徑，以最快的速度完成任務；
bug 的數量或 bug 的百分比——這不是工作輸出指標，而是工作質量指標。這樣會阻止開發者做出變更，並讓他們不願意報告自己發現的 bug；
工時或故事點數——當估算變成衡量團隊表現的手段，那麼很容易就可以猜到接下來會發生什麼——誇大的估算；
……
開發者很聰明，他們擅長解決複雜的問題。對於指定的指標，他們都會找到最簡單的改進方法，但很可能與工作質量或期望的項目結果不相關。但這並不意味着開發者就一定會這麼做，我認為這取決於具體環境以及動機有多強。但有一件事是確定的——開發者將意識到他們的生產力衡量方式與重要的事情是相脱節的。這不僅令人感到沮喪，也會讓他們在做真正的工作時分心。
為什麼會這樣？
為什麼指標對於軟件產品如此有效，而對於開發者的輸出卻不適用呢？這是開發者的陰謀嗎？實際上，如果你觀察一下軟件開發之外的領域，你會發現更多例子，它們可以説明指標適用於哪些方面以及不適用於哪些方面。
指標適用的地方：製造和銷售。以杯子的製造和銷售為例。你可以測量產量（比如每單位時間生產的杯子數量）和質量（無法通過質檢的不合格杯子的百分比）。在銷售方面，你可以衡量銷售額和利潤率。這些指標對管理來説都非常有用。例如，製造部門的目標可以是提高成功通過質檢的杯子的百分比，同時保持較低的單位成本。銷售主管的目標可以是增加銷量或提高利潤率。這些指標的改進對業務是有好處的，因此我們也可以將其作為相應部門效率的衡量標準。
指標不適用的地方：科學產出。科學家們通過論文來發布他們的研究結果。現在科學界也有了一些衡量工作產出和質量的指標：發表論文的數量、被引用的次數、研究結果的統計學顯著性。我們可以説發表 10 篇論文的科學家創造的價值是發表 5 篇論文的科學家的兩倍嗎？這是不太可能的，因為研究成果的價值是有差別的。即使不使用這些數字，通常也很難説哪項研究成果更有價值。因為論文數量和引文次數造假在科學界是一個眾所周知的問題，它們並不被認為是衡量工作效率的可靠指標。統計學顯著性也有問題——P 值篡改（p-hacking）是一個廣泛存在的問題。
兩個關鍵標準
在任何情況下，有效的指標都應該符合兩個重要的標準：
它們與價值直接相關；
這些價值具有一致性，即可以用可互換的單位來表示，並具有可數的數量。
讓我們來看看上面的例子：
製造和銷售的指標符合這兩個標準。在杯子的例子中，價值用杯子來表示。因為是大批量生產，所以杯子是一樣的。在銷售的例子中，價值是以美元來衡量的。業務目標是賺錢，所以錢與業務價值具有直接的關係。因為一美元可以等價其他任何一樣東西，所以基於金錢的指標可以衡量恆定的價值。
科學產出的指標不符合這兩個標準。我們找不到一個可以直接衡量科學研究結果價值的指標。我們只有間接的指標，比如論文和引用的數量，但這些都可能被篡改。無論如何，這些指標也不具有一致性，因為所有出版物都不是由可互換單位組成的。
開發者指標不符合這兩個標準
我們需要用什麼來衡量開發者的輸出？代碼行數、提交次數、完成任務的數量、工時、故事點數……如果將這些指標與上述兩個關鍵標準對照一下，你會發現：
它們都與價值沒有直接關係。我們不會向客户交付代碼行數、工時或故事點數。他們不關心我們提交了多少次代碼或完成了多少任務；
所有這些衡量結果都不具有一致性。這一次提交併不等於另一次提交，這一行代碼的價值與另一行代碼的價值不一樣，所有的任務也都是不一樣的，工時和故事點數都是估算出來的，具有不準確性。
毫無疑問，這些指標都不能很好地發揮作用。
為什麼我們沒有與價值直接相關的開發者指標？同樣的，我們也沒有給科學家用的指標。開發者就像科學家一樣，總是在創造新的東西。他們不會一遍又一遍地寫同樣的代碼——那樣沒有意義。代碼可以被重用——可以將它們提取到模塊或庫中，或者直接複製粘貼。每個開發者的工作都是獨一無二的。即使他們解決了相似的問題，也都是在不同的環境中或使用新的方法解決的。
是否有新的研究發現？
當然，現在沒有人會真的用代碼行數來衡量開發者的輸出，但應該會有一些新的研究發現，對吧？
2018 年出版的“Accelerate”一書呈現了對 2000 個不同規模的組織進行研究的結果。研究的目標是確定哪些指標可以用來區分高績效和低績效。他們的發現如下所示：
我們可以看到四個指標。接下來讓我們來看看這些指標是如何與價值聯繫在一起的，以及它們是否具有一致性：
部署頻率——我可以理解為什麼它會出現在這裏。你越頻繁地交付，交付過程就越可靠。高效的團隊往往更頻繁地發佈代碼。然而，相關性並不一定意味着因果關係。部署頻率與客户價值並沒有直接的關係。人們想要一個能夠滿足他們需求的產品，而不是一個儘可能頻繁變化的產品。這個指標也不具備一致性，因為一個變更並不等於另一個變更。
交付時間——滿足客户請求的時間。這一點與價值更加靠近一些，但它不具備一致性，因為客户請求是不一樣的，有些可能很簡單，有些可能極具挑戰性。
平均恢復時間(MTTR)——發生故障後恢復的速度。當軟件出現故障時，客户會不高興，所以這個指標與價值是有關係的，但也有不好的地方。首先，它沒有考慮到故障頻率。如果軟件經常出現故障並迅速恢復，儘管指標看起來不錯，但客户仍然會不滿意。第二，它不具備一致性，因為各種故障也是不一樣的。如果是整個系統出現故障，那就很嚴重了。如果只是一個小功能不能正常工作，大多數客户可能不會注意到。
變更故障率——導致故障變更的百分比。如果是用户自己安裝的更新，那麼這個指標確實與價值有關。如果用户在安裝更新時體驗不佳，他們就會害怕安裝後續的更新。對於 SaaS 產品，這種關係就不那麼直接了，因為客户不太關心服務為什麼出現故障，可能是由於變更，可能是你的一個供應商出了問題，可能是服務無法處理負載，或者是服務受到了攻擊。不管是什麼原因，如果服務不正常，顧客都會不高興。這個指標也不具備一致性，因為一個變更不等於另一個變更。有些變更是微不足道的，有些則可能很重要。
底線——所有四個指標都不具備一致性，而且並不總是與價值有直接關係。如果儘可能頻繁地發佈一些不重要的變更，那麼除交付時間之外，其他指標看起來都不錯。
至於交付時間，即使我們忽略了它不具備一致性的事實，將這個指標作為目標會導致我們優先考慮客户的簡單請求，卻忽略了客户沒有説出的請求。這通常包括重構、測試和所有其他客户沒有考慮到的改進。
這就是為什麼我不推薦使用這些指標作為開發目標。
或許我們可以找到更好的指標？
你可能會説：等等，雖然我們還沒有找到好的指標，但這並不意味着它們不存在，人們很聰明，他們會找到更好的方法。但我恐怕他們是找不到的。我們找不到好的開發者指標是有根本原因的。好的指標應該滿足兩個關鍵標準：
它們與價值直接相關；
它們具有一致性，即基於某些相等值的可數數量。
我們不能直接度量開發者的輸出，因為他們的產出結果總是不一樣的。每個任務和項目都有獨特的要求，所以不存在重複的結果。如果沒有重複的結果，就沒有一個可靠的度量基礎。我們所擁有的只是間接指標，這些指標並不總是與價值相關，將它們作為目標最終帶來的傷害將大於好處。
無法被度量的東西可以得到改進嗎？
指標很方便，因為它們為我們提供了一個反饋循環——你可以瞭解你做出的改變是否改進了某些東西。如果沒有指標，反饋循環就不會那麼簡單了。有時候你甚至會覺得自己像瞎子一樣。彼得·德魯克有句名言：
如果你不能度量它，就不能管理它。
但這不是真理。根據德魯克研究所的説法，彼得·德魯克並沒有幻想可以為所有事情找到一個度量標準。事實上，他從來沒這麼説過。並不是所有重要的東西都可以被度量，也不是所有被度量的東西都很重要。
沒有好的指標並不意味着我們不能提高開發速度。有些公司的軟件開發速度肯定比其他公司更快，而且不會因為速度更快而導致質量下降，因此，改進是可能的。
底線
你可以並且應該使用指標來改進軟件產品。你可以考慮使用性能指標（如延遲或 CPU 負載）、可靠性指標（如正常運行時間）和用户行為指標（如轉化率或留存率）。
但是，當你想要提高軟件開發速度，不應該依賴指標，因為我們沒有合適的可用指標。我們可以度量很多東西，但不幸的是，我們可以度量的所有東西都與價值沒有直接聯繫，或者沒有足夠的價值一致性，或者兩者都不具備。如果你基於這樣的指標設定目標，就不會有什麼好結果。