职场经验：【需求反讲】——一个让你远离“背锅”和“返工”的10分钟习惯

“我以为你要A，结果你做了B。” “我明明说得很清楚，你怎么做成这样？” 这两句话，应该是职场里出现频率最高的冲突导火索。我见过太多项目延期、同事反目，根源不是能力不行，而是信息在传递中的衰减。传递三次，准确率可能不到60%。我的应对方式极其简单：接到任何需求后，花10分钟做一次“需求反讲”。下面是我的三步法。

步骤一：重述——用自己的话复述一遍

不要点头说“好的”，不要回复“收到”。而是说：“基于刚才的讨论，我理解你需要的是……（用我自己的语言概括一遍）。” 这有两个作用：第一，确认你没有误解；第二，倒逼对方确认他的需求是否表达清楚。

举例：产品经理说“优化一下登录页面的用户体验”。你的复述可以是：“我理解，你是希望把登录页面的平均加载时间从2秒降到1秒以内，同时把注册按钮做得更明显，对吗？” 对方可能会纠正：“不，加载时间不是重点，重点是用户输错密码后，能一键找回密码。” 你看，一句话就校准了目标，避免了你去折腾图片压缩和CDN。

步骤二：量化——把模糊词汇变成数字

职场里最害人的词就是“尽快”“优化一下”“稍微改改”。你一定要逼对方给数字。继续上面的例子：“你希望登录流程从‘输入密码→点击登录→等待响应’的每一步，总耗时不超过多少毫秒？或者，你希望减少的是步骤数？” 量化的结果可能是：“从点击登录到进入主页，总耗时不超过1.5秒；找回密码流程不超过两次点击。”

量化还有一个好处：验收标准清晰。如果对方说“感觉有点慢”，你可以拿出当初约定的1.5秒来说事。

步骤三：确认边界——明确“这次不做哪些”

这是很多人忽略的一步。需求之所以会蔓延，往往是因为大家默认“顺便做一下这个也不过分”。你必须在最开始就划清边界。反讲时可以这样说：“我理解本次需求的范围是登录页面优化，不包括注册页面、密码修改页面，也不包括后端API的重构。这些是明确超出范围的，对吗？”

如果对方说“啊，我还以为你会顺便把注册页也调整一下”，你就有了谈判空间：“那需要另外排期，或者我们缩减登录页的优化范围。” 提前划界，比做到一半发现范围扩散要好一万倍。

一个真实案例

有一次运维同事让我“优化一下备份脚本”。我反讲：“你希望是缩短备份时间，还是减少备份占用的磁盘空间？” 他说“时间”。我再问：“当前备份耗时2小时，你的目标是多少？” 他说“30分钟内”。我又问：“如果压缩率降低但时间达标，可以接受吗？” 他说可以。最后我用并行压缩 + 网络直传代替本地压缩，做到了25分钟。如果我一开始埋头优化压缩算法，可能优化到1小时就卡住了，而且还是白忙活。