三十年前，一位新到香港的顾问，入职第一个星期，被人拉去看一套公司引以为傲的系统。坐下来，对方演示了一遍。看完只问了一句：这套东西是怎么定出来的？回答他的不是解释，是事实本身——完全错了。数百万美元的投入，成百上千个工时，做出来的东西完全错误。被派来救火的这位，恰好就是最终要用它的人。最该被问的人，坐在问题问完之后。
猜不是错，猜到底才是
有人说，IT 也在尽力猜，猜错不等于失职，需求本来就说不清。需求确实说不清——用户讲得出现在的痛，讲不出未来的形，这一半认了。可正因为说不清，代价该换来更早、更碎的确认：问一次，改一版，再问一次。而不是猜了一整轮、建到完工，才第一次把成品推到用户面前。错不在猜，在猜到底。说不清的需求，要的是更密的确认节奏，不是不来问。
沉默是训练出来的
也有人翻出当时的原话：为什么不问问真正要用它的人？答曰：他们不想参与。听着像用户该背锅。可用户的沉默是设计出来的——问过白问的历史，教会他们不开口。提了没下文，改了没反馈，一次一次，人就学会了省下力气。让人愿意开口，是项目的第一笔投资，不是用户的义务。没人投资这件事，就没人开口；没开口的系统，每一个格子都是猜的。这套通用规律见了太多次：公司先把钱投了，原型照着猜出来的需求做，最后彻底走样——出错的根源都不在技术，在最终用户从头缺席。
新工具装着旧缺席
还有人说，敏捷、MVP 时代早解决了，这是三十年前的旧事。工具更新了，缺席没更新。MVP 若仍由猜需求的那批人设计，只是把一个大错误切成一串小错误再连发——试错的节奏快了，靶子还是别人替用户画的。补救的门道其实在那家跨国公司自己的账上：新市场先在小地方试水，巴布亚新几内亚跑一遍，全砸了也不伤筋骨——试错的前提是失败输得起。军队那句老话，没有计划能在与敌人初次接触后存活，讲的同一件事：接触之前的一切都叫假设。靶子得由中弹的人画，才画得准。
上线之后，错误就成了事实
那就先建起来再改，进度就是价值？数百万美元买来的那个"完全错误"，最贵的账不在返工。它一旦上线，就长成了正确的形状：流程围着它走，报表照着它出，后来的人把它当成要被维护的事实。改一套没人用过的系统，难；改一套全公司在用的错误系统，难十倍——因为它错了很久，久到像对的。用户要摸上一百多个小时才能真正上手，学错的成本和学对的成本一样贵，而学费只交一次。
问过谁，错多深
这类失败不是技术失败，是缺席失败：需求由谁起草，决定系统错得多深。判断一套系统会不会成，别看演示，看草稿——草稿上有没有最终用户的手印。没有手印的，不是系统，是猜谜。猜对了是运气，猜错了是数百万美元。顺带一笔账：项目预算五十万、工期六个月，最后七十五万、九个月走完——项目成果是负的，业务成果仍可能是正的，两本账分开记，才知道钱输在哪、赢在哪。三十年来看着工具换了几代，这一条没换过：没人问过的问题，迟早要连本带利地答。
