三十年前，一位新到香港的顧問，入職第一個星期，被人拉去看一套公司引以為傲的系統。坐下來，對方演示了一遍。看完只問了一句：這套東西是怎麼定出來的？回答他的不是解釋，是事實本身——完全錯了。數百萬美元的投入，成百上千個工時，做出來的東西完全錯誤。被派來救火的這位，恰好就是最終要用它的人。最該被問的人，坐在問題問完之後。
猜不是錯，猜到底才是
有人説，IT 也在盡力猜，猜錯不等於失職，需求本來就説不清。需求確實説不清——用戶講得出現在的痛，講不出未來的形，這一半認了。可正因為説不清，代價該換來更早、更碎的確認：問一次，改一版，再問一次。而不是猜了一整輪、建到完工，才第一次把成品推到用戶面前。錯不在猜，在猜到底。説不清的需求，要的是更密的確認節奏，不是不來問。
沉默是訓練出來的
也有人翻出當時的原話：為什麼不問問真正要用它的人？答曰：他們不想參與。聽着像用戶該背鍋。可用戶的沉默是設計出來的——問過白問的歷史，教會他們不開口。提了沒下文，改了沒反饋，一次一次，人就學會了省下力氣。讓人願意開口，是項目的第一筆投資，不是用戶的義務。沒人投資這件事，就沒人開口；沒開口的系統，每一個格子都是猜的。這套通用規律見了太多次：公司先把錢投了，原型照着猜出來的需求做，最後徹底走樣——出錯的根源都不在技術，在最終用戶從頭缺席。
新工具裝着舊缺席
還有人説，敏捷、MVP 時代早解決了，這是三十年前的舊事。工具更新了，缺席沒更新。MVP 若仍由猜需求的那批人設計，只是把一個大錯誤切成一串小錯誤再連發——試錯的節奏快了，靶子還是別人替用戶畫的。補救的門道其實在那家跨國公司自己的賬上：新市場先在小地方試水，巴布亞新幾內亞跑一遍，全砸了也不傷筋骨——試錯的前提是失敗輸得起。軍隊那句老話，沒有計劃能在與敵人初次接觸後存活，講的同一件事：接觸之前的一切都叫假設。靶子得由中彈的人畫，才畫得準。
上線之後，錯誤就成了事實
那就先建起來再改，進度就是價值？數百萬美元買來的那個"完全錯誤"，最貴的賬不在返工。它一旦上線，就長成了正確的形狀：流程圍着它走，報表照着它出，後來的人把它當成要被維護的事實。改一套沒人用過的系統，難；改一套全公司在用的錯誤系統，難十倍——因為它錯了很久，久到像對的。用戶要摸上一百多個小時才能真正上手，學錯的成本和學對的成本一樣貴，而學費只交一次。
問過誰，錯多深
這類失敗不是技術失敗，是缺席失敗：需求由誰起草，決定系統錯得多深。判斷一套系統會不會成，別看演示，看草稿——草稿上有沒有最終用戶的手印。沒有手印的，不是系統，是猜謎。猜對了是運氣，猜錯了是數百萬美元。順帶一筆賬：項目預算五十萬、工期六個月，最後七十五萬、九個月走完——項目成果是負的，業務成果仍可能是正的，兩本賬分開記，才知道錢輸在哪、贏在哪。三十年來看着工具換了幾代，這一條沒換過：沒人問過的問題，遲早要連本帶利地答。
