需求澄清走了两年弯路，总结出这几条

有些事，做过了才知道当初想错了。

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

回头看，当初有几处判断是错的，而且错得很有代表性。

这篇不复述方法，只复盘需求澄清：以为会怎样、实际怎样、差在哪。

以为会怎样，实际怎样

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

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

差别不在于谁更努力，在于有没有先想清楚这件事的验收标准。想清楚了，动作自然就少。

如果重来一次，我会先花十分钟写清楚『做成什么样算完成』，再动手。这十分钟能省掉后面两小时。

现在会怎么做

这篇不复述方法，只复盘：以为会怎样、实际怎样、差在哪。

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

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

2. 复述一遍再动手

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

3. 问清三个边界

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

4. 要一个真实例子

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

5. 改需求要重新对时间

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

当初那个判断

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

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

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

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

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

几个常被问到的问题

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

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

问：要多久才能见效？

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

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

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

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

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

明天就能做的事

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

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

可以直接用的一段话

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

请把这段需求整理成：要解决的问题、本次范围、不包含什么、验收标准、时间影响。

最后

复盘不是为了后悔，是为了下次少花点时间。把结论写成一条规则，比记住感受有用。

复盘到最后落到动作上，就是这一条：下次接需求先复述一遍再动手。