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