别急着写代码，先把需求翻译成人话

产品经理走过来，拍了拍你的肩膀：”帮我加一个导出Excel的按钮。”

你点点头，心想这不就是个导出功能嘛，小case。打开编辑器，查文档，写SQL，处理格式兼容，调了两天样式——因为产品说”要好看一点”。第三天终于提测了，你满怀期待地@了他。

他打开页面，点了一下，沉默了三秒钟，说：”这不是我想要的。”

你：”？？？”

他：”我想要的是每天自动把报表发到老板邮箱里。”

你看了看自己写的三百行导出代码，又看了看他，有一种想把git log里最近三天的commit全部revert掉、连带自己人生也一起revert的冲动。

这个场景你经历过吗？如果你是开发者，大概率经历过不止一次。如果你是产品经理——你可能就是那个拍肩膀的人，但你真的不是故意的。

先别急着互相甩锅。我今天不是来拉偏架的，开发群和产品群我都潜伏过，双方的怨气我都见过。我想说的是：这事可能真的谁都没错，但你们都踩进了同一个坑里——而这个坑，每年吞掉的开发工时比任何一个技术债都多。

需求文档里写的，往往不是”需求”

很多开发者有一个根深蒂固的信条：需求文档上写什么，我就做什么。PRD说”加导出按钮”，那我就加导出按钮。至于为什么要加——我管那么多干嘛？你让我搬砖我就搬砖，你总不能怪我砖搬得太整齐吧？

听起来很专业，对不对？分工明确，各司其职。

但这个”各司其职”里藏着一个巨坑——因为PM写在文档里的，绝大多数时候根本不是”需求”，而是”他脑子里蹦出来的第一个解决方案”。

“导出Excel” ← 这是解决方案。 “老板想每天看运营数据” ← 这才是需求。

一个是”怎么做”，一个是”为什么做”。区别在哪？区别在于——如果你知道了真正的需求，解决方案可能完全不同。老板想每天看数据？那搞个定时邮件推送不就行了？甚至公司现成的BI工具配一下就完事了，根本不用你写一行代码。

但你没问。你接到”导出Excel”这四个字，就像收到一条Jira ticket一样，”状态”直接从”待评估”拖到了”开发中”。干了三天，才发现自己跑了一场方向完全相反的马拉松。

这不怪你手速太快，也不全怪PM嘴上没把门。这是一个结构性的沟通陷阱：提需求的人习惯把”解决方案”伪装成”需求”来传递，而接需求的人习惯照单全收——毕竟多问一句，搞不好还被怼”你做不了就说做不了”。

将近一半的功能，生下来就是为了被抛弃的

你以为只有你们团队有这个问题？

Standish Group做过一个长期跟踪调研，覆盖了大量软件项目。结论扎心：软件产品中，有将近一半的功能在交付后很少甚至从未被用户使用过。

你花了一个冲刺周期做出来的功能，上线三个月后，打开率可能还不如你写的那个404页面。

不是因为做得丑，不是因为有bug，是因为一开始就不该做。

这个现象的根源你已经猜到了——需求在传递过程中发生了”失真”。就像小时候玩的传话游戏：第一个人说”今天天气不错”，传到最后一个人就变成了”今天晚上吃火锅”。

看这个链条：

老板觉得数据看得不方便 → 跟PM说”搞个数据导出” → PM在PRD里写”新增导出Excel功能，优先级P1” → 开发者排期三天实现了一个完美的、支持多Sheet、带筛选条件的Excel导出 → 老板用了一次，嫌每次还得自己点，再也没打开过。

每一个环节的人都觉得自己做对了。老板反馈了需求，PM落了文档，开发写了代码。但最终结果是：三天的开发时间打了水漂，一个精心制作的按钮永远躺在页面角落里吃灰，和旁边那个”帮助中心”的链接作伴。

这不是谁偷懒的问题，是需求”翻译”链条断裂的问题。 “问题”在传递中变成了”方案”，没有人在中间按一下暂停键做一次反向追问。

程序员应该像医生一样”接诊”

说到这里你可能想：道理我都懂，但我一个写代码的，总不能教产品经理怎么写PRD吧？

你还真可以。不过换个方式。

你去医院，跟医生说：”给我开盒头孢。”

靠谱的医生会怎么做？直接给你开？不可能。他会问：哪里不舒服？疼了多久了？发不发烧？之前吃过什么药？

