需求澄清最实用的 6 条，我用了很久

先看一个常见的场面。

改了三版，每版方向都不一样。

这类问题翻来覆去就那几个，所以这篇不铺垫，直接给能用的。

下面这六条，是我筛过之后留下的。不追求全，只追求能用。

为什么会卡在这里

先看看多数人是怎么处理的。

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

多数人卡住，不是因为不努力，是因为没人把步骤的先后讲清楚。一头扎进去做，做到一半才发现方向错了，返工的时间比第一次做还长。

下面这套顺序，是我试过之后留下来的。它不一定最聪明，但每一步都能马上动手。

六条，可以直接抄

每条一句话说清做什么、为什么。可以全做，也可以先挑一条试。

1. 问『你要解决什么问题』，而不是『你要什么功能』

对方说『加个导出按钮』，真实问题可能是『每次都要手抄到另一个系统』。

2. 问清三个边界

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

3. 要一个真实例子

『上次出现这个问题是什么时候，能给我看一下吗』。例子比描述准确十倍。

4. 把验收标准写下来

『什么样算做完』写成三条可检查的句子，双方确认。

5. 明确不做什么

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

6. 改需求要重新对时间

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

照着做的一个例子

某开发接了一个『简单改一下』的需求。

做法是：他让对方写清验收标准，结果发现有五种边界情况。

结果是：提前说清，避免上线后返工。

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

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

几个常被问到的问题

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

答：不要用『我理解了』代替复述。理解是自己的，复述是双方的。 先回头检查这一条，多数时候问题在这里。

问：要多久才能见效？

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

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

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

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

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

明天就能做的事

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

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

最后

清单的价值在于用，不在于存。今天挑一条，试完再说下一条。

清单第一条，今天就做：下次接需求先复述一遍再动手。