軟體開發的瓶頸從來都不是程式編寫，而是理解問題。
軟體開發被認為是緩慢的。這就是為什麼公司不斷尋找加速的方法：增加開發人員、更好的工具、更有效率的流程。最近，人工智慧（AI）承諾能大幅縮短編寫程式碼的過程。但如果瓶頸從來都不是編寫本身呢？
Golo Roden 是 native web GmbH 的創辦人兼技術長。他專注於網頁和雲端應用程式及 API 的設計與開發，特別關注事件驅動和基於服務的分散式架構。他的指導原則是，軟體開發本身並非目的，而必須始終遵循底層的技術專業知識。
多年來，我觀察到公司在錯誤的地方投入加速。他們優化編碼，而真正該解決的問題卻懸而未決：首先要理解應該建構什麼。本文將探討真正的瓶頸在哪裡，以及忽略它的代價。
論點很簡單：軟體開發的瓶頸從來都不是產生程式碼的速度。它一直是產生理解的速度。那些優化前者而忽略後者的人，正在朝錯誤的方向加速。
許多公司存在一個默認的假設：軟體開發之所以耗時，是因為程式編寫太複雜。程式碼產生得越快，產品就完成得越快。這個假設聽起來似乎合理，但仔細審視卻站不住腳。
問一位經驗豐富的開發人員他們的時間花在哪裡。答案可能會讓你驚訝。實際編寫程式碼通常只占工作的一小部分。大部分時間花在其他事情上：他們必須確切弄清楚應該建構什麼。理解現有系統如何運作。釐清需求到底意味著什麼。糾正第一次沒有理解對的地方。
這不是效率低下。這是工作的本質。開發軟體意味著理解一個問題，並將這種理解轉化為電腦可以執行的正式語言。轉化步驟，也就是編碼，是較小的部分。較大的部分是理解本身。
從需求到完成功能之間的時間之所以長，並非因為打字慢。而是因為理解需要時間。因為溝通需要時間。因為在商業邏輯的世界和程式碼的世界之間進行轉化需要時間。那些看不到這種差異的人，就是在錯誤的領域投資。
這有一個寫作的比喻：沒有人會聲稱小說寫得慢是因為作者打字慢。小說寫得慢是因為發展故事情節、人物、結構需要時間。最後的打字是微不足道的。軟體也是如此。只是我們被程式碼明顯的複雜性所蒙蔽。
當瓶頸被誤診時會發生什麼？你優化你認為是問題的地方，卻納悶為何結果不如預期。
我見過一些公司為了加快速度而擴大團隊。結果不是產出更多，而是協調工作量增加。突然間，更多人需要被納入同一個水平。更多的會議、更多的協調、更多的誤解。Frederick P. Brooks 的著名定律（「為一個延誤的軟體專案增加人力，只會讓它更延誤」）不是理論遊戲。它描述了當你認為軟體主要是靠勞力創造時會發生的情況。
我也見過一些公司轉向新的框架，因為舊的框架據說太慢了。結果不是開發速度加快，而是數月的學習曲線。承諾的生產力提升從未實現，因為實際問題，即缺乏對業務邏輯的理解，並未因新框架而解決。它只是被轉移到了一個新的技術層級。
目前，我看到一些公司期望 AI 驅動的編碼助手能帶來顯著的生產力提升。這些工具令人印象深刻。它們可以產生程式碼、減少樣板程式碼、提供建議。它們能在幾秒鐘內完成人類需要幾分鐘或幾小時才能完成的工作。但它們並沒有解決真正拖慢大多數專案的問題。
目前對 AI 在軟體開發中的期望非常巨大。有人談論十倍的生產力提升、程式設計的民主化、以及每個人都能很快開發軟體。有些人甚至預測經典開發者職業的終結。這些說法有一個共同點：它們假設編寫程式碼是限制因素。如果 AI 接管了編寫，那麼瓶頸就會消失。
任何在這個行業工作較長時間的人都會認出這種模式。低程式碼和無程式碼平台也曾做出同樣的承諾：業務部門應該自己建構軟體，開發人員將變得多餘。在此之前，有 RAD（快速應用程式開發）系統，它們應該讓程式設計變得如此簡單，以至於任何人都能做到。在此之前，有 CASE 工具，在此之前，有 4GL 語言。每一代都有其技術，聲稱將預示著經典軟體開發的終結。這些預測都沒有實現。
這並不意味著這些技術毫無用處。許多確實讓工作變得更容易，加速了某些任務，開闢了新的可能性。但它們沒有解決根本問題：必須有人理解要建構什麼。必須有人彌合客戶需求與機器可執行之間的差距。這種轉化工作無法被自動化取代。
AI 也無法改變這一點。開發人員將繼續被需要。但正在改變的是需求的輪廓。僅僅「我會程式設計」已不再足夠。編寫程式碼的能力正在變得商品化，如果機器也能做到。剩下的、獲得價值的，是理解的能力：深入問題、提出正確的問題、在業務邏輯和技術之間進行轉化。未來不屬於那些最快產生程式碼的人，而是屬於那些最能理解需要什麼程式碼的人。
因為 AI 可以根據指令產生程式碼。但指令必須來自一個理解了要建構什麼的人。AI 無法知道客戶需要什麼。它無法質疑需求背後的隱含假設。它無法識別兩個利益相關者在使用相同詞語時意味著不同的東西。所有這些仍然是人類的工作。
當公司跳過這項工作而依賴 AI 生成的生產力時會發生什麼？他們在更短的時間內獲得了更多的程式碼。基於未經驗證假設的程式碼。將誤解轉化為機器語言的程式碼。將來需要昂貴地修正或替換的程式碼。AI 交付了它應該交付的。只是它並不是所需要的。
如果我沒有理解我應該建構什麼，那麼更快地建構它對我幫助不大。我只會更有效率地建構錯誤的東西。程式碼產生得更快，但它沒有解決正確的問題。迭代仍然會來，只是現在有更多的程式碼需要再次觸及。更多的程式碼意味著更多的複雜性、更多的調整點、更多的潛在錯誤。
這並不是說 AI 工具毫無用處。恰恰相反：對於確切知道自己需要什麼的經驗豐富的開發人員來說，它們可以是有價值的工具。它們可以接管例行任務，為真正重要的工作騰出空間：理解、提問、思考。但它們不能取代這項工作。任何相信他們可以跳過 AI 的理解階段的人，最終將浪費更多時間，而不是更少。
AI 加速了編寫。它並沒有加速理解。而理解一直以來都是真正的瓶頸。一個幫助我在錯誤方向上跑得更快的工具，並不是生產力提升。它是失敗的加速。
切入正題：專案到底在哪裡浪費時間？
第一個因素是業務部門和開發部門之間的誤解。一個需求被提出，開發部門實現它，在驗收時，卻發現：這不是他們的意思。不是因為有人犯錯。而是因為同一個詞對不同的人意味著不同的東西。
業務專家談論「訂單」，指的是一個特定的東西，包含他們日常工作中知道的所有隱含規則、例外和邊界條件。開發人員聽到「訂單」，並將其映射到他們的心智模型，這個模型必然是不完整的。兩者都認為他們在談論同一件事。直到程式碼存在了，他們才意識到情況並非如此。
最終，軟體並不反映客戶想要什麼，更不用說他們需要什麼：軟體反映的是開發人員的理解。隱含的假設和解釋起著作用，而它們——自然地——常常是錯誤的。這不是對相關人員的指責。這是知識無法簡單地從一個頭腦流向另一個頭腦的不可避免的後果。
然後修正的代價很高。不是因為編碼昂貴，而是因為在調整現有程式碼的同時，還必須補上理解的差距。
第二個因素是後來被證明是錯誤的假設。每個專案都始於對問題、對使用者、對邊界條件的隱含假設。其中一些假設是正確的；有些則不是。問題在於：大多數這些假設從未被明確提出。它們存在於相關人員的腦海中，未經言說，未經審查。
一個錯誤的假設被認識得越晚，修正的代價就越高。在第一週被質疑的假設只需要一次對話。在開發了六個月後才浮現的假設，則需要重寫。發現一個花了數月時間開發的功能，實際上是基於一個根本錯誤的假設，現在需要完全重新思考或無替代地刪除，這並不罕見。
第三個因素是源於缺乏理解的迭代。我不是指好的迭代，也就是基於真實回饋的產品逐步改進。這些迭代是有價值的。我指的是不必要的迭代：建構某物，意識到它是錯誤的，然後重建。不是因為需求改變了，而是因為從一開始就沒有正確理解它們。
這種迭代的代價很高。它不僅花費了重寫本身的時間，還花費了團隊看到他們的工作被丟棄的動力。它花費了利益相關者的信任，他們納悶為什麼花了這麼多時間在一個最終無法使用的東西上。它花費了在那個時間裡建構有意義的東西的機會。
所有這些因素都有一個共同點：它們不是源於編碼。它們發生在此之前。或者更確切地說，它們發生是因為「之前」被忽略了。
亞馬遜有一個原則叫做「反向工作法」（Working Backwards）。想法是：在產品開發之前，團隊會為完成的產品撰寫新聞稿。這不是為了行銷，而是作為一種思考工具。新聞稿迫使你從結果出發思考。這個產品到底應該為誰解決什麼問題？為什麼有人應該關心？它解決了什麼問題？最重要的是，客戶會如何描述這個產品如何改善他們的生活？
這聽起來像是額外的努力。它確實是初期的額外努力。但這種努力可以節省後來許多倍的時間，因為它在程式碼被寫入之前就揭露了誤解。它迫使假設被明確提出。它在第一行程式碼被寫入之前就建立了共同的理解。它防止了數月時間被投入到一個最終沒有人需要的產品上。
這些工具不必很花哨。與專家的深入對話，真正傾聽，不僅是收集需求，而是理解問題。共同演練流程的工作坊，以了解複雜性到底在哪裡。視覺化工具，展示不同的利益相關者如何理解問題以及他們的心智模型在哪裡存在分歧。
有正式的方法，如事件風暴（Event Storming），業務專家和開發人員在牆上的便利貼上協同演練業務流程。有來自領域驅動設計（DDD）的策略模式，有助於將大型領域分解為可管理的塊。這些以及類似的方法可能很有幫助，但它們本身並非目的。如果基本態度是正確的，即使沒有它們也能取得良好的成果。
因為最重要的事情不是方法，而是願意在寫下第一行程式碼之前投入時間去理解。願意提出可能聽起來很愚蠢的問題。願意質疑假設，即使其他人都認為它們是理所當然的。願意從慢開始，以便更快地達到目標。
「我們將從慢開始，以便更快完成」聽起來很矛盾。但這是我觀察到的專案一個接一個的現實。一開始花時間的專案，最終更快地達到目標。立即開始的專案，卻迷失在死胡同裡。
投資於問題理解是有投資回報率（ROI）的。只是它比額外開發人員的成本或工具的授權費更難衡量。
這種 ROI 反映在沒有發生的事情上：不必要的重寫。多餘的迭代。直到生產環境才顯現的誤解。由於早期就清楚它們無法解決實際問題而未被建構的功能。由於從一開始就有紮實的理解作為基礎而無需修改的架構決策。
它也反映在發生的事情上：真正解決業務問題的軟體——第一次就解決，而不是經過三次迭代後。理解「為什麼」的團隊，因此即使沒有明確指示也能做出更好的決策。基於對領域的紮實理解而非猜測而持續更久的架構決策。
這很難推銷。沒有人會因為沒有發生的錯誤而獲得獎金。沒有人會因為一個專案順利進行而得到晉升。理解的成功是看不見的。它們體現在問題的缺失，而不是解決方案的存在。這使得它們容易被忽略，難以被欣賞。
但數學很清楚：一開始投入理解的時間，最終會獲得數倍的回報。在與業務專家的良好對話中投入一天，可以節省數週的重寫時間。一個揭示假設的工作坊，可以防止數月時間朝錯誤方向開發。一個一開始提出的問題，可以挽救整個專案免於失敗。
這並不意味著在開始之前花費數月進行分析。它意味著在將答案灌輸到程式碼之前提出正確的問題。它意味著在建構之前傾聽。它意味著將理解作為工作的一部分，而不是延誤。
軟體開發之所以緩慢，並非因為程式編寫緩慢。它是緩慢的，因為理解需要時間——而且我們常常不允許那段時間。我們加速程式碼的編寫，而真正的瓶頸卻未得到解決。
這不是對個人的指責。快速交付結果的壓力是真實存在的。管理層對看到可見進展的急切心情是可以理解的。程式碼是可見的；理解是不可見的。優化可見的東西是人之常情。但這也是短視的。
好消息是：這個瓶頸是可以解決的。不是通過更快的工具，而是通過願意在專案初期投入時間去理解。通過與業務專家的對話，通過共同思考問題，通過在程式碼被寫入之前揭示假設。通過這樣的洞察：最快到達目標的路徑，不一定是從最快開始的那條路徑。
這需要時間。但它比替代方案花費的時間少。它會產生名副其實的軟體：解決問題而不是製造新問題的軟體。
軟體開發的真正瓶頸不是編碼。它從來都不是。那些認識到這一點的人，已經邁出了更快達到目標的第一步——通過從慢開始。正如海豹突擊隊的著名格言：「慢即是順，順即是快。」
本文最初以德文發表。在發表前經過技術協助翻譯並進行了編輯審閱。