产品经理再接到需求后应该从哪些方面思考?

接到需求后,如果直接画图,就成了画图的了,应该如何考虑才能全面呢?生怕有遗漏的地方
阅读全文
请先 登录 后评论
  • 0 关注
  • 0 收藏 60 浏览
  • 略问用户 提出于 2020-10-22 17:36:03

25 个回答

xxxxxa

默默的,就有了邀请的功能了啊。谢邀!

各人有各人的工作习惯,各个团队之间也有各个团队的配合习惯,就这个问题我觉得是没有唯一性答案的,只有适用性答案的,适合你的才是最好的。

在这里分享一下我的工作流程,大家一起探讨一下。


第一步,与需求方进行沟通,主要是复述你接收到的需求,确保需求接收正确没有存在理解偏差

第二步,我把它叫做清洗需求池,把接收到的需求进行清洗,分类出那些是已有替代功能完成了的,哪些是在之后的版本中有规划的了,哪些是与公司战略及产品目标不符合的需求,哪些是可以在这个版本加入的需求,同时评估需求的可行性、优先级、难易度。

第三步,将上述第二步的结果形成文档,并提交需求方,最好是自己亲自讲解,获取需求方的同意。

第四步,需求的具体分析,梳理逻辑关系,业务流程。

第五步,原型设计,输出PRD

第六步,开原型评审会,与UI、RD一同沟通需求及PRD,对会上的东西进行及时的补充和改进。

第七步,跟进UI设计稿,确认设计稿

第八步,协助RD开发,开始编辑测试文档(如果有测试,就协助测试完成,如果没有,就自行完成)

第九步,测试,验收产品

第十步,上线,交付产品

请先 登录 后评论
xxxxxa

我个人最怕的就是拿到需求立刻就开始流程和原型设计的,不经过思考的产出都是对产品的不负责任。

简单描述我的工作流程:

1、需求确认

需求确认是非常重要的一个环节。这里的确认不是简单的明确或者理解了需求方提出的需求,而是要深入挖掘到他需求背后真正的“诉求”是什么。因为很多时候需求方提需求都是拍脑袋提出的,或者经过了自己的一次转化。

所以,我习惯让需求提出方用最简单粗暴的方式描述需求,不要经过修饰和转换。

2、需求分析

当你了解到需求方真实的需求后,那么轮到你开始对这些需求进行分析了。

这些需求的意义、对现有功能的影响、实现的成本、优先级等等。

最后产出一个需求的列表,来作为和需求方沟通的一个指导,最后确定需求。

3、需求转化

确定了所有要做的需求后,才真正开始进入需求转化的阶段。

画场景图、画用例图、画流程图、画原型图、写PRD等等,都是为了把需求转化成技术人员可读可理解的内容。然后交付给技术部门去实现。

4、需求实现

这部分的工作更偏向“项目管理”的工作,目的就是确保开发的进度和方向没有偏差,并正确的能够满足业务部门的需求。

前两步“思考层”是我对产品经理们要求最高的地方,后面两步“执行层”反而有制度和流程控制容易一些。

所以,产品经理应该把更多的精力和投入放到前两步。

个人浅见,供参考。

请先 登录 后评论
xxxxxa

谢邀~~~~~产品狗的日常工作就是跟需求打交道,怎么处理需求?题主的问题提得很好,32个赞

如果你是高级的产品狗:

第一步,判断需求是否符合产品现阶段的规划

第二步,判断需求是否是一个真实的需求

第三步,判断需求的重量级和优先级


看了题主的提问,应该只是负责执行,那怎么处理需求呢

首先,在接到需求时,一定要把需求了解透彻,不要听个一知半解然后自己YY;如果需求传达这一步就出现问题,之后的一切都是无用功,浪费时间精力都不说,连累他人拖累项目;

其次,在动手之前先把业务流程弄明白,什么节点涉及什么部门/功能/页面,该部门/功能/页面在此节点充当何种角色,需要完成什么工作,先梳理一个流程图出来,然后找相关业务人员确认和完善流程;

然后才是根据需求天马行空的去创新,去设计功能和页面;

请先 登录 后评论
xxxxxa

说下我对问题的理解吧,lz应该问的是接到需求后,如何高效、优质的从“想”进入到“做”?

我总结了七步:

一、要做什么——确保你理解需求本身,无关对错。

二、做给谁用——确保你理解假象用户,无关对错。

三、会有用吗——自我辨证假想需求和用户到对错。

四、精确需求——根据辨证结果去完善或调整需求。

五、自我否定——否定已确认需求,考虑最坏结果。

六、确定思路——八字真言:轻重缓急快慢益损

(轻重:产品结构上的轻重;缓急:需求层面优先级;快慢:开发耗时长短;益损:烧钱得体验,还是损体验拿钱。要学会去判断这个功能对用户的重要性,才能更好的去设计和定位。

我不否定体验和盈利共存,但是要赚钱,体验必然会受损,摸钱出去时,心情总是差的。。。)

七:细化需求——根据确定的思路,细化成功能点。

至于说对行业摸底啊,了解市场啊这些的,不都是产品经理的日常修养吗?

请先 登录 后评论
xxxxxa

