用户说“做个排行榜”，其实他想要的不是排行榜

“帮我做个排行榜。” “加个导出功能。” “首页，再大气一点。”

这类话在项目周会上出现的频率，比我们想象的高。它本身不是问题——业务方凭直觉提需求，天经地义。麻烦出在接下来的那一刻：如果我们用一句“好的，我看看”就把话接了过来，需求就带着全部的模糊，一路滑过设计、开发、测试，直到验收会上才炸开——这不是我要的那个感觉。

返工、扯皮、加班，根子多半在这里。下面这套四步法谈不上新鲜，却是我们做了这些年项目，最常用来把模糊诉求翻译成可验收目标的老办法。

先把“方案”还原成“问题”

人本能地先想解法。业务方说“做个续费提醒弹窗”，其实真正让他头疼的是“用户总忘记续费”。

照着字面做，你会得到一个弹窗；而它的命运，多半是上线之后被用户勾上“不再提示”。可要是回到问题本身，路一下子就宽了：也许是到期前三天的一条短信，也许是账单页上提前的一句说明，甚至只是把扣款日挪到发薪之后。

同一句需求，往下多挖一层，答案往往就换了一批。所以我们说的第一步，从来不是动手，而是往回问。

四步，把模糊的话变成能验收的目标

一、先还原场景，别急着记录功能。 用四个问题逼出真相：谁在用？在什么场景下？遇到了什么具体的麻烦？现在是怎么凑合过来的？这四问答不上来，说明需求还没成形——这时候动手，做的是我们自己的想象。

二、把“必须有”和“想要有”分开放。 拿张纸分成两栏。少了它就解决不了问题的，进左栏；只是“有了更好”的，进右栏。项目延期，大多不是做不完，而是右栏塞得太满——它们总在最紧张的时候，一点点吃掉左栏的时间。

三、把形容词换成数字。 “好用”“大气”“快一点”，这些词一个都不该带进验收单。翻译成能测的说法：三步之内完成、首屏加载低于两秒、续费率提升十个百分点。写不出数字，通常不是要求不严谨，而是需求本身还没想清楚。

四、用自己的话复述一遍，让对方拍板。 “你要的是把老客户的续费率提上去，所以在到期前三天提醒一次，对吗？”对方点头，才算真正对上；对方一改口，那更好——你在开工之前，省下了整轮返工。

这一步做扎实，后面才谈得上快

产品不必急着画原型，先把问题问透；开发看到验收标准含糊，可以先停一停；业务方也不用急着抛方案，多问自己一句“我到底想解决什么”，往往比多提三个功能更管用。

很多项目不是输在最后，而是输在最开始。需求工作拼的就是这一点落地密度——把一句“做个 XX”，变成清楚的“为谁、解决什么、怎么算成了”，项目就已经赢在了起跑线上。

至于需求对齐之后，经验怎么留下来、又怎么装进系统，那是另外两篇要聊的事。