产品经理怎么做才能在需求评审中少挨打？
作为一个产品经理，需求评审是产品设计开发的一个重要环节。只要工作在进行，产品在迭代，新需求在不断产生，就会有需求评审。
在需求评审会议上，产品经理将面对前端、后端、测试、UI设计师、你的领导、甚至老板可能都会过来，不同角色聚在一个会议室听你讲解需求内容，简直妙不可言。在会议中，不同角色提出不同意见，出现无法预测问题等，产品经理又该如何游刃有余的化险为夷，高效完成需求评审呢？
本文作者基于自身工作经验，和大家一起聊聊需求评审相关的内容，希望对你们有帮助。
一、原型准备阶段
在评审前，是产品经理收集需求、分析需求、提炼需求、输出原型等文档的过程，在此阶段提几点自己总结的愚见，如果能做到以下几点的话，可能对你开展工作会有很大的帮助。
1. 需求细节尽量描述详细
详细即逻辑清晰、无遗漏、页面整洁、表达清晰等，图1、图2是作者平时写需求文档的一些习惯，仅供大家参考。这里说一个有趣现象，不知道大家有没有遇到过：就是不管你需求说明写得如何详细，有些技术就是不看，次次都来问。
(图1：审核状态需求说明)
(图2：字段需求说明)
图1是我做的B端项目某个审核状态的需求说明，将书写需求说明可以分为三部分：要描述功能或者动作、分状态或场景、细节描述，大家可对照图1自行理解，一看就懂。
2. 以前有的功能，现在项目涉及到要不要把以前的功能需求再写一下
关于这个问题，也有好几个小伙伴问过我。如果是该功能迭代优化，那涉及其相关的需求要在会上说明：原先功能整套流程是怎么样的，现在针对哪个环节进行升级迭代。
其实多写总归没毛病的，毕竟上一版的开发人员不一定继续负责以后的相关迭代工作，我的做法一般会加上这句话 “现有逻辑：若代码发生修改，应及时和产品、测试说明情况”。
因为在技术实际开发过程，可能会现有逻辑的代码进行增删，这种情况肯定需要测试人员重新测试；即使现有逻辑未动，测试人员可能也需要回归一下，走一下流程，都是有必要做的。
总之呢，关于涉及到现有逻辑会不会被改动，会议上还要重点提一下的。
3. 设计功能或者逻辑一定要有理有据
逻辑不通，形成不了闭环，大忌；设计功能的时候，自己认为这样就是这样，也是大忌；一起看下签到功能的例子，一说到签到功能想必大家脑海中连UI画面都想好了，常见的前台页面可能如下图这几种。
（图3：签到画面一）
（图4：签到画面二）
这两种签到布局展示的方式，在座的各位应该都见过吧，两者布局差异基本不大。从技术角度来看，图4的日期显示效果肯定比图3按天数方式实现要复杂一些。
假如你选择图4方案时，技术人员有可能会问：你为什么要采用这种日期显示方式，而不选择图3方式？各种小伙伴遇到这种问题，自己心里有答案吗？
如果你支支吾吾的，说不出个子丑寅卯，那么技术人员分分钟钟教你做人，我们可以这么回答：之所以按照日期的方式显示，可以使签到功能参与营销活动；比如5月20号这天，运营可以在后台设置那天签到奖励是情人节大额优惠券等等，这样按日期方式显示就很有意义了。
记住我们设计的每个功能都要有理有据。
4. 设计过程中遇到技术难点、技术知识盲区，一定要和技术去沟通
相信大多数的产品是没有技术背景的，在产品设计过程中，经常遇到需要实现某些复杂的操作交互、炫酷特效、营销游戏等。要实现这些功能，估计需要技术人员有比较扎实的代码能力。
因此，当你遇到把握不准自家技术能不能实现自己功能，可以找到技术负责人把自己的想法提前说给他听，提前一起讨论实现过程，或许让他们评估且及时制定方案。
最好在会议前双方把方案制定，达成共识，而不是把所有问题放在会议上讨论，这样做好处是避免了：在评审过程中就某一特效或功能实现难易程度，双方花费太多的时间讨论，而导致评审时间被拉长。
二、评审前的准备
1. 产品内部评审
如果是比较大的项目，可能是多个产品经理一起负责，那么最好是产品部门内部开一个小评审会，把大致逻辑、功能统统讲一遍，看看有没有遗留的，有没有补充的。
2. 业务部门会议
还是属于比较大的项目，跟业务部门开会主要目的是让他们了解产品部门做的东西是不是符合他们预期效果。我们只要跟他们大致讲解项目操作流程即可，无需太细致。小范围的需求预评审主要还是为了保证需求的质量，以保证正式评审的时候，不会出现大的纰漏。
3. 提前把原型或者需求文档发给技术人员
在需求评审会议的前一天，可以把原型和需求文档发送给参会的相关人员，目的是让他们提前熟悉需求。若有问题及时收集，在需求评审之前向提问者解答，能大大提高需求评审会的效率。
三、评审中 – 控制节奏、应万变
需求评审的过程，本质上就是沟通，用语言配合原型文档的方式，将需求、逻辑清晰的表述出来，然后和所有人基本达成一致意见。但讲解之前一定要先向大家介绍一下本次项目的背景，大致可以朝这两个大个方向进行说明：
- 需求来自哪个人或者哪个部门等，他们遇到什么问题了？【现状】
- 针对这些问题，采用什么方案或者增加什么功能，来解决他们遇到的问题或提升什么体验及指标等；【预期】
需求评审原则上就是产品经理的“主场”，所要保持主场的气势，稳住场面。#
道三，微信公众号：产品大秘籍。以前写过代码，现在产品圈摸爬滚打，专注于电商领域产品设计、主要分享电商和供应链领域知识点。
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！