编辑导语：需求评审是产品经理非常“害怕”但是又不得不做的一个会议 ，因为在评审会中，产品经理往往是被大家“攻击”的对象。做好评审会，对于产品经理的专业能力也是一个非常大的考验。产品经理如何才能在需求评审中少挨打呢？

作为一个产品经理，需求评审是产品设计开发的一个重要环节。只要工作在进行，产品在迭代，新需求在不断产生，就会有需求评审。

在需求评审会议上，产品经理将面对前端、后端、测试、UI设计师、你的领导、甚至老板可能都会过来，不同角色聚在一个会议室听你讲解需求内容，简直妙不可言。在会议中，不同角色提出不同意见，出现无法预测问题等，产品经理又该如何游刃有余的化险为夷，高效完成需求评审呢？

本文作者基于自身工作经验，和大家一起聊聊需求评审相关的内容，希望对你们有帮助。

一、原型准备阶段

在评审前，是产品经理收集需求、分析需求、提炼需求、输出原型等文档的过程，在此阶段提几点自己总结的愚见，如果能做到以下几点的话，可能对你开展工作会有很大的帮助。

1. 需求细节尽量描述详细

详细即逻辑清晰、无遗漏、页面整洁、表达清晰等，图1、图2是作者平时写需求文档的一些习惯，仅供大家参考。这里说一个有趣现象，不知道大家有没有遇到过：就是不管你需求说明写得如何详细，有些技术就是不看，次次都来问。

(图1：审核状态需求说明)

(图2：字段需求说明)

图1是我做的B端项目某个审核状态的需求说明，将书写需求说明可以分为三部分：要描述功能或者动作、分状态或场景、细节描述，大家可对照图1自行理解，一看就懂。

2. 以前有的功能，现在项目涉及到要不要把以前的功能需求再写一下

关于这个问题，也有好几个小伙伴问过我。如果是该功能迭代优化，那涉及其相关的需求要在会上说明：原先功能整套流程是怎么样的，现在针对哪个环节进行升级迭代。

其实多写总归没毛病的，毕竟上一版的开发人员不一定继续负责以后的相关迭代工作，我的做法一般会加上这句话 “现有逻辑：若代码发生修改，应及时和产品、测试说明情况”。

因为在技术实际开发过程，可能会现有逻辑的代码进行增删，这种情况肯定需要测试人员重新测试；即使现有逻辑未动，测试人员可能也需要回归一下，走一下流程，都是有必要做的。

总之呢，关于涉及到现有逻辑会不会被改动，会议上还要重点提一下的。

3. 设计功能或者逻辑一定要有理有据

逻辑不通，形成不了闭环，大忌；设计功能的时候，自己认为这样就是这样，也是大忌；一起看下签到功能的例子，一说到签到功能想必大家脑海中连UI画面都想好了，常见的前台页面可能如下图这几种。

（图3：签到画面一）

（图4：签到画面二）

这两种签到布局展示的方式，在座的各位应该都见过吧，两者布局差异基本不大。从技术角度来看，图4的日期显示效果肯定比图3按天数方式实现要复杂一些。

假如你选择图4方案时，技术人员有可能会问：你为什么要采用这种日期显示方式，而不选择图3方式？各种小伙伴遇到这种问题，自己心里有答案吗？

如果你支支吾吾的，说不出个子丑寅卯，那么技术人员分分钟钟教你做人，我们可以这么回答：之所以按照日期的方式显示，可以使签到功能参与营销活动；比如5月20号这天，运营可以在后台设置那天签到奖励是情人节大额优惠券等等，这样按日期方式显示就很有意义了。

记住我们设计的每个功能都要有理有据。

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

相信大多数的产品是没有技术背景的，在产品设计过程中，经常遇到需要实现某些复杂的操作交互、炫酷特效、营销游戏等。要实现这些功能，估计需要技术人员有比较扎实的代码能力。

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

最好在会议前双方把方案制定，达成共识，而不是把所有问题放在会议上讨论，这样做好处是避免了：在评审过程中就某一特效或功能实现难易程度，双方花费太多的时间讨论，而导致评审时间被拉长。

二、评审前的准备

1. 产品内部评审

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

