Jeff Patton在2019年敏捷希臘峯會的閉幕主題演講中說，我們需要關注結果，調整我們的思維方式和流程，從而不斷髮布產品和服務的小更改。
Patton表示，我們應該付費學習，而不是僅僅構建“潛在的可交付軟件”。他認爲，我們必須承認我們經常會失敗——我們必須讓謙遜成爲流程的一部分。然後，我們可以把學習納入流程：
如果我們不瞭解客戶的問題，那麼我們可以研究。如果我們不知道他們真正想要什麼，我們可以花時間構建原型，如果我們不知道他們是否會繼續使用它，我們可以花時間構建軟件，然後發佈給有限數量的客戶，並觀察他們的行爲。這些都不會帶來投資回報。不過，它們會幫助我們做出更好的決定，決定我們應該大規模地構建什麼。
Patton說，“當我們開始可視化結果時，團隊的思維模式就會開始關注結果。”
Patton建議多談結果。他說，即使是使用“項目”這個詞也會破壞我們的思考。要記住，我們希望項目結束，但理想情況下，我們希望產品儘可能長時間地存續。他認爲，我們所關注的結果只有在我們交付產品並投入使用之後才能被衡量；這就是爲什麼它被稱爲“結果”。
在2019年敏捷希臘峯會上演講結束後，InfoQ採訪了產品設計顧問、《用戶故事映射》一書的作者Jeff Patton。
InfoQ：21世紀的軟件開發實踐對軟件行業中許多人持有的流程假設提出了怎樣的挑戰？
Jeff Patton：事實上，我們生活的世界已經變了。我們的流程即工作方式正在適應這種變化。
最好的軟件開發流程和實踐是對我們的業務需求以及我們構建和銷售的產品和服務的響應。想想你每天使用的產品和服務的類型；它們中有多少依賴於數字體驗？你的手機，你的手錶，你的車，你的流媒體，你玩的遊戲。想想銀行、購買機票或酒店房間等服務。想想你是如何找到一家新餐館的，或者是如何點外賣的。現在，想想你每天使用的所有這些數字體驗，想想你看到的大版本和大更新的速度。我猜你不會看到很多。相反，你看到的是持續的小變化。
這是新常態。一切都是數字化的——需要軟件和技術。我們不再試圖在一個發行版中打包儘可能多的內容——相反，我們正在嘗試對我們的產品和服務進行持續的小改進。
不管你怎麼稱呼你遵循的流程，它都不能再根植於20世紀的大設計模式以及接下來的大交付。這種思維方式挑戰了企業賴以構建的許多假設。
例如，許多企業投資的技術開發都是使用時間和範圍固定的項目，其目標是在固定的時間內獲得儘可能多的成果。項目往往是長期的，以季度或年爲單位。相比之下，當代以產品爲中心的組織爲一個產品領域融資數月或數年，卻不瞭解他們將獲得的特性。相反，其關注點是可觀察到的市場成果——如客戶獲取和保留。那個產品領域的團隊會使用這些資金來持續地改進這個產品領域，關注的還是相同的業務成果。
InfoQ：我們在設計和構建軟件時應該怎麼做？
Jeff Patton：許多敏捷流程中缺失的價值觀是謙遜；承認我們不完美，承認我們經常會失敗。
我們無法預測在一次衝刺或一次發佈中能完成多少工作。但是，更常見的情況是，我們無法預測客戶是否會喜歡和使用我們的產品，以及是否有足夠多的客戶，讓我們可以真正獲得投資回報。如果這很簡單的話，所有的創業者都會成爲億萬富翁。
一旦我們把謙遜納入流程，我們就可以在流程中建立起學習文化。我們需要比十年前更快地學習這些東西，因爲請記住，當今世界發展得更快。這就是爲什麼像精益創業、設計、思考、精益用戶體驗和設計衝刺這樣的過程方法蓬勃發展的原因。它們是“付費學習流程”。將這些流程與更傳統的敏捷方法相結合，就形成了所謂的雙軌開發；一個同時包含持續學習軌道和大規模構建軌道的流程。
InfoQ：成功的項目注重結果，而不是產出。我們如何調整我們的心態和做法，以推動結果導向？
Jeff Patton： 更多地談論結果。這是項目思維方式和語言的問題。
我們用時間、成本和範圍定義項目。在像Scrum這樣的敏捷過程中，我們關注的是同樣的事情。我們定了爲期兩週的衝刺。我們通過調整團隊規模來降低成本。因爲Scrum可能有點殘酷，我們強迫團隊自己確定範圍——承諾在衝刺結束時能完成什麼。在衝刺審查中，我們會檢查我們所做的事情的質量——但是我們不會通常也無法談論結果，因爲通常在發佈幾周或幾個月之後我們才能瞭解結果。和項目思維一樣，Scrum也促使團隊關注時間、成本和範圍。
我試圖通過提醒人們這些現實來改變他們的思維方式。我會問團隊，“我們如何衡量成功的結果？”遺憾的是，這樣做的結果是更多的工作——尤其是監測產品，以便知道人們是否真的使用它們，以及使用了哪些功能。
我還會要求團隊構建一個簡單的可視化。左右軸是實際的工作；上下軸是實際的結果。對於他們提供的每個特性或功能，都放到這個簡單的圖表中。當將特性放到工作軸上時，我會要求他們把花費時間比預期長的標記出來。他們很快就會知道，大事耗費的時間往往比預期的長。對於實際結果，我將要求他們使用不同的桶。第一個是“不知道”——什麼都是從這個狀態開始的，因爲直到產品上市，用戶開始使用它們，我們才知道。但除此之外，還有從“糟糕”到“棒極了”。團隊開始瞭解需要多長時間才能看到結果。從“不知道”到“糟糕”到“棒極了”可能需要幾周的時間。而且，他們也會開始發現很少有事情會以“棒極了”結束。最後，我們正在建設的項目的規模與結果幾乎沒有關係。通常，我們構建的最小的東西會取得最大的成果。
原文鏈接：