此篇文章是從 Joel on Software 繁中翻譯備份而來

揭露冰山般的秘密 The Iceberg Secret, Revealed

作者：周思博 (Joel Spolsky)
譯：Paul May 梅普華
Wednesday, February 13, 2002
屬於 Joel on Software, https://www.joelonsoftware.com/2002/02/13/the-iceberg-secret-revealed/

「我不知道我的開發團隊怎麼了，」執行長在心裡對自己說：「剛開案時情況還很順利的。整個團隊像瘋了一樣，前幾個星期就做出一個很好的可用原型。可是從那之後事情似乎慢得像在爬一樣。他們根本就是在偷懶吧。」他選了一根 Callaway 鈦製一號木桿，叫球僮去弄杯冰涼的檸檬水。「或許我應該開除幾個表現最差的，這樣應該能讓他們動作快一點！」

這時候開發團隊當然不知道有什麼不對。事實上沒什麼不對，他們完全按照進度進行。

別讓這種事發生在你身上！我要告訴你一個小秘密，是關於那些非技術的管理人員的秘密，可以讓你的日子好過一百萬倍。這其實很簡單。知道了我的秘密之後，你和非技術背景的經理合作時再也不會有麻煩(除非你跟他爭論他的高爾夫球桿的反彈係數)。

很顯然的程式師用某種語言思考，而 MBA 則是用另一種語言思考。我曾經對軟體管理中的溝通問題思考過好一陣子，因為對我來說，能在程式師和 MBA 間翻譯溝通的人少之有少，一旦掌握權力和報酬顯然都會隨之而來。

由於我是由軟體業開始工作的，幾乎我做過的所有軟體都是所謂的「猜測(speculative)」軟體。意思是該軟體並不是為特定客戶而製作，而是依據很多很多人會買的期望而建立的。不過很多軟體開發者並沒有這種福氣。他們可能是在當顧問，要為單一客戶開發一個專案，也可能是企業內部的程式師，幫公司寫個會計用的東西(或者其他內部程式師會寫的東西，反正對我來說很神秘)。

你是否曾經注意到，在這些客製化的案子中如果出現進度延誤、失敗或各種災難，都有一個最常見的原因。這個原由基本上可以濃縮下面這句話：「客戶(應該說多餘的客戶)並不知道他們要的是什麼？」

這邊列出同一種症狀有三種版本：

「這混帳客戶不停的改變主意。一開始要主從式架構。然後又在 Delta 航空的空中雜誌讀到 XML，結果又決定要加 XML。現在為了配合整群的樂高 Mindstorm 小機器人，我們又要整個重寫。」
「我們完全照他們的要求製作軟體。合約中把最小的細節都寫清楚。我們也照合約內容交付軟體。結果等我們交付時他們卻垂頭喪氣的。」
「我們的爛業務同意了一份固定價格合約，答應要寫基本上未明確定義的東西，而客戶的律師又夠精，抓緊合約裡的條款說除非客戶接受，否則不用付錢，所以我們只好投入 9 個人的團隊去做他們的案子，做了兩年才只拿到 800 美元。」

如果有某件事很重要，必須用 2500 轉大電鑽注入每個生手顧問的腦袋裡。那就是下面這個件事：客戶不知道他們要什麼。別再期望客戶知道他們要什麼。這種事就是從來沒發生過，你就認了吧。

代替的作法是假設你反正都得做出一些東西，而客戶也得喜歡你做的東西，最多只是會有點驚訝而已。你得自己去研究，自己去找出一個設計，能皆大歡喜地解決客戶的問題。

你要設身處地替他們著想。想像你剛把公司用一億元賣給了雅虎，決定要翻修廚房就找了專業設計師來。你給他的指示只有「要和威爾和葛蕾絲(Will and Grace, 譯註：美國喜劇)裡的廚房一樣酷。」你根本不知道要怎麼做到，也不知道自己想要一個維京爐具和 Subzero 冰箱，這些都不是你會的字。你只要設計師做出一些好東西，這就是你請他的原因。

搞極限程式設計的人會說，解決的方法就是把客戶帶進房間，把他們當成開發團隊成員一樣參與各個設計程序。我覺得這也太「極限」了一點吧。這就像是設計師在設計廚房時要我在場參與，然後要我對各個小細節表示意見。對我來說這實在很無聊，如果我想當個設計師我自己去當就好了。

不管如何，反正你不會真的要客戶待在你的團隊裡，是吧？客戶代表很可能只是會計部門抓來的某個小人物，派去陪程式師作業只是因為他是部門裡做得最慢的，所以沒有他做事也沒差。接下來你只好犧牲原本的設計時間，用最簡單明瞭的方式全部解釋一遍。

假設你的客戶不知道他們要什麼，然後依照你對該應用領域的瞭解自己去設計。如果你需要花時間去學習該應用領域的知識，或者需要該領域的專家幫忙，這都是正常的。不過要記得軟體的設計才是你的工作。如果你能搞懂該應用領域而設計出一套好的使用介面，客戶就會很高興。

回到主題，我答應過要告訴你一個秘密，那個關於軟體的客戶(或非技術經理)以及程式師兩者間語言翻譯的秘密。

