需求评审时总是被挑战,肿么破?

前几天有小伙伴给我留言,说自己每次需求评审的时候被各种拍砖,不知道肿么破。

先看下这位小伙伴遇到的问题:

产品经理
下面是我的回复:

产品经理
确实,需求被挑战几乎是每个产品经理都会遇到的问题。要想在评审的时候被拍得越来越少,首先得总结下常见的被挑战的问题点有哪些。

经常被挑战的问题

1、技术层面,实现逻辑的可行性问题

需求评审中,常常会被技术同学挑战的问题,多是发现产品经理提出的某个“想当然”的功能需求点,在技术上是很难实现或存在较大风险。

举个例子:

如果设计这样一个功能:不论用户是否登录,一进入某个页面就获得n天后的1次抽奖机会。当用户n天后再次进入该页面时,不论是否登录都可以完成抽奖,中奖后再要求用户登录领奖。

从用户体验上说,用户在无需登录的情况下就可以进行如此流畅的操作,肯定比一进来就要求登录体验更好。

但是在实现上,产品经理得考虑,无需登录的状态下,如何识别用户?抽奖次数记录在哪里?可以记录在本地吗?如果记录在本地,n天后用户再进入该页面,记录还在吗?存在哪些记录丢失的风险?等等。

这时,需要跟技术同学做充分的沟通和评估,再做一个技术实现与用户体验的平衡,产出靠谱的产品需求。

2、需求层面,考虑不周全

经常会被产品经理遗漏的需求包括:
该产品流程与其他产品线的产品存在交集,会影响到其它产品的联动修改
只考虑到正向、正常产品流程,没有考虑到逆向、异常产品流程如何处理
需要描述细节的地方一句话带过,不清晰。例如,展示活动倒计时。那就需要说明活动倒计时从什么时间开始计算?以什么时间为截止时间?活动开始之前如何展示?活动结束之后如何展示?等。

在评审前,没有考虑足够细致、全面,也常常是需求被挑战的点。

3、业务层面,ROI过低

某一个需求功能点的意义、价值过小,但是实现成本过高,也常常会被团队拍砖的。

怎样才能被越拍越少

总结了经常被挑战的问题之后,那怎样才能被越拍越少呢?我个人认为:

1、多做总结。

每一个需求上线后都回过头来,如果让自己再做这个需求,要怎么做,会优化哪些?PRD怎么写?甚至要不要重新写一次?这次的主要问题暴露了我哪方面的欠缺?

... ...

这样,每次总结,相信在做产品设计时会考虑越来越全面,对产品将面临的风险(或者说“坑”)会有比较充足的预估。

2、设计过程中多问自己为什么

某一个功能点,为什么要做?价值点是什么?实现成本如何?ROI高吗?为什么要这么做?还有更好的解决方案吗?

... ...

让自己设计的每一个功能点都能站住脚,不仅有价值而且实现方案是最优的。

3、需求评审之前做充足的沟通

在有了初步的产品实现方案之后,就应该跟核心开发同学做一次小范围的深入沟通,主要确定
需求的实现逻辑都是可行的
评估实现成本
是否跟原有产品逻辑有所冲突
是否还有没有考虑到、或没有说明清楚的需求点。

在评审前跟开发同学做充分的沟通,可以极大减少评审中被拍的次数。

4、终极绝招:产品经理必备撕逼技能

这个世界上不缺少挑刺、抱怨的人,但是缺少能给出建设性意见的人。

所以当面对只会说你的方案这里不对,那里不对的人,

那需要提醒他:

“如果你觉得我是错的,那你最好证明你是对的”

或者

“如果大家没有更好的方案,那证明现有的这个就是最好的。”

还有哪些比较好的方法可以避免评审被拍,欢迎大家在文章下面留言补充... ...

 

作者:菜花(个人微信公众号:caihuatan2016),前阿里巴巴产品经理。目前在某O2O电商公司负责营销产品线。

关键字:产品经理, 常见问题, 需求评审, 评审

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部