给需求澄清一个七天的启动计划

如果你打算这周就开始，先看这一段。

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

别想太多，按顺序走，每天只做一件。

七天，每天一个动作，做完打勾。

七天，每天一个动作

第一天：问『你要解决什么问题』，而不是『你要什么功能』

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

第二天：复述一遍再动手

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

第三天：要一个真实例子

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

第四天：把验收标准写下来

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

第五天：回头检查有没有踩坑

把下面三条当检查表过一遍，中了哪条先改哪条。这一步不做，前四天白做。

• 不要用『我理解了』代替复述。理解是自己的，复述是双方的。
• 不要接没有验收标准的需求。
• 不要在群里确认重要需求。口头和群聊都会失真，落到文档。

第六天：把这几天做的整理成一页

不用美化，能看清自己做过什么、卡在哪就够了。这一页以后就是你的底稿，下次直接从它开始。

第七天：讲给一个人听，或者写成一段话发出去

讲不清楚的地方，就是还没真正掌握的地方。

第一周之后的样子

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

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

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

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

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

几个常被问到的问题

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

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

问：要多久才能见效？

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

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

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

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

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

几个容易踩的坑

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

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

明天就能做的事

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

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

可以直接用的一段话

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

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

最后

七天之后，你手上会有一个能用的版本。它可能不完美，但比停在计划里强。

第八天开始，把这件变成常态：开工前写一句『本次不包含』。