需求评审：如何让会议不变成吵架

微信扫一扫，分享给好友

关闭

需求评审会，产品经理最害怕的场景：

你讲了20分钟需求，研发说「这个需求背景是什么？」测试问「这个异常场景怎么处理？」设计师说「这个交互做不了」。

30分钟的会开了90分钟，需求还没过。

策略一：会前做好「预热」

不要把评审会当成「首次亮相」。在正式评审前，做以下准备：

准备一：提前1-2天把需求文档发给参会人，要求提前阅读。

准备二：和关键研发人员1对1沟通，了解技术可行性，提前解决明显的问题。

准备三：准备好「为什么做」的论证。需求评审不是「讲功能」，而是「说服大家这个功能值得做」。

策略二：会中控制好节奏

节奏一：先讲背景和目标（2分钟）

不要一上来就讲功能细节。先回答：这个需求解决什么问题？不做会有什么影响？

节奏二：再讲方案和范围（5分钟）

简要描述方案，明确本次需求的范围（做什么、不做什么）。

节奏三：重点讨论风险和疑问（15分钟）

把大部分时间留给讨论。主动问：「技术上有什么风险？」「测试覆盖有什么难点？」

节奏四：明确结论和下一步（3分钟）

结束前，明确：需求是否通过？如果有问题，谁负责跟进？什么时候再次评审？

策略三：处理反对意见的技巧

技巧一：区分「技术不可行」和「实现成本高」

如果是技术不可行，需要调整方案。如果是实现成本高，需要评估是否值得投入。

技巧二：用数据说话

当有人说「这个需求不重要」时，用数据回应：「这个需求影响30%的用户，目前因此流失的用户每月约500人。」

技巧三：学会「 defer」

如果某个问题当场解决不了，不要硬撑。说「这个问题我需要再调研一下，明天下午之前给你答复。」

策略四：会后及时跟进

评审会结束只是开始。24小时内发送会议纪要，包含：

• 通过的决策
• 待跟进的事项和负责人
• 下次评审的时间

写在最后

需求评审会的本质不是「过需求」，而是「对齐认知」。产品经理的目标不是「赢」，而是「让团队理解并认同这个需求的价值」。

当你的目标从「说服」变成「对齐」时，你会发现评审会变得顺畅很多。