成果重於產出

想像一個團隊正在為購物網站撰寫軟體。如果我們查看團隊的產出，我們可能會考慮他們在上個季度製作了多少新功能，或跨職能衡量標準，例如減少頁面載入時間。然而，成果衡量標準會考慮衡量銷售收入增加，或減少產品的支援電話數量。專注於成果，而非產出，有利於建置更多功能來提升軟體使用者和客戶的效能。

與任何專業活動一樣，我們這些參與軟體開發的人員都想要了解什麼讓我們更有效率。這適用於想要提升自己表現的個別開發人員、想要提升組織內團隊的經理，或像我這樣的專家，想要提升整個產業的競爭力。讓這件事變得困難的原因之一，是因為沒有明確的方法來衡量軟體團隊的生產力。而且，這個衡量問題會因為我們是根據產出或成果來評量效能而變得更加複雜。

我一直認為我們應該專注於成果。如果一個團隊提供了大量功能，無論我們用程式碼行數、功能點或故事來衡量，如果這些功能無法幫助使用者提升其活動，那麼這些功能就沒有意義。許多未使用的功能都是浪費精力，事實上，它們比這更糟，它們會使程式碼庫膨脹，讓未來更難新增新功能。這樣的軟體開發團隊需要關心新功能的實用性，他們在提供較少但更有用的功能時進步。

我聽過一個反對使用基於結果的觀察的論點，那就是想出可重複的結果測量比產出測量更困難。我發現這個觀點難以理解。衡量軟體的純產出出了名的困難。程式碼行數是一個無用的測量，即使它們沒有那麼容易被操縱。功能點或故事點的可複製性很差 - 不同的人會給予相同的事物不同的點數。與此相比，我們非常擅長衡量財務成果。當然，許多結果觀察更難進行 - 考慮客戶滿意度 - 但我認為它們沒有任何比軟體功能更困難的。

當然，僅僅稱呼某事為「結果」並不能讓某事成為關注的正確事物，而且肯定有技巧可以選擇正確的結果來觀察。一個方便的概念是 Seiden，他說結果應該是使用者、員工或客戶行為的改變，這會為組織帶來好事。他區分了「結果」，這是較容易觀察的行為改變，以及「影響」，這是對組織的更廣泛影響。在開發 EDGE 時，Highsmith、Luu 和 Robinson 建議關於客戶價值的結果（洗碗機的可靠性）應比關於業務價值的結果（保固維修成本）賦予更大的權重。

使用結果觀察時，一個後續的疑慮是，將其分配給軟體開發團隊較為困難。考慮一個使用軟體來追蹤其供應鏈中商品品質的客戶團隊。如果我們根據最終消費者拒絕的數量來評估他們，其中有多少是軟體造成的，有多少是品質分析師開發的品質控管程序造成的，又有多少是改善原料品質的獨立計畫造成的？如果我們想要比較不同的軟體團隊，例如為了判斷使用 Clojure 是否有助於團隊更有效率，這種分配的困難將會是一個巨大的障礙。類似地，開發人員工作得很好，並交付出色且有價值的軟體來追蹤品質，但品質控管程序卻很糟糕。因此，拒絕率沒有下降，而計畫被視為失敗，儘管開發人員在他們的部分做得很好。

但分配的問題不應被視為觀察錯誤事物的理由。俗話說「你得到你所衡量的」，在這種情況下，更像是「你得到你嘗試衡量的」。如果你將成功評估的重點放在產出上，那麼每個人都在思考如何增加產出。因此，即使很難確定團隊的工作如何影響結果，但人們轉而思考結果以及如何改進結果的事實，比任何比較團隊在生產錯誤事物方面的熟練程度的努力都更有價值。