作者 | Steve Fenton

譯者 | 明知山

策劃 | Tina

在我成長的歲月里，我養過一只拉布拉多與惠比特混血犬，名叫巴克利。我們幾乎形影不離。我在花園里挖洞時，它會在旁邊嗅來嗅去。我在看書時，它會趴在我腿上，常常趴到我雙腿發麻。當我們全家去森林散步時，它會跑在前面探路，再折返回來看看我們。在它歡快地來回奔跑間，它跑過的路差不多是我們的十倍。

狗最棒的一點在于，當你處境艱難時，你可以跟它們傾訴。它們是極好的傾聽者，當無人理解你時，它們懂你。

如果我還要再養一只狗，陪伴會是我首要的理由。養狗的理由有很多，但對我而言，陪伴永遠排在第一位。

現在想象一下，我去救助中心想要看看可領養的狗狗，而他們卻想讓我帶一只獵豹回家，只因為它跑得比狗快得多。這就好比有些機構聲稱自己在用人工智能，卻只狹隘地看重速度。

速度從來都不是目標

我們以前經歷過這些。我們都應該為敏捷運動凋零成干癟的空殼、只剩下單純追求“速度”而感到惋惜。速度從來都不是最終目標。提升工作效率的首要意義是為了更早獲取反饋。當你發現你令人驚嘆的新功能并未讓用戶感興趣時，可以立即停止開發。

如果你能盡早終止一個糟糕的想法，就能少浪費很多資源，并且能立即轉向更好的思路。沒有人應該一味追求用最多的功能、最快的變更速度來開發軟件。當軟件堆砌了過多功能，還為不斷膨脹的功能列表頻繁改動時，人們就會開始反感你所開發的產品。

微軟的 Word 是當今最強大、功能最齊全的文字處理軟件，但已經沒什么人專門用它了。他們都在用功能少得多的谷歌文檔。這說明谷歌選擇的功能必定更具吸引力，或者說更少的功能讓軟件變得更易用。實際上，這是諸多細小因素共同作用的結果。有時候，一項真正亮眼的功能便能蓋過所有其他的功能，而在瀏覽器中就能協作編輯谷歌文檔的便捷性可能正是如此。

如果你在二十年前問別人，他們會告訴你微軟 Word 在同類軟件中擁有不可撼動的地位，但現在它只占有 3.9% 的市場份額，而谷歌文檔占 9.6%（數據來源：https://6sense.com/tech/productivity/googledocs-vs-microsoftword）。如果你認為這種市場轉變僅僅是定價問題，那你很可能正在為那種只片面追求速度的組織工作，因為你已經不再相信打造用戶真正重視的軟件這一理念了。

為了速度而采用人工智能缺乏可信度

軟件行業的領導者有著他們的一貫作風，當他們宣稱只為一味追求增速而采用人工智能時，這一點理應被審慎看待。你會發現，在過去十年或二十年里，他們曾宣布為追求速度而進行敏捷轉型、采用 DevOps 或進行平臺化改造。

他們在所有這些舉措中耗費了大量精力卻未取得顯著成果，這充分說明他們并不像聲稱的那樣渴望速度。當然，他們想給自己的工作履歷貼上一枚“DORA 精英績效”的徽章。但他們仍然沒有真正的動力去提升速度，因為他們對那個更頻繁交付的基本成果——用戶反饋——并不感興趣。

任何一位讓團隊以速度之名經歷了這么多次折騰，現在又說人工智能將最終帶來速度的領導者，都是在自欺欺人。

反饋節拍器

當你更看重反饋而非速度時，就會讓反饋循環來主導整個軟件交付流程的節奏。以這個節拍來設定節奏，能為你留出關鍵余地去處理反饋，并做到敏捷理念所倡導的核心：快速調整方向。

把反饋當作節拍器、為整體工作節奏定調的組織和團隊往往能夠主動找出并消除所有打亂節奏的工作。他們規劃團隊架構，以最小且經過精心設計的依賴關系來開展工作。他們簡化變更審批流程，確保團隊能夠自主決定何時上線部署，同時也能完整地觀測到部署后的實際效果。

DORA 模型及其包含的生成式文化、變革型領導力、精益產品管理與持續交付流程并非偶然被創造出來的，而是數十年深耕實踐沉淀出的成果。踐行這些理念的團隊固然擁有交付速度，但這并非他們采納這類文化與實踐的初衷。他們真正追求的是獲取高頻且高質量的反饋，從而找準真正需要構開發什么。

