大部分人刚开始做产品经理时，都会经历过需求评审会上被多方Diss的场景。这篇文章，作者分享的经验，可以帮你平安度过。

产品新人面临的第一个难关就是需求宣讲总被开发Diss怎么办？本文从三个角度解答。

1. 需求评审是什么
2. 好的需求评审的标准
3. 可能遇到的问题及应对办法

一、什么是需求评审

• 通常是一个会议：会上由产品经理传递产品方案和结论，让开发、测试都了解需求的细节和最终设计方案。避免开发辛辛苦苦写完代码，结果跟产品输出的方案大相径庭，导致双方撕逼打架。
• 需要什么：PRD文档+低保真模型/高保真模型
• 参与人包括：前端、后端、测试、UED、SE（架构师）、算法工程师（可选）等。

二、好的需求评审的标准

分点陈述，思路清晰，要求明确。

• 文档逻辑全面：产品更像规则的制定者，方案需要覆盖所有场景，包括功能影响范围、页面/功能流程、按钮交互逻辑。（这个要跟开发提前沟通）。
• 后台逻辑完整：比如涉及的接口和查询逻辑，异常情况判断。
• 演讲有重点：开会的时候技术可能没那么认真去听，所以一定要讲重点。必要时可以点名提问。

注意：⚠️会议是同步结论，而不是讨论。在会议主要讨论产品方案，技术问题是技术实现的问题，讨论角度不要跑偏。

三、可能遇到的问题及应对办法

会上一定会被开发质疑方案、甚至被你的产品同事质疑方案，这个时候要内核稳定，精准过招出击。

1）这个功能为什么要做？/做这个功能有什么意义？

——问题拆解：问出这个问题，多半表明开发不愿意接受你的需求，可能是出于工期太满、难度太大、功能复杂的原因。这时候我们要给出一个答案，让开发自己说服自己，这个需求是有意义的。

——应对策略：需求来源+优先级+功能价值+实现成本

——例子：

这个需求是XX领导提的（来源），希望能在10月份上线（优先级），有了这个功能之后用户可以实现学生认证，拿到多种权益，带动学生群体销量（功能价值）。工作量也不大，评估了是10个人天左右（实现成本）。

2）这个功能为什么要这么做而不是那么做？

——问题拆解：开发觉得你的方案复杂，有更优解。

——应对策略：

1. 会前：一定要穷尽所有方案，考虑利弊，并可以提前和对应的开发沟通。
2. 会中：理智阐述自己的想法，并询问开发他觉得更好的方案是什么，并展开讨论。方案影响因素：用户体验、功能影响范围、复用性等等。
3. 会后：如果方案还有争议，会后再跟开发沟通。（此条不建议，优先把问题在会上解决是最高效的）

3）比问题多更可怕的是没问题！！

不怕开发提问，就怕开发不提问！这说明可能开发没有认真听你的方案！因为再简单的功能，都一定会有一些点是你可能没考虑到的。所以遇到没人提问要及时调动情绪，甚至可以点名对应的开发，看看对功能的理解是否到位。

四、真实案例

案例一：

刚开始做产品时，只知道自己埋头苦捋功能流程，梳理完之后再自己做一个设计出来。只跟产品沟通，没有跟技术沟通就上了评审会，结果因为功能逻辑漏洞太多，被驳回，开了二次评审。后续在开会前都会反复check方案的完整性、合理性，与至少一位开发沟通后再上会。

案例二：

功能有争议时，被技术一怼，就会被带跑偏，跟着技术的方案走。有时也会被领导带着走，他说啥就是啥。没有自己的立场。比如，一个欢迎弹窗，可放可不放，有人质疑太麻烦，我就不放；一个卡片样式，有图无图都可以，一旦被质疑，我就会跟着对方的节奏走。被带教的产品说，“产品要有自己的态度，一定要强势，不能被轻易改变”。只有你才能对用户负责，一些可做可不做的功能，一定要想清楚做不做，然后坚持自己的看法。

五、好的PRD文档参考

对产品来说，永远是思路>文档，但是一个好的文档可以反过来帮你check思路是否完整。