产品经理在和开发进行需求评审时,经常刚开个头,就被各种问题拖入无止境的解释、争辩、开小会中,结果通常就是会议几个小时无结论,强行推进开发,后期各种需求变更,搞得大家都很疲惫。今天思考的话题就是如何避免这样的情况。

就结论而言,就是四个字:做足准备!

首先,我们在写需求画原型时,要做足准备

第一,产品经理在做原型时,不要一开始就画交互界面,而是单独列一个区域,把这个版本需求的来龙去脉说清楚。包括为什么要做这个版本,要满足哪些人的哪些需求,做了这些后有什么价值,如何证明,以及大概要做的模块都有哪些,时间估算等等,让每个来开会的人一上来就有宏观意识。

第二,涉及业务流程的需求,也要单独列一个区域,专门绘制流程图,并把流程图中的「概念」解释清楚,然后才是针对概念的交互界面,这样也能方便开发迅速理解业务,再和交互稿对照查看,印象更深刻。

第三,在绘制交互界面时,也要尽量按目的、按逻辑分组归类。比如将「提升用户活跃」作为大分类,在这个分类下,「推送功能优化」作为小分类,在这个小分类下,我们要做哪些子模块,层层分解。

其次,我们在会议召开前期,也要做足准备

第一,在和全体开发开会前,尽量提前和开发各业务负责人召开一个小会,进行需求初评,目的是提前收集问题,沟通是否有技术难点,确认需求的开发成本,并从技术的角度看是否有考虑不全的逻辑漏洞等等。如果存在需求不足的地方尽快修改。当然还可以让开发负责人向下简单传达要做哪些需求,让大家心里有数。

第二,在会议召开前,一定先通过邮件形式发布会议召开邀请,同时附上即将要讲解的原型文档,至少提前1天让所有参会人员了解需求。当然最好在发完邮件后到每个开发座位上再提醒一下,督促大家去阅读文档,有较大分歧的反馈尽早收集处理。

最后,在召开会议时,更要有备而来

第一,每一个需求点,产品经理自己要有充足的理由说服大家,无论是数据证明,还是市场调研,还是用户心理分析等等,尽量避免说出「我觉得应该XXX」这样的话,而是讲客观依据。

第二,每一种交互设计,都尽量有几套方案备选,如果大家对已画出的交互意见较大,就再摆出几种备选,让大家有目的地展开讨论。

第三,产品经理讲解交互稿时,可以先讲总体,再讲重要细节,再讲次重要细节,并层层确认。比如订单支付流程,先讲解支付顺利的主流程,再讲解支付失败的异常流程,最后再讲解支付成功、失败的交互效果。这样做的好处是限制讨论边界,避免理解偏差。

第四,对于会议上争议较大的问题点,有个「5分钟」原则,5分钟后还没有结论,就记录下来,会后再单独讨论。如果问题点太多,就说明产品经理还没考虑清楚,那就尽早结束会议,重新修改原型,再召开一次会议。当然我们还是希望这样的情况不要发生,因为非常浪费时间和精力。

最后的最后,再介绍一个小经验

就是建议将PRD、需求FeatureList和原型都画在一起,统一讲解,这样能提高效率,减少理解成本。如下图所示:

当然这是我个人经验,不同公司可以根据情况调整。

以上是我的思考,你们公司是如何做需求评审的呢?期待你的留言。

欢迎关注作者的微信公众号:「互联网悦读笔记」

「设计评审技巧」

================明星栏目推荐================

优优教程网 UiiiUiii.com 是优设旗下优质中文教程网站,分享了大量PS、AE、AI、C4D等中文教程,为零基础设计爱好者也准备了贴心的知识树专栏。开启免费自学新篇章,按照我们的专栏一步步学习,一定可以迅速上手并制作出酷炫的视觉效果。

设计导航:国内人气最高的设计网址导航,设计师必备: http://hao.uisdc.com

点赞
收藏
继续阅读相关文章

发表评论 快来秀出你的观点

还可以输入 800 个字
 
 
载入中....
评论 收藏