产品经理需求评审会的本质，为什么需求评审对产品经理是一个挑战？
导读：产品经理的最终目的还是为了实现用户价值、产品价值，解决用户痛点、提高用户体验，只要你的角度是站在用户这边着想，大部分需求评审都是很顺利的，更多的只是一些细节的沟通和确认而已
需求评审其实就是产品经理向团队说明需求是什么、为什么要做这个需求、需求转为功能界面是什么样的，是一个一起沟通和分析需求最佳方案的一个会议。
第一部分是需求背景和价值，这个需求是否真的值得做。第二部分是需求的落地方案是否是当前最优的，还有什么问题。需求评审的形式不一定要开个会，这个和团队规模和运转模式有关系，可能就是产品经理单独找研发对着需求文档讲一次，双方达成共识就可以了；也可能是组织团队十几个人在会议室一起过方案。需求评审时，每个岗位的同学都会站在自己的角色和角度去考虑问题，研发有研发的逻辑、测试有测试的视角、UI有UI的审视，领导有领导的考虑，大家把所有问题都抛出来，提出想法和建议，最后达成共识。当评审会越严肃、参与的人越多时，压力和挑战越大，没有人会希望一屋子人都在否决你主导的方案。作为产品经理，前前后后把需求写成文档其实花了很长时间，一般的1-3天，复杂点新模块的4-10天也不算长，消耗了产品人很多精力和心血，要是评审出现很多问题，当时的情绪可想而知。前面说的需求评审的2大部分，一个是背景和价值，一个是落地方案。第一部分其实通常不会有问题，除非是产品经理自己规划的需求，那么就要细节说清前因后果，特别是竞品部分的分析一定要拿出来分享，如果需求是老板提的，就请直接说出“这是老板提出来的需求”。第二部分落地方案的评审才是会议的核心，因为产品经理的核心能力之一就是把需求转成功能，这个功能为什么这样设计、合理不合理、逻辑有没有问题、有没有遗漏、有没有更好的办法，所有评审人员都在提出自己的也对，就是要在这样的情况下，依然要说服并团队推进需求落地，当然方案设计不能有太多问题，如果有的话还的再来一次。就在需求讲完开始提问这个环节，产品经理vs程序员的战斗也就打响了。“这个需求很复杂，难度很大，需要很久，价值不高”。“你这个需求做不做要高层领导参加决定，要在单独拉个会拉上领导一起确定”。第二是按照你的设计来做太复杂，影响了整体数据结构或者和之前设计有点冲突之类，不想搞，然后也不会说出这个原因，开始扯其他的。第三是研发主观意识很强，就是他觉得这样不行，他不同意，你说服不了争议比较好处理，把争议点讨论清楚，一起找出新方案就好。妥协是有一方必须要退让，不是产品经理就是研发，不然没法推进了。这里涉及到一些原则和一些综合价值情况，但凡是产品核心体验、性能问题，产品经理是一定不能退的，打到老板那也不行。一些综合价值不高又消耗过大时，产品经理是可以退的，很多时候没必要那么强硬，该进则进，该退则退，这样团队能融合的更好。1、需求评审最好是至少2次，一次产品经理团队内审，一次开发团队公审。2、需求评审时要保持对PRD足够熟悉，要让自己的逻辑思维和大脑一直保持清醒，否则在和研发沟通逻辑时，很容易把你绕晕。3、注意控制好每次的评审时间，要控制好会议的节奏。4、评审会议要提前发出来，需求评审前要对需求提前预审。5、产品经理写完的需求文档要自己过几遍，确保自己检测没问题。6、每次需求的评审记录要记录清楚，主要是需求评审后的待办事项以及问题跟进。7、需求没有评审通过还有问题就当场说清楚就行，大大方方承认，约好下次再评审一次，有些复杂需求审批几次也很正常。产品经理的最终目的还是为了实现用户价值、产品价值，解决用户痛点、提高用户体验，只要你的角度是站在用户这边着想，大部分需求评审都是很顺利的，更多的只是一些细节的沟通和确认而已。在沟通中出现碰撞更能发现功能的缺陷和需要改进的地方，就像刚开始说的那样，大家把所有问题都抛出来，提出想法和建议，最后达成共识。而为了提高评审效率，产品经理必须要保证产品需求文档的质量，需求评审的过程其实也就是把你的PRD文档从上到下讲一遍而已，只要PRD写得好丝毫不用慌。
