如何做好需求评审？

作为一个产品经理，准备需求评审是产品设计开发的一个重要环节。那么如何做好需求评审呢？

一、原型准备阶段

(1) 需求细节尽量描述详细

详细即逻辑清晰、无遗漏、页面整洁、表达清晰等。最好能做到不清楚需求的人，通过文档也能理解要完成的任务。

(2) 对以前有的功能的修改要说明功能差异

如果是该功能迭代优化，那涉及其相关的需求要在会上说明：原先功能整套流程是怎么样的，现在针对哪个环节进行升级迭代。

(3) 设计功能或者逻辑一定要有根据有思考

记住我们设计的每个功能都要有理有据，不能想当然，不能做需求的搬运工。

(4) 设计过程中遇到技术难点、技术知识盲区，一定要和技术去沟通

当你遇到把握不准自家技术能不能实现自己功能，可以找到技术负责人把自己的想法提前说给他听，提前一起讨论实现过程，或许让他们评估且及时制定方案。

二、评审前的准备

(1) 产品内部评审

如果是比较大的项目，可能是多个产品经理一起负责，那么最好是产品部门内部开一个小评审会，把大致逻辑、功能统统讲一遍，看看有没有遗留的，有没有补充的。

(2) 业务部门会议

还是属于比较大的项目，跟业务部门开会主要目的是让他们了解产品部门做的东西是不是符合他们预期效果。

(3) 提前把原型或者需求文档发给技术人员

在需求评审会议的前一天，可以把原型和需求文档发送给参会的相关人员，目的是让他们提前熟悉需求。若有问题及时收集，在需求评审之前向提问者解答，能大大提高需求评审会的效率。

三、评审中 - 控制节奏、应万变

需求评审的过程，本质上就是沟通，用语言配合原型文档的方式，将需求、逻辑清晰的表述出来，然后和所有人基本达成一致意见。

注意不要忽略以下方面：

(1)项目背景

需求来自哪个人或者哪个部门等，他们遇到什么问题了？【现状】，针对这些问题，采用什么方案或者增加什么功能，来解决他们遇到的问题或提升什么体验及指标等；【预期】

(2) 收集合理的意见、想法

针对于这种意见，可能会给我们后续迭代有一定的启发，但是不一定要放在本次需求内。需求总有优先级排序的，应当先解决眼前紧急的问题。

(3) 不要过度纠结细节讨论

细节是永远都扣不完的，如果在会议上陷入细节的讨论，不仅浪费大家时间，而且对于产品经理来说也会非常痛苦。这时候你可以制止那人，让你把这块功能讲完，再让大家提问题，实在有人要聊细节，建议在会后和他单独好好讨论，产品经理始终要记住把控会议时间和节奏。

(4) 发现逻辑漏洞后及时修正

如果对业务了解不够深入，思考不周全，很容易被其他人发现逻辑或功能遗漏等问题，这对产品经理来说是属于比较严重的评审事故了，错了就要挨打。一般不是较大的逻辑问题，评审会议还是能继续开下去的，会后应当及时补充内容。

(5) 不要把会评审成技术方案讨论会议

每当遇到某些功能，对于技术来说实现比较有挑战性或者很感兴趣的时候，他们就会不知不觉的开始讨论用什么方法实现好，该如何如何去操作，留下一脸懵逼的你。这时候你要打住他们，如果逻辑没问题，怎么实现是技术的问题，不允许在会议上占用太多时间来讨论具体方案。

(6) 如果技术说“这个实现不了”

技术们这样的回应时，想必大家也遇到过，不要慌，之所以这么回应，绝大情况下是背后有一个巨大的开发量，或者是时间紧张。

首先呢，我们要确认技术们的难点在哪里，是需要更多的开发时间呢，还是真的有一定开发难度。综合各方面因素，考虑是否值得这样的投入？如果真的是一个很重要的功能点，可以说清楚该功能对整个业务的重要性，就算开发复杂、难度高，需要较多的时间也可以接受。如果还是争论不止，那把这问题暂时放一下，会后叫上技术负责人和该项目开发人员一起在讨论，切记也不能占用要多时间。

四、评审后 - 查缺补漏、保持跟进

需求评审会议结果后，我们还不能如释重负，还有事情要做呢:

(1) 及时修改问题

(2) 督促排期，跟踪进度

(3) 需求评审复盘

五、总结

在会议中，产品经理被针对是很正常的情况，做好充分的准备，才能应对各种突发事件。