結果大於產出
著者 Martin Fowler
譯者 塵世間一個迷途小碼農
想象一下一個團隊在編寫購物網站的技術團隊。如果我們在看這個團隊的產出的時候，我們或許會考慮上個季度產出了多少個功能，或者一個跨功能模塊的度量（如頁面加載時間）。然而，一個對於結果的度量將應該考慮度量所增加的營收，或者所減少的產品支持電話數量。聚焦於結果而不是產出，將會使得團隊傾向於構建那些有助於提升軟件用戶和客戶效率的功能特性。
就好像任何專業活動一樣，我們這些從事軟件開發的人想要了解是什麼使得我們更有效。事實上確實如此，正如一個開發人員嘗試改善他的個人表現，或一個希望改進組織內團隊的管理人員，或者像我這樣試圖提高整個行業水平的專家亦是如此。但是，使這變得困難的事情之一是沒有明確的方法來度量軟件團隊的生產力。這個度量問題變得更加複雜的原因取決於我們將有效性測量建立在產出還是結果的基礎上。
我總是認爲結果應該是我們所關注的。如果一個團隊交付了很多功能，不管我們是用代碼行數、功能點數還是故事數來度量它，如果這些功能無法幫助用戶改進他們的活動，那麼這些功能就無關緊要了，許多未使用的特性都是浪費精力。實際上，更糟糕的是它們會使代碼庫膨脹，從而使將來添加新特性變得愈發困難。這樣的軟件開發團隊需要關注新功能的有用性，這樣它們就可以在交付更少但是更實用的功能的這個事情上得到改善（這裏指的就是團隊的結果【outcome】更高）。
我聽到一個關於反對基於結果的觀察的論點是，爲結果而提出的可重複的度量要比爲產出而提的要更困難。我發現這個觀點挺難理解。度量軟件的“純”產出是出名的困難，代碼行數是一個無用的度量，即使它們不那麼容易被用於在產出多少方面進行造假。另外，功能點或者故事點的可複製性是很差的，不同的人會給同樣的東西打不同的分數。與此相比，我們非常善於度量財務產出。誠然，考慮到客戶滿意度的話，許多的觀察結果是更加棘手，但是我不認爲它們任何一個比軟件功能的評估更難。
當然，僅僅稱某件事爲“結果”並不能讓你把注意力集中在正確的事情上，而選擇觀察正確的結果肯定是有方法技巧的。Seiden提出了一個很有用的觀點，他認爲結果應該是對組織有益的一些用戶、員工或客戶行爲的改變。他區分了“結果”和“影響”，前者是更容易觀察到的行爲變化，後者則是對組織有着更廣泛的影響。在《發展邊緣》一書中，HighSmith、Luu和Robinson建議，基於客戶價值的結果應該比基於業務價值的結果應該得到更多的重視（書中舉例指一臺洗碗機的可靠性要比保修維護成本更應該被重視）。
使用結果觀察的一個重要問題是，很難將它們分攤給軟件開發團隊。考慮一個客戶團隊，他們使用軟件來幫助他們跟蹤供應鏈中的商品質量。如果我們通過最終消費者退回的不良品的多少評估它們的話，有多少是由軟件引起的，有多少是由質量分析人員開發的質量控制程序引起的，有多少是由提高原材料質量的行動引起的？如果我們想要比較不同的軟件團隊，這種（責任）分攤的困難是一個巨大的障礙，也許如果是爲了判斷使用Clojure是否幫助團隊會來得更有效一點。同樣的情況是，開發人員工作得很好，並交付了優秀且有價值的軟件來跟蹤質量，但是質量控制流程並不好。因此，儘管開發人員在他們這方面做得很好，但不良品還是因此沒有下降的話，整體項目（包含開發人員的軟件交付也作爲整體項目的一部分）還是被認爲是失敗的。
但是，這個分攤的問題不應該被當作觀察錯誤事物的理由。俗話說“you get what you measure”，在這種情況下更應該是“you get what you try to measure”。如果你把成功的評價集中在產出上，那麼每個人都在思考如何提高產出。因此，即使很難確定團隊的工作如何影響結果，但人們轉而考慮結果以及如何改善結果的事實，這個要比在團隊中去比較誰在生產產品方面（不考慮結果，即不考慮客戶價值的這種產品生產的方向是錯誤的）更加熟練的這一個方面上的努力來得更加有價值。
原文鏈接：