需求评审：别只听产品讲，主动塑造需求

需求评审会上有两种工程师。一种全程沉默，产品说什么就记什么，最后问「还有问题吗」，他说没有，回去照着做。做到一半发现需求有坑、互相矛盾、或者技术上根本做不了，再回去找产品改，双方都不开心。

另一种工程师，在评审会上主动提问、质疑、提替代方案。他会说「这个需求背后的真实目的是什么」「如果换成这样做，效果一样但成本低一半」「这个边界条件下会出问题，得定义清楚」。需求评审结束，方案比产品最初的版本合理得多，做起来也顺畅得多。

两者的差距不在技术，在对需求评审这件事的认知。前者把自己当成实现需求的工具，后者把自己当成塑造需求的合作者。后者更值钱，因为开发中绝大多数问题，是业务了解不细致导致的。这篇讲怎么从被动接单走向主动 shaping。

先搞清楚，需求背后的真实目的是什么

图：把产品给的「解决方案」还原成「问题」，才能判断有没有更好的解

产品给的需求，往往是一个「解决方案」，不是「问题」。他说「我要一个导出功能」，但真实的需求可能是「运营月底要出报表，现在手动整理太慢」。

如果你只盯着「导出功能」去实现，可能做出来一个不好用的导出。如果你追问到「运营月底出报表」这个真实目的，可能会发现，比起导出，做一个定时生成的报表推送，或者一个可视化看板，更能解决问题。

所以在评审会上，第一个要问的是，「这个需求要解决的业务问题是什么」。把产品给的「解决方案」还原成「问题」，然后一起判断，这个解决方案是不是最优的，有没有更好的。

这不是抬杠，是帮产品把需求想透。好的产品经理欢迎这种追问，因为他们也知道，需求描述和真实目的之间经常有偏差。

这是工程师在需求评审里的本职，但很多人做得不到位。

可行性把关。这个需求技术上能不能做、好不好做、有什么风险。有些需求看起来简单，技术上涉及复杂的改造成本。有些需求在当前架构下做不了，需要先做基础设施的改造。这些要在评审时就讲清楚，而不是接了之后才发现做不了。

成本评估。每个需求都有实现成本，要把成本量化出来。这个功能简单做要 3 天，做好要 2 周。这个需求需要改 5 个模块，那个需求只需要改 1 个。把成本摆出来，让产品基于成本和价值做优先级判断，而不是默认所有需求都要全量实现。

识别隐含的技术债。有些需求如果「正确地做」，会暴露出系统里之前欠的债。这时候要讲清楚，要么先还债再做需求，要么接受一个打补丁的实现，两者都行，但要明确选择，不能糊里糊涂地埋雷。

图：系统的大部分复杂度和 bug 都藏在边界里，评审时主动挖出来逐条确认

产品给需求的时候，通常只描述了「正常路径」，happy path。但系统的大部分复杂度和 bug，都藏在边界和异常里。

评审时要主动把这些挖出来问。空值怎么办，输入超长怎么办，并发操作怎么办，操作到一半失败了怎么办，权限不够怎么办，依赖的服务挂了怎么办。这些场景，产品不一定想得到，但你不问、不做定义，开发时就会自己瞎做，做出来的行为不可预期。

把这些边界情况一条条列出来，和产品确认每个情况期望的行为。这个过程本身就是在帮产品完善需求，也是在降低后续返工的概率。

不要假设，要确认

评审时不确定的，宁可多问一句也别假设。一个「我以为是这样」的假设，到测试或上线时往往就是个 bug。把所有模糊的地方都确认清楚，哪怕显得啰嗦。确认了写进文档，后面就有了依据。开发中最贵的错误，几乎都是「我以为」造成的。

主动 shaping 不等于抢产品的活。你提建议、提替代方案、指出问题，但最终需求怎么定，是产品的决策权。

提替代方案要有依据。不是「我觉得这么做更好」，而是「这么做的效果一样，但成本只有三分之一」或者「这么做的用户体验更好，因为用户实际的操作路径是这样的」。用事实和逻辑支撑，而不是个人偏好。

接受产品不接受你的建议。你提了方案和理由，产品综合考虑后还是选了原来的，那就尊重他的决策。可能他有你不了解的业务考量。记录下你提过的建议和理由，万一后面验证你的方案更好，也有迹可循。

最忌讳的是两种极端。一是完全不提，闷头接需求，这是失职。二是强推自己的方案，和产品对抗，这是越界。健康的姿态是，充分表达专业意见，然后支持团队的最终决策。

需求评审不只是「接需求」，也是技术人输出洞察的机会。

在评审中，你可能会发现产品没想到的点。「如果我们顺便把这部分的数据结构化，以后做数据分析会很方便，未来可能省很多事」「这个功能其实可以做成通用的，下次类似需求就不用重新开发了」。

这些是从技术视角看到的产品机会。把它们提出来，产品往往会觉得有价值，因为技术人对系统的理解深度是产品没有的。这种反向输出，是技术人影响产品的最高级形式，不是被动接需求，而是主动创造需求。

图：从接单者到合作者，是把「写代码」升级为「影响产品方向」的关键转变

需求评审的本质，是产品和技术的协作，不是甲方和乙方。

接单者心态把产品当甲方，自己当乙方，甲方说啥我做啥。这种心态下，需求质量取决于产品一个人，技术人的专业判断完全浪费了。

合作者心态把需求评审当成共同打磨方案的过程。产品懂业务和用户，技术懂可行性和成本，两边合起来才能产出真正好的需求。技术人的价值不只是把需求实现出来，还包括帮需求变得更合理、更可实现、更解决问题。

一旦完成了这个心态的转变，你会发现需求评审不再是负担，而是你影响产品方向、减少后续返工、体现专业价值的最好机会。而你的不可替代性，恰恰来自于这种「不只是会写代码」的能力。