我一直認為成效是我們應該關注的重點。試想一個團隊提供了很多功能（無論我們是用程式碼量、功能點、還是使用者故事來度量），只要這些功能沒有幫助使用者改善生產活動，其實都是無用功 - Martin Fowler
以下部份內容摘自Martin Fowler的文章：
一個開發網上商城的電商團隊，如果企業只關注團隊的產出，可能會考慮到團隊人員在上個季度中實際開發了多少新功能，或者考慮跨功能的提升，例如頁面載入時間降低了多少，圖片載入是否流暢。但是，如果考慮成效，增加銷售收入或減少產品支援電話數量才是真正有價值的度量。關注成效而不是產出，就會更加傾向於構建那些可以提高使用者和客戶效率的功能。
與任何專業活動一樣，從事軟體開發的我們也希望學習如何能夠更加高效。這對於希望改善自身績效的個體開發者，希望改善組織內團隊的管理者，都是如此。造成這方面學習困難的原因之一是沒有明確的方法來衡量軟體團隊的生產力。在此之上，考慮基於產出還是成效評價有效性，讓這個問題變得更加複雜。
Martin Fowler認為成效是我們應該關注的重點。試想一個團隊提供了很多功能（無論我們是用程式碼量、功能點、還是使用者故事來度量），只要這些功能沒有幫助使用者改善生產活動，那麼都是無用功。許多未使用的功能被浪費，更糟糕的是未使用的功能所寫的程式碼會使程式碼庫膨脹，從而導致將來新增新功能變得越來越困難。身處這樣境地的軟體開發團隊需要關心新功能的實用性，減少新功能的開發，從而能夠聚焦功能實用性。
也有人反對使用基於成效作為觀察點的論點 —— 要想針對成效提出可重複的度量，要比針對產出難很多。但Martin Fowler個人很難理解此觀點：眾所周知，度量軟體開發的純產出是困難的，即使不玩複雜的遊戲，程式碼行也是無用的度量；功能點或故事點的可複製性更差，不同的開發者針對同一事項會做出不同的評估。與此相比，我們是非常擅長衡量財務結果的。當然，確實有很多成效的度量是比較棘手的，比如客戶滿意度，但Martin Fowler認為其中任何一個都不會比軟體功能開發困難。
少即是多這個道理很容易理解，但在現實工作中，很少有人能夠做到和堅持這一點。往往行業頭部的企業怎麼做的，新增了功能，產品經理多會選擇直接抄，少數的產品經理會選擇對標，並加以改進。最終能夠真正的保持產品的簡潔性、實用性的少之又少。更不要說從解決使用者痛點的需求、用完即走（降低使用者對產品的無用依賴）、減少使用者客訴量等基於成效的度量去做事。最終導致的就是小到團隊新人牴觸臃腫的程式碼量，反覆最佳化重構都無法根治。大到產品失去重點、浪費人力和物力，人員陷入疲憊的追逐功能的賽道上，缺乏創新動力。管理盲目對人員以產出為績效評定，造成無休止的功能迭代和重構怪圈。
所以當我看到“Martin Fowler： 關注成效而非產出”的文章後，變產生很強的認同感。那麼如何選擇正確的成效進行觀察確實是一項技能。Seiden提出過一個簡單判斷，他說成效應該展現在對組織有利的使用者、僱員或客戶的行為變化之上。他進一步區分了“成效”和“影響”，前者是易於觀察的行為變化，後者是對組織更廣泛的效果。在開發EDGE框架時，Highsmith，Luu和Robinson建議，針對客戶價值（洗碗機可靠性）的成效度量要比關於業務價值（保修維修成本）的成效度量更為重要。
當然使用成效作為度量的一個結果是指標分解到團隊相對困難。比如一個用軟體來幫助跟蹤供應鏈中商品質量的團隊，如果根據最終消費者的拒單數來度量，那有多少是由於軟體本身造成的？有多少是由於質量分析師制定的質量管理過程產生的？有多少是配送過程中被人為造成的？因此指標分解的困難是比較不同團隊效能的巨大障礙。
但分解面臨的挑戰不應作為觀察錯誤事項的理由。我們常說“種瓜得瓜，種豆得豆”的道理，所以如果我們把工作重點放在產出上，團隊中每個人也都會考慮如何增加自己的產出，進而提升自己的業績，就會容易忽視掉產品本身要解決的問題，即便明知做的這些無用。因此Martin Fowler認為即使很難確定團隊的工作如何影響最終成功，思考和如何改善成效，對比那些無真正實效產出的付出都要值得。
