微信扫码登录

其他登录方式

绑定手机号

注册

我同意用户协议

忘记密码

用户协议

绑定手机号

近期有不法分子打着爱盈利的旗号,制作“爱盈利”名称的App,并伪造爱盈利证件,骗取用户信任,以抖音点赞赚钱或其他方式赚钱为名义,过程中以升级会员获得高佣金为名让用户充值。
爱盈利公司郑重声明:我司没有研发或运营过任何名为“爱盈利”的APP,我司做任务赚钱类产品从没有让任何普通用户充值升级会员。我公司产品均在本网站可查询,请将网站拉至底部,点击“关于我们”可查看爱盈利相关产品与服务。
温馨提示:当遇到此类问题请拨打官方电话或添加官方微信,以免财产损失。爱盈利官网地址:www.aiyingli.com。
  • 推广与合作
X

关于需求评审的一些实践方法和思考

来源: 310188
爱盈利(aiyingli.com)移动互联网最具影响力的盈利指导网站。定位于服务移动互联网创业者,移动盈利指导。我们的目标是让盈利目标清晰可见!降低门槛,让缺乏经验、资金有限的个人和团队获得经验和机会,提高热情,激发产品。

开需求评审是产品经理的工作内容之一,那么如何做好这项工作呢?梳理自己在工作中的实践和感悟,希望能找到更适合的最佳实践方法。

关于需求评审的一些实践方法和思考

需求评审的作用

1. 向他人传达自己设计理念

如何在会议上讲解清楚自己的设计思路并得到大家认可,是需求评审前应准备和考虑的问题。

2. 发现自己设计的不足,查漏补缺

一个人的思维毕竟是有限的,通过评审,让不同角色的人员站在不同的角度审视方案,是很好地补充自己思维不足和发现方案缺陷的方式。所以,没有评审,没有交流,没有讨论,是一件多么可怕的事情。

3. 推动研发工作的重要节点

每次的需求评审都意味着产品研发进度又前进了一步,说明各项工作在慢慢不断完善和向前推进。

4. 凝结团队成员的力量

通过开会交流、讨论,团队成员对自己的工作有更清晰的认知和责任感,也是无形中团结大家向同一目标努力的一股力量。

需求评审的流程

1、版本范围评审会

当一个版本开启时,需要先界定此次迭代的范围。产品经理先根据需求优先级,确定一些需要做的需求点,并对这些需求点的业务逻辑和功能设置可进行清晰地阐述。迭代需求点确认后,召集需求方(如tob系统的业务部门、运营部门等)、后端、前端、UI等干系人参加评审会议。此次会议更像是一个版本启动会(类似项目启动会),目的在于:

  • 正式告知需求方,接下来我们打算做这些功能,若他们有更紧急的需求,可及时提出,保证每次迭代都在做最紧急重要的需求(当然,不同的部门会从自身角度出发提出要求,此时,需要产品经理进行综合考量)
  • 使团队每个人对接下来将要做的事情有一个初步的概念和认知,使团队就此事达成共识;
  • 使每个人对自己接下来的工作做到心里有数,接下来有这些活等着我;
  • 技术人员(尤其是后端)评估功能实现的技术难点及可行性,避免原型、交互等前期工作做完后,交到技术人员手上才知道有技术瓶颈造成前期工作和资源的浪费。

此次评审需特别注意:需求点讲解的粒度不应过细,产品经理只要讲清楚,接下来我们将要做XXX这几条需求,每个需求大概实现的是一个什么功能即可,避免陷在业务细节中,偏离会议的主旨。

2、功能方案业务确认评审会

产品经理根据确定后的需求列表,初步完成设计原型方案后,召集业务或需求方(若无需求方,应在产品组内部进行评审)对功能设计进行评审确认。此次评审相当于方案确认会,目的在于:

  • 从不同的视角审视方案是否符合需求,是否合理;
  • 查漏补缺,通过评审,可以及早发现问题并及时补充完善;
  • 通过业务需求方的审核,使得产品设计更贴近实际需求

此次评审,讲解的重点在于,每个需求点是如何转换为页面上的功能结构的?这样的功能结构是如何满足需求的?为什么是这样的结构,设计的思路是什么?有人说,产品经理最难的是,说服别人肯定自己的设计,此次会议要达到的就是这个目的。

3、UI交互需求讲解评审会

方案经过评审后,完善修改问题,无误后,即可开启UI设计。此时,召集UI人员讲解和沟通需求。此次评审会的目的在于,让UI理解每个页面,为什么这个页面上有这些功能点?这些功能点之间的联系是什么?在讲解的过程中,应着重于页面交互和功能说明,避免过多的业务细节困扰UI。

4、前端交互需求讲解会

待UI出具了交互和设计规范后,需想前端宣讲细节。此次会议主要由UI负责人讲解,产品经理辅助解释。以前端人员理解规范、交互和功能设计初衷为目的。当然在开会前,产品经理应该对交互设计稿先进行审核,发现与需求不满足的地方,并进行讨论修改。

5、后端技术需求评审

业务细节规则、功能设计符合需要,需求方通过评审后,可交由后端技术设计数据表等准备工作。此时召集所有技术人员,一个个功能点进行详细的业务逻辑介绍,旨在帮助研发人员理解业务细节,帮助他们更好地进行架构规划和代码编写。

6、评审路线图

大致可以总结成下图,当然各项评审之间没有固定的前后顺序,不同职能间若不是强关联,往往是并期进行的:

关于需求评审的一些实践方法和思考

(在新标签页中打开,即可查看大图)

需求评审的注意点

除了细节功能的讲解,宏观大框架的交代也必不可少:

  1. 交代产品定位和目标:不要一开会就马上进入细节功能,balaba讲一通,别人还没反应过来,你给讲完了。应该先交代你要做的是个什么产品?PC端、移动端?APP、H5?为什们打算做这个产品?若是后期迭代,此处交代此次迭代的目标即可。
  2. 交代产品的面向用户:产品是做给谁用的呀?产品给这些人提供什么样的功能呀?此次迭代的功能主要是面向哪一些用户的呀?
  3. 交代产品的功能架构:这么多功能,他们之间的层级关系是什么样的?是用什么样的线索和结构组织起来的?
  4. 交代功能设计的思路:一个产品肯定有一套统一的设计思路,比如统一的信息展示、统一的页面流转路劲。

总结一下,大概下面这些内容是都应该讲解的:

关于需求评审的一些实践方法和思考

诚然,不同的项目、产品、团队,实际的操作方式不同,但想要达到的效果一致,关键在于找到一个清晰的标准又灵活的适合自己的操作方式。

 

本文由 @小麻雀 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

爱盈利-运营小咖秀(www.aiyingli.com) 始终坚持研究分享移动互联网App运营推广经验、策略、全案、渠道等纯干货知识内容;是广大App运营从业者的知识启蒙、成长指导、进阶学习的集聚平台;

想了解更多移动互联网干货知识,请关注微信公众号运营小咖秀(ID: yunyingshow)

评论

相关文章推荐

SELECT dw_posts.ID,dw_posts.post_title,dw_posts.post_content FROM dw_posts INNER JOIN dw_term_relationships ON (dw_posts.ID = dw_term_relationships.object_id) WHERE 1=1 AND(dw_term_relationships.term_taxonomy_id = 3083 ) AND dw_posts.post_type = 'post' AND (dw_posts.post_status = 'publish') GROUP BY dw_posts.ID ORDER BY RAND() LIMIT 0, 6

京ICP备15063977号-2 © 2012-2018 aiyingli.com. All Rights Reserved. 京公网安备 11010102003938号