时间: 2021-07-30 11:14:49 人气: 4 评论: 0
编辑导语：需求评审是产品经理非常“害怕”但是又不得不做的一个**议 ，因为在评审**中，产品经理往往是被大家“攻击”的对象。做好评审**，对于产品经理的专业能力也是一个非常大的考验。产品经理如何才能在需求评审中少挨打呢？
作为一个产品经理，需求评审是产品设计开发的一个重要环节。只要工作在进行，产品在迭代，新需求在不断产生，就**有需求评审。
在需求评审**议上，产品经理将面对前端、后端、测试、UI设计师、你的领导、甚至老板可能都**过来，不同角色聚在一个**议室听你讲解需求内容，简直妙不可言。在**议中，不同角色提出不同意见，出现无法预测问题等，产品经理又该如何游刃有余的化险为夷，高效完成需求评审呢？
本文作者基于自身工作经验，和大家一起聊聊需求评审相关的内容，希望对你们有帮助。
在评审前，是产品经理收集需求、分析需求、提炼需求、输出原型等文档的过程，在此阶段提几点自己总结的愚见，如果能做到以下几点的话，可能对你开展工作**有很大的帮助。
详细即逻辑清晰、无遗漏、页面整洁、表达清晰等，图1、图2是作者平时写需求文档的一些习惯，仅供大家参考。这里说一个有趣现象，不知道大家有没有遇到过：就是不管你需求说明写得如何详细，有些技术就是不看，次次都来问。
(图1：审核状态需求说明)
(图2：字段需求说明)
图1是我做的B端项目某个审核状态的需求说明，将书写需求说明可以分为三部分：要描述功能或者动作、分状态或场景、细节描述，大家可对照图1自行理解，一看就懂。
关于这个问题，也有好几个小伙伴问过我。如果是该功能迭代优化，那涉及其相关的需求要在**上说明：原先功能整套流程是怎么样的，现在针对哪个环节进行升级迭代。
其实多写总归没毛病的，毕竟上一版的开发人员不一定继续负责以后的相关迭代工作，我的做法一般**加上这句话 “现有逻辑：若代码发生修改，应及时和产品、测试说明情况”。
因为在技术实际开发过程，可能**现有逻辑的代码进行增删，这种情况肯定需要测试人员重新测试；即使现有逻辑未动，测试人员可能也需要回归一下，走一下流程，都是有必要做的。
总之呢，关于涉及到现有逻辑**不**被改动，**议上还要重点提一下的。
逻辑不通，形成不了闭环，大忌；设计功能的时候，自己认为这样就是这样，也是大忌；一起看下签到功能的例子，一说到签到功能想必大家脑海中连UI画面都想好了，常见的前台页面可能如下图这几种。
（图3：签到画面一）
（图4：签到画面二）
这两种签到布局展示的方式，在座的各位应该都见过吧，两者布局差异基本不大。从技术角度来看，图4的日期显示效果肯定比图3按天数方式实现要复杂一些。
假如你选择图4方案时，技术人员有可能**问：你为什么要采用这种日期显示方式，而不选择图3方式？各种小伙伴遇到这种问题，自己心里有答案吗？
如果你支支吾吾的，说不出个子丑寅卯，那么技术人员分分钟钟教你做人，我们可以这么回答：之所以按照日期的方式显示，可以使签到功能参与营销活动；比如5月20号这天，运营可以在后台设置那天签到奖励是情人节大额优惠**等等，这样按日期方式显示就很有意义了。
记住我们设计的每个功能都要有理有据。
相信大多数的产品是没有技术背景的，在产品设计过程中，经常遇到需要实现某些复杂的操作交互、炫酷特效、营销游戏等。要实现这些功能，估计需要技术人员有比较扎实的代码能力。
因此，当你遇到把握不准自家技术能不能实现自己功能，可以找到技术负责人把自己的想法提前说给他听，提前一起讨论实现过程，或许让他们评估且及时制定方案。
最好在**议前双方把方案制定，达成共识，而不是把所有问题放在**议上讨论，这样做好处是避免了：在评审过程中就某一特效或功能实现难易程度，双方花费太多的时间讨论，而导致评审时间被拉长。
如果是比较大的项目，可能是多个产品经理一起负责，那么最好是产品部门内部开一个小评审**，把大致逻辑、功能统统讲一遍，看看有没有遗留的，有没有补充的。
还是属于比较大的项目，跟业务部门开**主要目的是让他们了解产品部门做的东西是不是符合他们预期效果。我们只要跟他们大致讲解项目操作流程即可，无需太细致。小范围的需求预评审主要还是为了保证需求的质量，以保证正式评审的时候，不**出现大的纰漏。
在需求评审**议的前一天，可以把原型和需求文档发送给参**的相关人员，目的是让他们提前熟悉需求。若有问题及时收集，在需求评审之前向提问者解答，能大大提高需求评审**的效率。
需求评审的过程，本质上就是沟通，用语言配合原型文档的方式，将需求、逻辑清晰的表述出来，然后和所有人基本达成一致意见。但讲解之前一定要先向大家介绍一下本次项目的背景，大致可以朝这两个大个方向进行说明：
需求评审原则上就是产品经理的“主场”，所要保持主场的气势，稳住场面。人人都是产品经理，正是因为人人针对某一个功能都**有自己的想法和意见，那么产品经理该怎么应付呢？
针对于这种意见，可能**给我们后续迭代有一定的启发，但是不一定要放在本次需求内。需求总有优先级排序的，应当先解决眼前紧急的问题。我们大可不必针对每个意见一一作出解释，你们可以保留自己的意见，我负责记录，提高**议效率。
很多同学应该遇到过这种情况：你每一句话需求，总有人**打断你并和你扣细节，打破砂锅问到底，这不是什么好现象。细节是永远都扣不完的，如果在**议上陷入细节的讨论，不仅浪费大家时间，而且对于产品经理来说也**非常痛苦。
这时候你可以制止那人，让你把这块功能讲完，再让大家提问题，实在有人要聊细节，建议在**后和他单独好好讨论，产品经理始终要记住把控**议时间和节奏。
如果对业务了解不够深入，思考不周全，很容易被其他人发现逻辑或功能遗漏等问题，这对产品经理来说是属于比较严重的评审事故了，错了就要挨打。一般不是较大的逻辑问题，评审**议还是能继续开下去的，**后应当及时补充内容。
每当遇到某些功能，对于技术来说实现比较有挑战性或者很感兴趣的时候，他们就**不知不觉的开始讨论用什么方法实现好，该如何如何去操作，留下一脸懵逼的你。这时候你要打住他们，如果逻辑没问题，怎么实现是技术的问题，不允许在**议上占用太多时间来讨论具体方案。
技术们这样的回应时，想必大家也遇到过，不要慌，之所以这么回应，绝大情况下是背后有一个巨大的开发量，或者是时间紧张。
这种情况，千万不能傻乎乎的直接反驳“这个有那么麻烦嘛？”、“很简单的啊，这样搞搞就好了啊”，这种很容易被技术认为是傻bi的表现，严重的话**激化矛盾。
首先呢，我们要确认技术们的难点在哪里，是需要更多的开发时间呢，还是真的有一定开发难度。综合各方面因素，考虑是否值得这样的投入？如果真的是一个很重要的功能点，可以说清楚该功能对整个业务的重要性，就算开发复杂、难度高，需要较多的时间也可以接受。
如果还是争论不止，那把这问题暂时放一下，**后叫上技术负责人和该项目开发人员一起在讨论，切记也不能占用要多时间。
需求评审**议结果后，我们还不能如释重负，还有事情要做呢！
小功能评审基本上可以百分百过，但是大项目基本上很少全票通过的情况，都**有一些小修改小调整的。该修改的地方修改，该落实细节地方落实好细节，最终通过邮件等方式告知大家。
督促各个岗位负责人针对此次项任务周期，最后确认预估的整个开发周期。后续要持续跟进开发进度，直至完成上线。在跟进过程中，很有可能出现未考虑到的问题，这时候需要产品经理要和开发紧密合作，讨论新的解决方案，并同步修改原型和需求说明。
**议上，大家都**各抒己见，对产品经理来说很多意见和想法对自己很有启发，我们可以一一收集起来，也可以找同事帮自己记录下。**议结束后，我们就要针对这些想法进行筛选分析，合理的进行后续的迭代工作。
还有一点也要反思自己**议中，哪几个点做的还不够好的，及时改善不足之处，快速成长。
在**议中，产品经理被针对是很正常的情况，通过以上内容的介绍，大多数情况下可以帮助大家避免一些问题。当遇到反对观点，我们常常**不自觉产生自我保护意识，一味的进行反驳，却忘了需求评审的目的，决不妥协和轻易妥协似乎都不是好办法。
最后，祝大家顺利的渡过每一次需求评审，也可在留言区分享**议中出现有趣的事情！
道三，微信公众号：产品大秘籍，人人都是产品经理专栏作家。以前写过代码，现在产品圈摸爬滚打，专注于电商领域产品设计、主要分享电商和供应链领域知识点。
本文原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。
