David Wood — Fredericksburg, Virginia, USA
我們不可能知道一切#
在軟體產業，知識更新的速度遠超過任何個人的學習速度。昔日學一門手藝、終身受用的時代已成過去。如果停止學習，你會迅速落伍。
然而，面對這個現實，我們在專案管理上卻常常做出截然相反的假設：彷彿只要前期做足分析，就能完整掌握一個軟體專案的所有需求。
核心觀點： 完美知識謬誤（The Fallacy of Perfect Knowledge）——認為可以在某個時間點，為軟體專案擷取完整、無衝突的需求——這是一種根本性的錯覺。
瀑布式方法論的根本假設#
經典的**瀑布式方法論（Waterfall Methodology）**及其衍生流程，都隱含一個前提：只要前期投入足夠的時間與謹慎，就能在第一行程式碼寫下之前，完整理解整個專案。
這個假設是錯的，原因有三：
- 需求即使「確認」後仍會改變，開發過程中環境與理解都在持續演進
- 多個需求往往相互衝突，即使來自同一個來源
- 相同的需求文字，可能被不同人解讀成不同意思，受到個人認知、目標與語言背景的影響
迭代方法論的侷限#
螺旋式或敏捷方法論承認需求會演變，將迭代開發視為解法。但這也只是部分答案——軟體交付只是開發歷程中的一個逗號，而非句點。
需求在交付後仍會持續變化，在系統進入維護期甚至成為遺留系統（Legacy System）後，依然如此。
補充： Meir (Manny) Lehman 早在 1969 年就指出，軟體在其整個生命週期中會不斷演化。這個洞見奠定了後來所有演化式軟體工程方法的理論基礎。
擁抱無知，才能向前#
技巧： 接受「我們永遠無法完全掌握需求」這個現實，並據此設計開發流程：
- 在維護階段持續使用迭代（Iteration）與重構（Refactoring）
- 將需求的演變視為正常現象，而非失敗
- 建立機制讓新的理解能夠快速被納入系統
注意： 在需求文件上花費大量時間試圖「寫得完整」，往往是一種虛假的安全感。需求文件越詳盡，過時的速度往往越快。接受不完整性，反而是更誠實、更有效的專案管理態度。