产品经理如何高效的完成需求评审

责编:【产品大秘籍】公众号 2020-07-10 10:28 阅读(113)
产品需求评审目的是让项目的参与者,包括UI设计师、测试工程师、前端工程师、后端工程师等等相关人员,能够快速理解产品开发的整套流程及细节,最终达成统一意见,认可自己的方案。

那么做为产品经理,需要注意哪些事项,才能使得需求评审高效的完成?

下面来谈谈我自己工作中总结的一些想法:


一、评审前 - 原型输出阶段

1. 需求细节尽量描述详细;

同一个项目中,多处出现一样功能要不要都要写功能需求说明。这里我觉得还是有必要的,可以写一份说明,然后其余相同功能的地方,直接引导开发人员去那一页原型查看即可。

以前原型有的功能,现在迭代了要不要再写一遍。如果是该功能进行优化,那涉及其相关的需求说明肯定要再写出来;
如果是上下游功能优化迭代,且与该功能有一定的交互,那肯定也要把该功能的需求说明再次写出来,因为上一版的开发人员不一定继续负责以后的相关迭代工作;

详细的需求文档,是产品经理避免与开发人员撕bi的最直接的“证据”。

产品:你这个功能点怎么没做啊?

开发:原型上没有呀!

产品拿出原型;

产品:你这个功能点好像做的不对啊?

开发:原型就是这么说的呀!

产品拿出原型;


2. 设计功能或者逻辑一定要有理有据;

举个签到时间显示的案例

方式一

方式二

这两种签到时间展示的方式,在座的各位应该都见过吧,两者区别也很明显。从技术角度来看,方式二时间显示效果肯定是比方式一复杂一些。
当你选择方式二方案时,技术人员有可能会问:你为什么要采用方式二的时间显示方式,而不选择方式一?各种小伙伴遇到这种问题,自己心里有答案吗?
千万不要说出“我以为什么什么的”等等一厢情愿的答案,这样会被怼的很厉害,技术人员会分分钟钟教你做人。记住我们设计的每个功能都要有理有据。
参考答案可能是:之所以按照日期的方式显示,可以参与营销活动;比如5月20号这天,我们可以后台设置签到奖励是情人节大额优惠券等等(当时我设计后台签到奖励是金币和优惠券都可配置),这样按日期方式显示就很有意义了。
上述的案例,是我自己亲身的经历。

3. 涉及到技术难点,知识盲区,一定要提前和技术进行沟通,万万不能自己想当然;

相信大多数的产品是没有技术背景的,在产品设计过程中,某某操作交互、某某花里胡哨效果、某某功能效果市面上都有实现的例子,然后以为自己家技术也能完美的实现,日常工作中我也是这么认为的,他们是可以的(斜眼)。
举个活动抽奖的案例

这种比较个性化抽奖小活动,也是我经历过的,当然这种方式抽奖市面上肯定有类似的,我见到很多次。

在把握不准的自家技术能不能实现自己想要的那样子,可以在产品设计过程中,可以把自己的想法提前说给技术负责人听,然后让他们及时评估,这样避免了在评审过程就某一特效或功能,双方花费太多的时间讨论。

二、评审中 - 控制节奏、应万变


1. 意见、想法处理方式

参与评审会议的各位小伙伴,在你讲同一个功能的时候,他们的关注点各不相同,他们也会各自提出自己想法及建议。
这里要把想法及建议分一分类:

(1)建议性、优化性的想法

针对于这种意见,我们还是给予保留的,但不一定当时就要采纳加进来,你有你的优化节奏,不能被他们牵着鼻子走。
对于这些想法,我们静静听他们讲完即可。
正确的做法:一些不错的而且我们没有想到的意见,产品后期迭代优化的时候,可以酌情的参考。
(2)逻辑漏洞、功能漏洞
关于逻辑漏洞、功能漏洞等问题,是属于比较严重的评审事故了,错了就要挨打。
较大的逻辑问题,可能此次评审会议就毫无意义了,自己没有理清逻辑,莫非要其他人教你做产品。
人人都是产品经理,人人又都不是产品经理,要谨慎、负责对待每一次评审,错了不可怕,要总结每一次经验。

2. 意见不合处理方式

每一次评审,或多或少都会和相关人员就某一问题(撕)展开激烈的讨论(逼)。你说的有理,他说的也没有错,这时候该怎么办呢?心态要稳,注意情绪。
有些人特别喜欢钻牛角尖,在大家都有理有据的时候,那只能有一个声音:当双方有理有据时,一定要听产品经理的。至于为什么呢,自己慢慢品。时间宝贵,无需没完没了的争论,会后再论,评审继续。

3. 这个实现不了

技术们这样的回应时,想必大家也遇到过,不要慌,之所以这么回应,绝大情况下是背后有一个巨大的开发量,或者是时间紧张。如果有评审前第三点操作,就会避免出现这种回应的次数。
那出现万一的情况呢,咱千万不能直接反斥“这个有那么麻烦嘛?”,“很简单的啊,这样搞搞就好了啊”,这种很容易被技术认为是傻bi的表现,严重的话会激化矛盾。
首先呢,我们要确认技术们的难点在哪里,是需要更多的开发时间呢,还是真的有一定开发难度。综合各方面因素,考虑是否值得这样的投入?如果真的是一个很重要的功能点,可以说清楚该功能对整个业务的重要性,就算开发复杂、难度高,需要较多的时间也可以接受。
如果还是争论不止,那把这问题暂时放一下,会后叫上技术负责人和该项目开发人员一起在讨论,秉承砍我可以,砍需求不行,但还是要酌情。
不管新手还是老鸟,只要把需求写详细,按部就班的讲解基本上不会有什么大问题。至于会议时间的把控,原则上不宜拖太长的,不过因人而异。

三、评审后 - 查缺补漏、保持跟进

1. 及时修改问题

小功能评审基本上可以百分百过,但是大项目可没有百分百一说,都会有一些小修改小调整的,修改完成后及时交付给相关人员,让他们查看预估时间。

2. 相关人员预估开发时间
项目设计前,结合各种因素对项目开发时间有一个大概预算时间,然后结合相关人员提供时间作对比。真的超过预算时间,砍我可以,砍需求不行,适当加班也是有必要的。

3. 制定开发计划表,每天跟进,有问题及时反馈。

.....

欢迎关注【产品大秘籍】公众号


标签: 需求评审
前端交流群: MVC前端网(menvscode.com)-qq交流群:551903636

邮箱快速注册

忘记密码