1. 冰山效應：非技術人員只看得到 UI#

Joel 用冰山來比喻軟體開發中一個根深蒂固的溝通問題：非技術利害關係人（老闆、客戶、專案經理）判斷專案進度的依據，幾乎完全是他們能看到的東西——也就是使用者介面（UI）。

然而，UI 只是整個軟體的「冰山一角」。真正龐大且複雜的部分隱藏在水面之下：

• 資料庫設計與資料存取層
• 商業邏輯與規則引擎
• 安全性機制（認證、授權、加密）
• 錯誤處理與例外情況的管理
• 效能最佳化與快取策略
• API 設計與系統整合
• 自動化測試與部署流程

這個現象不是因為非技術人員「不夠聰明」——而是因為軟體的本質就是抽象的。你不能像看到一棟建築物的結構一樣，直觀地看到軟體的內部架構。唯一可見的介面就是 UI。

2. 這個認知落差造成的問題#

2.1 過早展示精美的 UI 會讓人以為專案快完成了#

這是最常見也最致命的問題。假設你花了一週做了一個漂亮的 UI mockup 或 prototype：

• 客戶看了之後說：「哇，看起來快完成了嘛！」
• 但實際上後端邏輯、資料處理、安全機制、錯誤處理都還沒開始
• 專案可能只完成了 10%，但客戶覺得已經完成了 90%
• 當後續開發花了「預期之外的長時間」時，客戶會感到困惑甚至憤怒

2.2 不成熟的功能需求開始湧入#

一旦利害關係人看到「接近完成」的介面，他們會立刻開始提出各種修改和新增需求：

• 「既然都快做完了，能不能再加一個功能？」
• 「這個按鈕的位置我覺得應該改一下」
• 「能不能把這邊的流程改成那樣？」

這些需求在專案早期出現原本是好事，但問題在於它們的產生是基於「專案快完成了」的錯誤前提，導致對時程的期望完全失真。

2.3 時程估算的崩壞#

當利害關係人基於 UI 的完成度來推斷整體進度時，會產生嚴重的時程誤判：

• 「UI 都做好了，應該再一兩週就能上線吧？」
• 「上次你改了一個畫面只花了兩天，為什麼這次要兩個月？」
• 管理層開始質疑開發團隊的效率，信任關係惡化

最糟糕的情況是：團隊為了「看起來有進度」而優先開發 UI，把困難的後端工作往後推。這會造成專案後期的爆炸——所有困難的問題同時爆發，而截止日期已經近在眼前。

3. Joel 的建議：管理期望#

3.1 控制展示的時機與方式#

• 在早期展示時，使用低保真度的草稿或線框圖（Wireframe），而非精美的設計稿
• 讓介面看起來「明顯未完成」——這能準確傳達專案的真實狀態
• 當後端工作正在進行時，明確告知：「畫面不會有變化，但我們正在建造底下的基礎設施」

3.2 主動解釋水面下的工作#

不要期望非技術人員自動理解「看不見的工作」。你需要主動溝通：

• 用類比讓他們理解（「就像蓋房子，你看到的外牆只是最後一步，之前需要地基、結構、水電管線」）
• 在進度報告中明確列出正在進行的非 UI 工作
• 展示測試結果、效能數據等「看不見的品質」的證據

3.3 謹慎使用 Prototype#

Prototype 是雙面刃：

• 好處：幫助團隊與客戶對齊需求，及早發現問題
• 風險：讓客戶誤以為「做出 prototype 就等於做出產品」

如果你決定使用 prototype，請在展示時明確說明：「這是一個外殼。裡面沒有任何真正的功能。它的目的是讓我們討論介面設計，而不是展示進度。」——然後重複說三次，因為他們第一次聽不進去。

4. 開發者的自我保護策略#

理解冰山效應後，開發者可以採取以下策略來保護自己與團隊：

• 先做困難的部分：先處理後端邏輯、資料模型、效能需求等水面下的工作，最後才做 UI。這樣當 UI 開始出現時，專案確實已經接近完成
• 持續溝通進度：不要等到有視覺上的變化才報告進度。定期告知利害關係人正在進行的工作，即使那些工作「看不到」
• 量化不可見的工作：用具體的數字說話——「我們完成了 47 個 API endpoint 中的 32 個」比「後端正在進行中」更有說服力
• 教育利害關係人：長期而言，幫助非技術人員理解軟體開發的本質，是減少摩擦的最有效方法