我的看法可能和大家不太一样,可能也和我之前是乙方有关系。基本在谈需求的时候,就差不多知道怎么做了,所以采集完需求后,可能我就开始动手做了。 一种是框架基本在谈需求的时候就会确定,另一种情况是给你需求的人都不知道要做成什么样。所以你必须快速拿出一些方案给他选择。 可能和我没在大公司呆过有关系,没有专门的用研团队给你参考意见,能做的就是凭着自己的理解,先把东西做出来,再跟需求方确认对不对。这样在谈判的时候更容易沟通一些。 我们在谈需求的时候模块会拆的比较细,每个模块出来后都可以及时沟通。前期最困难的是确认主框架,一旦主框架确认了,后面再做就没那么困难了。 很多产品太过于强调,拿到需求后的理解分析调研,但是真的会有多少产品在工作的时候能做到,或者说有条件做到用户调研。 听完需求后我最多就是画个流程图,理清一下逻辑,就开始动手做原型了。如果做的过程中我有问题,我可能会看大量的竞品。也谈不上什么竞品分析,如果有不错的功能和交互可能会给需求方一些参考。 借鉴并不是一种抄袭,很多大佬也都说过,先模仿像了再做自己的,当你模仿深了自然会体会到别人做产品的意图。不要怕抄,也不要怕错。越快犯错就越有时间试错,而且这里的错是为了做出正确的产品,并不是把产品做错。 还有就是要做什么产品需求的时候,要先了解这个行业,要有准备的谈需求,在谈的时候思路自然就清晰了。 个人习惯不同,公司规模不同,办事流程不同,做事的方式也就不同,你应该做的是尽快适应公司的节奏,找到自己的方法。

请先 登录 后评论
xxxxxa

对,先得谢邀(这样就能显摆我很牛的,是被邀请了才来的哈~)

看你什么程度的产品经理啦,要是产品助理的话,接到需求。和老板复述一遍你理解的这个需求,没有问题了,去梳理流程和画图,然后测试,然后改,然后测试,然后改,然后测试……然后找设计师实现,然后去找前端,然后去找后端上线。(中间还是有无数的测试的)。

这个过程中需要学习流程和交互,学习和设计沟通,学会和开发沟通。不只是单纯的一个画图的。

如果你是产品经理级别产品经理。

1 接到需求。

运营或者市场团队提出的,确认这个需求解决什么问题,要达到什么效果。这是不是最好的解决方案(一般别人给你提需求都是直接提解决方案“狗狗啊,咱们做一个用户等级体系吧)。有没有其他的更好的。全部思考清楚后,觉得做不做,做到什么程度。

老板提出的,二话不说,接。最好问一下老板,这个解决啥问题,要达到什么效果。老板清楚最好,不清楚的话,自己去想的,做这个东西,会有什么效果呢?能带来什么收益的,需要支出多少成本呢?带着方案去找老板,看看你领会的对不对,老板是不是同意做这个。(别说老板傻逼,老板那么精明要你干啥)

2 决定做了,就和 killifer和lmh 说的差不多了,反正大体流程就是这样的,但是做的好不好就是本事了。踏实做好每一步吧。

忘了说一点了~画图的不叫画图的,叫交互设计师,很厉害的。(当时我就特别想做交互设计师,老板看我资质愚钝,说,滚去做产品吧!)

请先 登录 后评论
xxxxxa

楼上的童鞋大多讲的是比较确定的需求,比如来自市场销售的,企业客户的。需求处理的流程都正确,但难点其实在需求清洗,对于摸索型和创新的产品,需求在一开始并非都是确定的。关于需求清洗(深挖),我分享一些经验。

1.需求的背后是否有真实用户故事的支撑;

2.需求的频次,高频,中频,还是低频;

3.该需求是否符合常识,复盘用户故事中的用户角度。分析产生这种问题的原因是什么,动机是什么,有没有数据支撑,推理和总结出真实需求。多询问这种问题,能够帮助产品人员把握到实际需求。功力在这个地方。

4.市场规模与竞争情况。

请先 登录 后评论
xxxxxa

简单回答先:

1、确认该需求是否有必要、是否是需求的原意

     ① 没必要的东西,一开始就该扼杀掉;

     ② 可能存在需求方的意思被歪曲,多顺着问几个为啥;

2、确认该需求再整体需求池子里的优先级

     ① 不够重要的话,先排后呗,都不用后面345678了;

3、进行需求具体分析

     ① 梳理流程以及业务逻辑;

     ② 进一步确定判断条件、边界条件等;

4、画原型图

     ① 针对需求确定页面框架、页面要的信息、信息优先级;

     ② 确定交互;

5、和设计沟通

     ① 和设计沟通需求情况;

     ② 基于设计了解需求的情况下,沟通UI以及交互;

6、和开发沟通需求;

7、核对设计的设计图;

8、检验开发最终撸出来的对应情况;

请先 登录 后评论
xxxxxa

大家都说的比较具体,我说一些实战经验吧

接到需求一定问的细一点

曾经我门老板说了一个需求,我在接到这个需求之后就开始竞品分析做了很久 并且提出了几个方案,但是老板回来对需求发现不是想要的,在具体了解过后,才了解老板只是需要一个很简单的表单就可以。

其实一个需求会有很多方式实现,有体验好的,也有简单粗糙但是需要马上上线的,一定不要想当然做一个自认为完美的东西,所以尽量多的去沟通,除了需求满足功能,可能你也需要去问问需求的背景是什么,大概的简易程度等等

总之磨刀不误砍柴功 个人经历引以为鉴

请先 登录 后评论
xxxxxa

我是这样做的:

1、与需求方沟通确定对需求的理解无误;

2、考虑新需求与现有业务是否有交叉或者冲突的地方;

3、对于有交叉和冲突的地方 考虑新需求会不会对原有的业务逻辑产生影响,有多大影响,评估大概需要花费的时间(产品、设计、开发、测试)。然后在和需求方讨论(带上开发)是否需求调整需求;

4、新需求与现有的没有影响,单独一块。首先考虑需求的用户使用场景、根据场景完善流程图、最后在画原型。

5、原型出来之后在和需求方、开发、设计 进行原型评审

请先 登录 后评论