你知道冰山有 90% 是在水面下嗎？沒錯，大部份的軟體也是這樣。那些漂亮的使用介面只佔 10% 的工作，而其他 90% 的程式設計都是看不到的。如果再考慮到一半時間在抓蟲這個事實，使用介面就只佔了 5% 的工作。如果只計算使用介面中的視覺部份(能在 PowerPoint 裡看到的部份)，其實就不到 1% 了。

這並不是秘密。真正的秘密是非程式人員並不知道這件事。

這個冰山秘密有些很重要的推論。

重要推論一：把使用介面的畫面展示給非程式人員看時，如果這個介面很不好，對方會認為你整個程式也是很不好的。

我在當顧問時學到這一課，當時我對某客戶的執行團隊展示一個重要的 web 專案。專案本身的程式幾乎都已完成，不過還在等美術設計師選擇字型和色彩還有漂亮旳立體活頁圖案。等待期間還是用普通字型和黑白色，畫面上有很多地方都空白而不太美觀，基本上就是不好看啦。不過功能全部都在，而且有些很不錯的成果。猜猜展示的結果如何？客戶整個會議都在緊盯著畫面的美術外觀。他們連使用介面都沒提，只管圖形好看不好看。他們的專案經理抱怨著說：「這看起來就是不太俐落。」他們能想到的就只有這些，我們沒法子讓他們考慮到功能。圖形設計顯然不用一天就可以修好，而整個感覺就像他們認為自己找的是畫家

重要的推論二：把使用介面的畫面展示給非程式人員看時，如果這個介面非常漂亮，對方會認為這個程式幾乎已經完工。

非程式人員只會看著畫面，他們看到的是一堆像素的組合。如果那些像素看起來像個有功能的程式，他們就會認為：「哦，要讓這個程式真的動起來應該不會有多難吧？」這裡有一個很大的風險：如果你先做出使用介面的原型，認為這樣就能與客戶進行討論，結果每個人都會認為你幾乎都做完了。接下來你花了整整一年去做「裡面」的事，卻沒人會看到你的工作成果，大家還以為你什麼都沒做。

重要的推論三：同樣是網路公司，比起功能齊全又累積了 3700 年資料但用灰色底色的網站，只有四個網頁但外觀漂亮的會獲到較高的評價。

噢，等一下，網路公司已經完全沒有價值了。別在意了。

重要推論四：因為政治因素要求由各技術經理或客戶「啟動」專案時，可以提供數種美術設計讓他們選擇。

改變某些元件的擺設方式，改變外觀和字型，移動標誌位置，標誌也可以變大或變小。拿些無關緊要的家家酒內容給他們玩，讓他們覺得自己很重要。這些他們就不會嚴重影響你的時程了。好的室內設計師會定期拿些樣本之類的小東西給客戶選，不過從來不會跟客戶討論洗碗機的位置。不管客戶想怎樣，反正洗碗機就是放在水槽邊，沒必要浪費時間去爭論，就是得放水槽邊，連擺高一點都免談；客戶想玩設計就讓他去碰些無害的東西，比如流理檯面要選義大利花崗石，還是用墨西哥瓷磚還是挪威木砧板，這種事他改變主意 200 次都沒關係。

重要的推論五：展示時唯一重要的就是畫面。一定要讓它美得冒泡。

不要認為你能成功地讓任何人去想像這會有多酷，也不要認為他們會注意功能。他們才不管呢。他們只想看到一堆漂亮的像素。 Steve Jobs 懂這個。哦，小朋友他是真的很懂。蘋果的工程師已經學會做出漂亮的畫面，看看 Dock 上那個 1024x1024 的華麗新圖示(雖然這樣會浪費珍貴的桌面空間)。而 Linux 的桌面幫卻為半透明的 xterm 而瘋狂，畫面是很漂亮沒錯，不過通常用起來很煩。每次當 Gnome 或 KDE 宣佈發行新版，我會直接去看看畫面抓圖，然後說：「噢，他們把行星由木星改成土星了，酷哦。」不過從來不管他們實際上做了些什麼。

記得這篇文章一開始時的執行長嗎？他之所以不高興，是因為團隊在剛開始就給他看很漂亮的投影片，裡面都是用 Photoshop 做的原型(連 VB 都不是)。而後來都在實際做底下的東西，所以看起來就像完全沒做事。

你要怎麼處理這種事呢？當你瞭解了冰山的秘密後就很容易處理了。要知道在暗室裡用投影機所做的任何展示都只是像素而已。如果可以的話應該把未完成的使用介面畫得像未完成。舉例來說，在功能完成之前對應的工具欄圖示就只用草圖。如果是建立 web 服務，在功能完成之前就先不要放在首頁裡。這樣大家就會逐漸看到首頁由三個命令擴充到廿個命令。

更重要的是要確定你控制了大家對時程的想法。提供一份 Excel 格式的詳細時程。每星期都送出自我慶祝的電子郵件，談論本週進度如何由 32% 進步到 35% 完成，可以如期在 12 月 25 日發行。不要讓專案是否正常進行的想法影響到真正的事實。另外不管有多希望老闆贏，千萬別讓他用 Callaway 的鈦製木桿，美國高爾夫協會已經禁止這種球桿，這真是不公平啊。