什么样的需求评审会是高效的?

昨天

产品经理的职位的工作方式,在不同企业中有各式各样。有的负责需求整理、有的负责画原型、有的负责项目管理、有的甚至负责设计.....,但需求评审是整合以上所有环节的核心流程:深度理解需求


最近在带一个新的产品团队,我发现了一个有趣的现象。在评审中,产品经理尽可能的把需求文档写得非常细、逻辑文档一大堆、以及设计完成的UI稿。开发尽可能的少出BUG,不拖延上线。


但结果是:产品越来越累、开发越来越累,但项目却好不起来。


如下案例:


在评审中,产品以瀑布流的方式展现需求,从第一个页面到需求的最后一个关联页面如下图:



注意上面的页面1、页面2、页面3....已经在需求评审中是高保真的原型,你发现这样的流程有什么问题吗?




其实上面的问题会有3个


  1. UI资源浪费

  2. 需求评审效率低

  3. 产品资源浪费


UI资源浪费


我们在需求评审中,因为是需要产品策划方案。产品经理给出的方案首先是要满足用户的,这里的用户可能是一个真实的用户、也可能是一个企业客户或则内部部门。


但在需求评审中,我们可能与开发、领导一起讨论后会拿出来更简洁的方式满足用户需求。这个时候如果采用上面的方案,UI资源的浪费是不可想象的。


因为UI输出的结果页,是不能确定我们会上线用的?而只是为来应付评审而已!如果解放UI资源后,我们可以让UI做一些更多的业务支持。比如出一些banner、去支持其他产品线所需要的UI资源。



需求评审的效率


采取瀑布流的方式,其实页面的连接并不高。我们都知道人看图会比看字符更快的理解意图。


但对一个需求来说,往往是若干个页面组合在一起的。因此采取尽可能的将页面铺展开链接起来,可以帮助参与评审会的同学更快的理解需求。



如上图,我们可以看到这样的页面讲解方式后。可以帮助参与评审的同学大体明确4个方向:


  1. 需求的解决方向如何

  2. 所使用的技术解决方案会是什么

  3. 开发难度与时间如何

  4. 需要的设计时间多少


在评审会中,确定上面4个问题后。其实整体的方案就基本确定了,剩下的就是产品经理去推动、连接各个部门即可、最终上线



产品资源浪费


产品经理没办法自己评估项目的时间周期、技术实现难度。


采取上面团队中的评审方式,其实也会造成产品经理梳理出来的文档是无效的,甚至是需要大部分调整的。


我们通过使用原型页面来确定上面的4个问题后。


产品经理再落地产品需求文档,就会避免这样的问题出现。产品经理可以更多的思考需求是否能解决问题,而不是落地在文档上。


把最终的方案呈现给开发同学甚至是设计同学即可。




当然,不管需求评审怎么变,本质是希望让团队开发、设计更清楚的理解需求。所以我们可以也通过线下私聊的方式和技术、设计去完成需求评审的目的。


产品经理的角色不仅是做一个需求解决者,还要去学会更快的让团队获得成就、与团队共同面对困难。拒绝与开发成对立、设计同步





好啦,今天就在这里。我会每周原创两篇工作的案例



  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值