微信扫码登录

其他登录方式

绑定手机号

注册

我同意用户协议

忘记密码

用户协议

绑定手机号

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

需求评审前、中、后三阶段,都该做好哪些准备?

来源: 309226

作为产品经理,需要注意哪些事情,才能让一个需求评审能够高效的完成呢?

需求评审前、中、后三阶段,都该做好哪些准备?

需求评审目的是让项目的参与者(这里主要指研发测试)能够快速理解产品的意图,认可采用的方案。那作为产品经理,需要注意哪些事情,才能让一个需求评审能够高效的完成呢?

可以先回忆一下我们评审过程中遇到的一些问题:

“这个做了有什么用?”

“有没有认真想过?”

“唉,你这个做了,之前的XX是不是就没用了”

“这个做不了”

“有和业务方确认过吗?”

“你这个需求这么大,一下子评的完吗?”

“我靠,你是不是傻X,哪有这么设计的?”

“你是产品经理,你的数据呢?”

(欢迎留言补充)

不管是新手上路,还是老司机开车,在需求评审过程中,相信都碰到过上面的情况。为了让效率更高,目标明确,我们可以在评审前、评审中和评审后做相应的准备:

1、评审前——做好产品基本功

  1. 如果是一个商业产品需求,请和你的业务方认真推演产品要解决的问题。注意要抠出业务方要解决的问题,而不是问业务方“你要不要这个功能?” 作为产品经理,你要相信自己的产品设计能力,业务方提供的产品方案可以作为参考,不能作为指南。
  2. 如果一个是工具类的产品或者体验层面的优化,请认真分析各个方案背后的用户心理变化,同时准备好相关数据佐证你的假设。评审上可能用得到
  3. 仔细推敲产品方案,是否有考虑过还有其他的方式可以解决问题,不同的方案优缺点各是什么。
  4. 提前找到此项目对应的技术负责人,认真的和他们沟通你的方案和想法,技术的小伙伴们不是被动的执行者,让他们参与到你的前期设计中来。
  5. 请去掉“我是产品经理,我比你懂市场,我比你懂交互,我比你懂人性”的帽子,很多技术小伙伴真的比你懂。
  6. 准备好一份逻辑清晰的需求文档,形式不局限,核心是要表达清楚你的意图。
  7. 如果之前评审经常出现表达混乱,说的意思别人不容易懂。你可以再辛苦点,准备好一份评审大纲
  8. 仔细review你的需求文档,是否各个细节都考虑到了,尤其是异常的情况,和其他系统有依赖影响的情况。不然测试的同学会把你问的哑口无言

(欢迎补充)

2、评审中——注意表达,注意情绪,控制好节奏

1)参与评审的技术,他们的关注点可能各不相同。有的擅长剖析你的需求动机业务目标(大部分的技术leader会关心)、有的擅长追求细节(比如测试同学)、有的喜欢带偏话题(在你评审的时候,可能他们会提一个其他的话题)、也有的喜欢用“教导你”的口吻“教你”做怎么产品,还有各种各样

2)需求开始,可以先讲清楚你的业务背景,确保大家理解的前提下再带入你的方案。然后记得要阐述为什么要用这套方案,而不是其他方案。这两件事情需要在开始就说的很清楚,讲完后可以停顿让大家提业务背景和方案的问题。这里要掐断那些喜欢问交互细节,逻辑细节的问题。

这一步骤的重点是要说清楚发生了什么问题,为什么这么干而不是那么干——这样不至于在后续的环节里,又有人提回来质疑你的需求背景

3)复杂的问题,考虑用一些流程图,再结合“总分总”的方式。可以先说明白整理步骤,先做什么,再做什么,最后做什么。然后再按步骤细评各个环节的细节,都评完后再阐述一下总的流程。

4)注意话题不要被带偏。在过程中,出现某个同学说“唉,之前有个XX也是类似的问题,还没解决”。这个时候作为产品经理,应及时掐住话题源头,可以说这个问题待会私下讨论。

5)新人控不住节奏的时候,可以求助会议上稍微资深的技术大大来控制节奏。   “这个问题好像和本次评审无关,李大大我们会后再聊这个,你看怎么样?”——李大大可能是个技术总监。

6)你也会遇到喜欢爆粗口的技术。“我操,这有个屁用啊!”“你是不是脑残啊!”  我们要控制好自己的情绪,因为这个粗口的背后,他们想表达的意是:“这样设计是不是不对”?只是加了一个感叹词嘛。听他们把背后的原因说出来,不建议用“为什么没用啊?”“这样挺好的啊”“我靠,你才脑残”来正面回应他们的感叹词,这会让气氛更尴尬,后面的评审更难进行。可以问“是有什么问题吗?”“方案哪里不合理?”

7)“这个不好做”、“实现不了的”。遇到技术们这样的回应时,绝大情况下是背后有一个巨大的开发量。不建议直接驳斥“这个还这么麻烦啊?”“很简单的啊,这样搞搞就行了啊”。我们需先权衡是否值得这样的投入?如果的确是一个很重要的业务卡口,可以表达清楚这件事的严重性,就算开发复杂,需要较多的时间也可以接受。

8)做好会议纪要!以便会后讨论和修改

3、评审后——保持持续跟进,反复review

  1. 评审结束不代表就等着上线了,接下来要做的是持续的关注。需要不断的review,确保该表达的细节都有表达
  2. 需求更新,请维护好更新的记录,在什么时间点更新的,请通知相关的开发测试设计同学,不要藏着掖着
  3. 跟进开发计划和进度
  4. 准备二期的内容

最后一句,你得让技术感受到你是要做好产品的,不是完成任务的(自行体会)。希望可以帮到你~

 

作者:嘿嘿Beta,资深电商产品狗,微信公众号:heiheibeta

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

题图来自PEXELS,基于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号