Elite 團隊的做法

Elite 團隊是一家大型醫療保健企業旗下的軟件團隊。該機構主營病患管理與急診分診相關軟件業務。放到安全關鍵行業來看，這類軟件確實是能夠直接關乎生死的。

他們每六個月發布一次病人管理系統，而決策支持系統的測試周期為兩周，如果發現問題還要再加兩周。如此循環往復，直到某個版本測試通過為止！

即便有著這樣的過往，我們還是設法開展了一項為期六個月的工作計劃，每三小時就能創建一個可部署的軟件版本。我們遵循了一套非常強大的技術實踐，但我們刪減掉的內容或許比新增的更為重要。這種平衡來自于引入了實例化需求的可執行規范，同時剔除了流程緩慢、效率低下的官僚審核環節。

就成果來看，與一家新醫療保健服務商達成重要合作，對方需要提供決策管理 API，用于接入他們的網站系統。我們在兩周內安全地交付了一個可用的 API，并促成了一份價值 180 萬美元（相當于現在的 250 萬美元）的合同。

如果你的組織還沒有梳理出投產路徑并做出類似的改變，那么沒有任何方式能夠實現你想要的交付速度。你會引入人工智能，就像當初引入 Scrum、DevOps 和平臺工程一樣，最終依舊收效甚微，和過往的結局別無二致。

你當下能做的最重要的事情就是梳理價值流，尤其是從代碼提交到生產部署的流程，并開始修復那些損壞的部分。該做出哪些改變其實并無神秘可言。Dave Farley 和 Jez Humble 在他們合著的《持續交付：通過構建、測試和部署自動化實現可靠的軟件發布》中已經揭示了其中的奧秘。

你為什么采用人工智能？

在此之前，你或許會說采用人工智能是為了提升效率、加快進度。倘若你認真對待軟件開發這件事，我希望你能轉變這種說法，并向身邊的人明確表明：頻繁反饋和決策敏捷性才是你的核心優先事項之一。

那些已經通過持續交付等實踐解決了吞吐量 / 穩定性權衡的團隊，對單純追求速度的執念會更低。他們更愿意去挖掘更有價值的發展機會。最后，我想列舉并建議幾類這樣的機會。

小團隊更優。我們在這個問題上做出了妥協，因為我們需要的東西等不及一個非常小的團隊來慢慢完成。我們可能會將團隊規模擴大一倍，即使我們知道這樣做并不會將所需的時間縮短一半。COCOMO 模型對這種收益遞減規律有著精密的計算，不過 Fred Brooks 說得更令人印象深刻：向一個已經延誤的項目增加人手只會讓它延誤得更久。

因此，大多數深知溝通與協調復雜度的軟件團隊都會把人數控制在 6 至 12 人的規模區間，也就是所謂的“兩張披薩”團隊。但這并非理想團隊規模，其實還是偏大了。這只是權衡多方因素后做出的務實選擇。如今有了人工智能，我們應當考慮打造“一張披薩”規模的團隊，甚至更小。

具備高度自主性、基于松耦合組件開展工作的小型團隊或許是釋放人工智能賦能軟件開發價值的有力方式。

我的最后一個建議是，與其只是更快地開發原有軟件，人工智能或許能讓你的團隊去打造更具格局與愿景的產品。你可以著手推進以往遲遲不敢啟動的全球化業務布局。你或許早就有一些功能構想，卻始終無法梳理出清楚的思路，而借助人工智能快速搭建原型，你能夠進行從前難以嘗試的探索與實踐。

無論如何，先從對軟件交付流程與部署流水線進行更大力度的優化著手。務必打通反饋閉環，并像使用節拍器一樣用它來把控整體節奏。做好這些之后，你在引入人工智能時便能追求遠比“單純提速”更有價值、更具想象空間的目標。

https://thenewstack.io/feedback-driven-ai-adoption/

聲明：本文由 InfoQ 翻譯，未經許可禁止轉載。

會議推薦

企業級 Agent 落地，繞不開 4 個真實的工程問題！如何在 Agent 安全性和可用性之間找到平衡點？Agent 需要什么樣的記憶系統才能真正理解上下文？如何通過算法壓榨實現智力增量與成本控制的極致平衡？多 Agent 協作，如何做到可觀測、可治理、可控制？6.26-27 AICon 上海站，國內頭部公司的 Agent 實踐，一次說透。

今日薦文

你也「在看」嗎？