人人都是产品经理|如何让PM完成需求评审而不被打?


编辑导读:需求评审是每个产品经理都躲不过的一项工作 , 如何做好这项工作可大有学问 。 本文将从三个方面展开分析 , 对需求评审感兴趣的童鞋不要错过哦 。

人人都是产品经理|如何让PM完成需求评审而不被打?
本文插图

如果说产品经理的生涯是一条修炼之路 , 那么需求评审就是产品汪躲不过的劫 。
做不好需求评审的产品经理 , 很可能会对产品生涯产生阴影 , 因为每一次需求评审都是对产品经理的多人毒打 。
心态好的产品经理能每次爬起来完成蜕变 , 而心态不好的产品经理 , 很可能会被实力劝退 。
尤其是对于新手产品经理 , 或者是新加入一个团队的产品经理来说 , 第一次需求评审将决定你在团队中的印象 , 也将决定你日后的日子是苦是甜 。
如何让产品汪完成需求评审而不群殴 , 本文从需求评审前 , 中 , 后三步来谈一下我工作中得到的经验 。

人人都是产品经理|如何让PM完成需求评审而不被打?
本文插图

一、需求评审前
正式需求评审前 , 一定要进行一次需求预审 。
大事都是在小会上决定的 , 而大会只是做一个详细通知和布置具体的任务 。
需求预审的参加对象 , 是产品经理、前端主管、后台主管 , 一般三个人即可 , 或者是前后台的开发主力 。
预审的目的有两个:
明确需求是否可以实现 。 有时候一些想偷懒的开发 , 面对一些复杂的需求 , 就会以“这个做不了”来推脱 。
这个时候 , 你把预评审的结论说出来 , 他也就熄火了 , 就不至于陷入扯皮的尴尬 。
验证需求文档的主要逻辑 。 大会评审的时候 , 如果主要逻辑出现了问题 , 那基本上可以确定要再进行一轮评审 , 这样不仅浪费了大家的时间 , 还可能让自己被贴上不靠谱的标签 。
需求评审前 , 一定要提前发评审邀请 。 可以是邮件 , 也可以直接在工作群邀约 。
但是一定要有提前量 , 这样可以让开发预习一下 , 提前把问题准备好 , 提高大会评审效率 。
评审邀请 , 如果是写邮件 , 发送邮件前 , 也最好在群里跟大家约一下时间 , 免得出现时间冲突的情况 。
邀请邮件的内容一般包括:需求的背景 , 便于理解需求的功能列表(不需要太细)需求文档链接 , 看团队习惯会议主体、会议时间、地点和参与人员
邮件发完以后 , 记得在群里和大家同步一声 , 免得有人漏掉邮件 。
二、需求评审中
需求评审的步骤大致如下:
并不是每次需求评审都需要完全按照这个流程 , 比如是迭代型的需求 , 就不需要走第二步 。
需求评审 , 本质上就是沟通 , 用语言配合原型文档的方式 , 将需求清晰的表述出来 。 所以 , 一定要明白我们和其他人之间 , 肯定存在知识诅咒 。
所以 , 不要一开始就讲细节 , 不要一开始就讲细节 , 不要一开始就讲细节 。
细节是永远都扣不完的 , 如果在会议上陷入细节的讨论 , 不仅浪费时间 , 而且对于产品经理来说也会非常痛苦 。
因为总有一些细节是你没有想到的 , 而且你会发现 , 一到这种时候 , 大家都非常兴奋 。
因为谁都会挑毛病 , 而且大家都非常乐意挑别人的毛病 。 所以不要找不自在 。
而且陷入细节的需求评审 , 会显得毫无逻辑 。 大家很容易一脸懵逼 , 特别是对于没有提前看过文档的同学(不幸的是 , 大部分同学都不会提前看文档) 。
在正式讲解需求之前 , 一定要先明确本次会议的主题 , 会议需要完成达成哪些目的 。 主要事项有哪些 , 让大家心里有底 。 这也是串起整个会议的主线 。
正式开始需求评审后 , 首先要做的 , 就是要和大家达成一项共识:为什么要做本次迭代 。 也就是这些需求能带来哪些价值 。


推荐阅读