客户需求案例

去年夏天，客户一个做餐饮的需求客户找到我，说想开发一套扫码点餐系统。案例他张口就要“功能齐全”，客户我问他具体要什么，需求他掰着手指头数：会员积分、案例优惠券、客户外卖对接、需求后厨打印、案例排队叫号。客户我听完没急着报价，需求先问了一句：你现在店里几个服务员？案例他愣了一下，说两个，客户加上他自己。需求

这就是案例问题所在。两个服务员的小店，搞一套需要专人维护的会员系统，等于给自行车装飞机引擎。我见过太多这样的需求——客户把“想要”当成了“需要”。

后来我让他做了一件事：拿张纸，把每天店里最让他头疼的三个场景写下来。他写了：高峰期点单排队、老客户记不住口味、外卖平台抽成太高。我说好，那我们就解决这三件事。会员积分？砍掉。优惠券？暂时不做。排队叫号？两个服务员忙得脚不沾地，叫号机响了谁去按？

最终方案很简单：扫码点餐直接下单到后厨，老客户扫码后自动显示上次点的菜，外卖只做自提不接平台单。开发成本从最初预估的六万降到一万八。上线那天他给我发了张照片，后厨打印机旁边贴了张纸条：“别催，按顺序来。”他说现在高峰期能多翻两次台。

这个案例我经常拿出来讲，因为它暴露了一个普遍现象：客户提需求时，往往在描述解决方案，而不是问题本身。他说要“会员积分”，真实需求可能是“让老客户觉得被记住”；他说要“外卖对接”，真实需求可能是“不想被平台抽成”。如果你直接按他说的做，最后交付的是一堆功能，不是价值。

还有一个做服装批发的客户，要求开发一个库存管理软件。我问他现在怎么管库存，他说用Excel，但经常出错。我让他打开表格看看，发现他所谓的“出错”是颜色和尺码对应不上，比如红色M码实际有货但表格显示缺货。问题不在软件，在于他录入时就用错了编码规则。

我建议他先花两天时间重新整理货号体系，再谈软件。他不理解，觉得我在拖延。我说你现在的数据，就算给你一套ERP系统，跑出来的结果还是错的。他勉强答应了。两周后他打电话说，整理完货号发现积压了三十万的旧款，以前根本看不出来。

你看，客户要的是“管理软件”，实际需要的是“看清库存”。这两者之间隔着一层——数据质量。很多技术团队不愿意碰这一层，因为不赚钱，还容易扯皮。但跳过这一层，项目基本会烂尾。

我自己的判断标准很简单：如果客户说不清“现在怎么解决这个问题”，那他的需求就是模糊的。这时候不能急着写代码，得先陪他把现状捋一遍。有时候捋完发现，根本不需要开发，换个流程就行了。比如那个餐饮客户，最初还想做“智能推荐菜品”，我说你连客户口味数据都没积累，推荐什么？推荐你昨天剩的菜吗？他笑了，这事就过去了。

写这些不是要否定客户。恰恰相反，客户比谁都清楚自己的痛点，只是他们习惯用技术名词包装痛苦。技术人员的价值，是把那些名词拆开，找到里面的血肉。拆错了，做出来的东西就是一堆漂亮的废铁。

上周那个餐饮客户又找我，说想加个“会员储值”功能。我问为什么，他说隔壁店在搞，充五百送五十，客户都跑那边去了。我说你确定你的客户是因为储值跑的？他想了想，说好像是因为隔壁上菜快。我说那你要不要先看看后厨动线？他沉默了几秒，说“你等我再观察几天”。

这就对了。需求不是问出来的，是看出来的。