2. 业务部门会议

还是属于比较大的项目，跟业务部门开会主要目的是让他们了解产品部门做的东西是不是符合他们预期效果。我们只要跟他们大致讲解项目操作流程即可，无需太细致。小范围的需求预评审主要还是为了保证需求的质量，以保证正式评审的时候，不会出现大的纰漏。

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

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

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

需求评审的过程，本质上就是沟通，用语言配合原型文档的方式，将需求、逻辑清晰的表述出来，然后和所有人基本达成一致意见。但讲解之前一定要先向大家介绍一下本次项目的背景，大致可以朝这两个大个方向进行说明：

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

需求评审原则上就是产品经理的“主场”，所要保持主场的气势，稳住场面。人人都是产品经理，正是因为人人针对某一个功能都会有自己的想法和意见，那么产品经理该怎么应付呢？

1. 合理的意见、想法

针对于这种意见，可能会给我们后续迭代有一定的启发，但是不一定要放在本次需求内。需求总有优先级排序的，应当先解决眼前紧急的问题。我们大可不必针对每个意见一一作出解释，你们可以保留自己的意见，我负责记录，提高会议效率。

2. 不要过度纠结细节讨论

很多同学应该遇到过这种情况：你每一句话需求，总有人会打断你并和你扣细节，打破砂锅问到底，这不是什么好现象。细节是永远都扣不完的，如果在会议上陷入细节的讨论，不仅浪费大家时间，而且对于产品经理来说也会非常痛苦。

这时候你可以制止那人，让你把这块功能讲完，再让大家提问题，实在有人要聊细节，建议在会后和他单独好好讨论，产品经理始终要记住把控会议时间和节奏。

3. 逻辑漏洞、功能遗漏

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

4. 不要把会评审成技术方案讨论会议

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

5. 这个实现不了

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

这种情况，千万不能傻乎乎的直接反驳“这个有那么麻烦嘛？”、“很简单的啊，这样搞搞就好了啊”，这种很容易被技术认为是傻bi的表现，严重的话会激化矛盾。

首先呢，我们要确认技术们的难点在哪里，是需要更多的开发时间呢，还是真的有一定开发难度。综合各方面因素，考虑是否值得这样的投入？如果真的是一个很重要的功能点，可以说清楚该功能对整个业务的重要性，就算开发复杂、难度高，需要较多的时间也可以接受。

如果还是争论不止，那把这问题暂时放一下，会后叫上技术负责人和该项目开发人员一起在讨论，切记也不能占用要多时间。

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

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

1. 及时修改问题

小功能评审基本上可以百分百过，但是大项目基本上很少全票通过的情况，都会有一些小修改小调整的。该修改的地方修改，该落实细节地方落实好细节，最终通过邮件等方式告知大家。

2. 督促排期，跟踪进度

督促各个岗位负责人针对此次项任务周期，最后确认预估的整个开发周期。后续要持续跟进开发进度，直至完成上线。在跟进过程中，很有可能出现未考虑到的问题，这时候需要产品经理要和开发紧密合作，讨论新的解决方案，并同步修改原型和需求说明。

3. 需求评审复盘

会议上，大家都会各抒己见，对产品经理来说很多意见和想法对自己很有启发，我们可以一一收集起来，也可以找同事帮自己记录下。会议结束后，我们就要针对这些想法进行筛选分析，合理的进行后续的迭代工作。

还有一点也要反思自己会议中，哪几个点做的还不够好的，及时改善不足之处，快速成长。

五、总结

在会议中，产品经理被针对是很正常的情况，通过以上内容的介绍，大多数情况下可以帮助大家避免一些问题。当遇到反对观点，我们常常会不自觉产生自我保护意识，一味的进行反驳，却忘了需求评审的目的，决不妥协和轻易妥协似乎都不是好办法。

最后，祝大家顺利的渡过每一次需求评审，也可在留言区分享会议中出现有趣的事情！

#专栏作家#

道三，微信公众号：产品大秘籍，人人都是产品经理专栏作家。以前写过代码，现在产品圈摸爬滚打，专注于电商领域产品设计、主要分享电商和供应链领域知识点。

本文原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。