为什么？因为你说的”给我开头孢”不是病情描述，是你百度完之后的自我诊断。你可能只是嗓子发炎，含片就够了；也可能是病毒感染，头孢压根没用——吃了白吃，还伤肝。

病人给的是”自拟药方”，医生要做的是透过药方找到”真正的病因”。

PM跟你说”加个导出按钮”，本质上就是病人在说”给我开头孢”。他给你的不是问题，是他自己想出来的解药。你要是直接照方抓药，大概率开错。

你要做的是”接诊”——PM告诉你的是症状（我想要XX功能），你得找到病因（用户在什么场景下被什么问题卡住了）。

这不是质疑PM的水平。说实话，很多时候PM自己也没完全想清楚——deadline催着、老板压着，他把脑子里第一个蹦出来的方案写进了文档，就当需求发出去了。你帮他往回问一步，很可能两个人花十分钟就找到一个更简单的方案，省下来的时间大家都早点下班。

拿到需求后的三个必问

好，说了半天”不要直接干”，那到底该怎么干？给你三个问题，下次PM甩需求过来的时候，先别急着打开IDE评估工时，先把这三个问题问出去。

第一问：”这个功能解决的是谁的什么问题？”

这是最基本的一个问题，但大量需求文档里压根没写。

你可以这样问：”这个导出Excel，是给谁用的？运营？老板？客户？他们在什么场景下需要？多久用一次？”

如果PM能清清楚楚地回答——”运营小王每周一要给老板出运营周报，现在是手动从后台一个个截图”——恭喜，这是一个想清楚了的需求，可以干。如果他支支吾吾、东拉西扯——”就…大家可能会用到吧”——那你可以微笑着说：”要不咱先确认一下具体场景，我怕做出来不是大家想要的。” 答不上来就说明需求还没熟透，先别急着下锅。

第二问：”如果不做这个功能，用户现在怎么凑合的？”

这个问题杀伤力极大，但极其有效。

它帮你判断一件事：这是”止痛药”还是”维生素”。如果用户现在已经有了凑合的办法——手动截图、用第三方工具、甚至自己写了个Python脚本——那这个需求的优先级可能没那么高，至少没到P1。

但更有价值的是，用户现有的凑合办法里往往藏着真正的解法。”原来运营每天花半小时手动从后台复制粘贴数据？那我搞个自动定时推送，是不是比让她多一个’导出按钮’更解渴？”——瞧，方案自己就冒出来了。

第三问：”我们怎么知道这个功能做成功了？”

这个问题最容易被忽略，但可能最重要。

“做完了”和”做成功了”是两码事。代码merge了、没有bug，这叫做完了。但用户真的用了吗？问题真的解决了吗？如果没有人提前定义什么叫”成功”，那你做完之后产品经理满不满意，完全取决于他那天中午吃了什么。

你可以这样问PM：”上线之后，我们看什么指标来判断这个功能有没有用？”好的回答是这样的：”运营每周手动处理数据的时间从5小时降到1小时。”有了这个标准，你做的时候有方向，上线后有判据，复盘时有依据。

没有衡量标准的需求，就像没有终点线的赛跑——你永远不知道自己跑到了没有。

那个”导出Excel”，10分钟就能解决

回到开头那个让你差点砸键盘的故事。

如果你在接到”加一个导出Excel按钮”的时候，没有直接打开编辑器，而是先问了三个问题：

“解决的是谁的什么问题？”——老板想每天看运营数据。

“不做的话他现在怎么办？”——运营每天手动截图发微信群，老板还经常催。

“怎么算做成功了？”——老板每天早上9点前能看到前一天的关键指标，不用再催人。

三个问题问完，真正的需求浮出水面了：老板要的不是Excel，是每天准点看到数据。解决方案？公司现成的BI工具配一个定时邮件推送，10分钟搞定。你的三百行代码？一行都不用写。

省下来的三天干什么？做真正重要的需求，或者——摸鱼也行，至少你不用加班改一个从一开始就做错了的功能。

这三个问题不是什么需求分析大师的独门秘籍，就是一个简单的习惯——在动手之前，多花五分钟搞清楚”到底要解什么题”。

写了十年代码的老程序员跟我说过一句话，我觉得可以当座右铭：写代码之前，最值得写的那行代码是一个问号。

PM不是你的对手，需求文档也不是不可质疑的圣旨。当你学会从”接单员”变成”翻译官”，返工会变少，加班会变少，你跟PM之间的关系——说不定还能从”互相甩锅”进化成”互相补位”。

别急着写代码。先把需求翻译成人话。