需求澄清总是不顺，恰恰是因为你太认真

先看一句你可能听过的建议。

做完了对方说『这不是我要的』。

这句话不算错，但它只在一个前提下成立——而这个前提，很多人的场景里并不满足。

先把需求澄清这件事的真实机制说清楚，再讲怎么做。

先说说那个流传很广的说法

只问『你要什么』。用户说的是方案，不是需求。

这句话之所以流行，是因为它在某种情况下确实成立。但很多人把它当成通用规则，结果就是用错了场合。

真正的机制是这样的：方法本身没错，错在它假设了一个前提——而这个前提在你的场景里不成立。

真正管用的做法

下面这几条，可能和你现在的做法相反。先别急着否定，看完再判断。

1. 复述一遍再动手

用你自己的话把需求说一遍，让对方确认。这一步能挡掉一半返工。

2. 问清三个边界

什么时候用、谁用、什么情况下不用。边界比功能更能定义需求。

3. 明确不做什么

范围蔓延是返工的主因。开工前写清这次不包含什么。

4. 改需求要重新对时间

不要默默加班消化。每次变更都说清对工期的影响。

一个真实的反例

一位设计师连续三版被打回。

做法是：第四次她先问：这个物料在什么场景给人看、看完要对方做什么。

结果是：问完发现前三次的方向都错了，第四次一版通过。

这个例子不复杂，难的是每次都这么做。可以照着做，也可以只挑其中一步先试。

整个过程里没有出现什么复杂工具，改的都是顺序和标准。这也是它能被复制的原因——不需要天赋，只需要不再省那一步。

几个常被问到的问题

问：照着做了，还是没效果，为什么？

答：不要在群里确认重要需求。口头和群聊都会失真，落到文档。 先回头检查这一条，多数时候问题在这里。

问：要多久才能见效？

答：第一周通常只是熟悉流程，第二周才开始省时间。如果两周后完全没感觉，回头看看是不是漏了第一步。

问：第一步该从哪里开始？

答：下次接需求先复述一遍再动手。从这一件开始，别一次全上。

问：最容易犯的错是什么？

答：拿到需求就开工。方向错了，做得越快越浪费。

几个容易踩的坑

这几条比方法更值得看，因为方法可以慢慢学，坑踩一次就要花时间填。

• 不要用『我理解了』代替复述。理解是自己的，复述是双方的。
• 不要接没有验收标准的需求。

明天就能做的事

不用全做，挑一件今天就能开始的。

• 下次接需求先复述一遍再动手
• 每个需求写三条验收标准
• 开工前写一句『本次不包含』

可以直接用的一段话

如果你平时用 AI 帮忙，下面这段可以直接复制，把方括号里的内容换成你的情况。

对方的需求原话是：X。请帮我列出还需要澄清的五个问题，重点问使用场景、边界和验收标准。

最后

反常识的说法值得听，但别急着全盘接受。拿一个你自己的场景试一次，比争论有用。

别急着推翻原来的做法，先试这一件：开工前写一句『本次不包含』。试完再判断。