2020年开年一篇:我的产品策划流程是怎么样的

经常性的在网上看到产品新人在问“新人怎么走好产品经理这条路”,感觉这个问题还是比较后面的事情,回头想想貌似一直在默默的接受别人的干货,刚好今天心血来潮,就在这里分享下自己关于产品经理新人应该注意的事情的经验,为广大同胞贡献点绵薄之力。

新人刚进公司时,正常都只会负责原有产品的优化且有一段的时间让你熟悉产品,接着提供一些优化建议,个人认为这是很关键的一个环节,它能严重影响领导对你能力的评估。

为什么这么说?

因为一般人都只会基于现有产品的业务提出一些用户体验方面的优化,假如你能在这个基础上再增加一些产品发展方向的建议,可以简单到只是同业/同类产品有而现有产品没有功能,甚至你都不用去分析本身这个功能的对错,因为在这个地方你要展示给领导是“你在关注这个产品”。

PS:这也是做竞品分析的入门阶段。

接下来,就是各种提需求,推进需求落地的阶段(建议优先了解公司的工作流程,这有助于你后续的推进工作,不至于不知道哪个时间段该做什么事)。

推进需求落地的流程一般都是“原型—与项目组开会讨论—开发阶段—业务验收—项目上线”。下面就说说在这个流程的各个环节需要注意的点:

原型环节

一般的公司产品经理也要充当交互设计师。

首先你要先了解公司项目组对原型的要求,面对客户的一般都需要动态交互的原型(有网页交互效果);针对项目组的,一般静态的原型即可解决,特别的敏捷开发的项目组,只要在开发的时候多做沟通即可。

与项目组开会讨论

在这个环节,有技术经验的朋友可能比较容易沟通一点。

除了比较清晰、完善的讲解你需求的内容外,最主要的一点是需要项目组给你反馈开发计划,这是你项目进度的保证,也是避免后期项目出现延期等情况时,自己有苦说不出。

开发阶段

不要以为项目进入开发就没什么事情,你需要根据之前项目组反馈给你的计划进行开发进度的跟踪,这样在开发进度出问题时,才能及时与相关负责人沟通,保证开发进度,不要等项目延期后,两眼一摸黑,说不出个所以然,因为领导都是只问结果不管过程。

业务验收

业务验收这个环节在整个项目里尤其重要,因为它的最终结果是项目能不能上线的保证,特别是用户体验方面的问题,经常性会碰到;另外一方面,正常情况下来讲,前面一般会确认项目的上线时间,所以BUG的修复进度关系着产品能不能按时正常上线,如果你要的不是一个残次品,建议在验收前期就要做好奋战的准备。

项目上线

这个包括的内容比较广泛一点,如果是一个新的项目上线,都会包括用户协议、市场/销售部门的培训以及项目上线后的用户意见收集等;如果是优化的内容,一般只会有市场/销售部门的培训以及项目上线后的用户意见收集,这时候要特别留意用户的反馈,不要以为上完这个东西就算交差了。

2020年祝大家新年快乐!

记得刚开始做产品出需求方案的时候,上来就开始画原型写文档,在写的过程中发现某个交互没想明白或者漏了一部分逻辑,然后回过头来再修改或者补漏,这样前前后后折腾好长时间,终于做完了一份完整的方案,等重新检查的时候,发现又漏了某个地方流程有问题,于是又改,反复折腾之后终于完成了初版。

然后等到需求评审的时候,面对技术爸爸们的各种疑问如坐针毡,发现又漏了好多的逻辑和细节,等到需求评审结束的时候,已经被需求折磨的死去活来。

出现这样的问题,一是因为刚开始做产品方案设计,基础产品交互规范的熟练度不够。还有就是急于完成任务,对于需求或功能的整个没有思考的很明白,太过于专注方案以及功能本身的实现。

后来做的需求多了(踩的坑多了),慢慢的修正自己过去在做产品方案的中一些问题,也跟身边同事交流,整理了一套比较符合自己的产品设计流程,可能不适用所有的场景,是我目前用的比较多的一套流程。

一、“看”竞品

说到看竞品,很多人的第一反应是要抄么?我们一般刚开做需求方案的时候,常见的套路就是选几个相关的竞品或产品,对着某个功能抄一遍,然后形成自己最终的方案。

这时候我们的注意力还是方案或功能实现本身,并没有深入的思考内在的逻辑以及背后的动机等等。就像上学的时候,交作业前拿过来同学的作业对着答案直接抄了上去,并不会再去想答案背后的演算流程。但是也有老师会说,同学们你们抄作业可以,但是你们一定要弄明白抄的答案为什么是这样。

看竞品也是同样的道理,在开始策划一个需求方案的时候,我会找到竞品功能或者相关的功能,深度的体验相关的功能,弄明白整个功能的逻辑以及流程,体验功能交互上手的感觉,对功能的效果有个初步的判断。

同时要做好记录,对于竞品做的好的点以及关键点的实现逻辑做好收集记录,然后对同一功能或模块在不同平台的实现方式或者关键点的差异尽可能的收集资料,尽可能作出符合逻辑的思考和解释。做完这一步对需求整体的实现逻辑以及流程有了初步的掌握,可以开始下一步。

举个简单的例子:策划登录注册功能,同样的登录注册功能可能在不同的产品上具体实现的业务逻辑或流程都会有不同,注册门槛的差异、注册流程的不同、注册信息的、登录场景的不同等等,都跟具体产品的需求场景和特性有关。

二、理思路

做完竞品调研后,就可以着手开始自己需求的策划。在对业务逻辑以及功能流程有一个大概把握的前提下,再结合自己产品当前的现状以及实际场景从整体到局部开始进行(说到整体到局部的系统化思维,推荐一本很多人都看过的书《金字塔思维》)。

从需求背景、需求目的、功能流程、功能list、关联需求等等,开始整体思路的梳理。功能list以及功能流程,在竞品调研的基础上是最容易出整体思路的模块,也是产品功能设计本身,但是需要注意的是,产品功能本身只是需求策划其中的一部分,不是需求全部。

我经常踩坑是,关注需求流程和实现本身,而忽略和需求相关联的其他需求点和事项。比如,新的需求方案对于已有需求影响、新老版本兼容的问题、涉及的财务、运营等各个流程的变动问题、功能的推广问题等等,以上都是需要根据需求的实际背景事先进行考虑以及规划的。

还有经常被忽略的一点就是需求价值以及效果的衡量,我刚开始做产品经常有的问题就是埋头于如何实现整个需求,对于需求的价值以及效果很少考虑,做了很多东西但是并没有好好回顾其中的价值,对于工作的回顾和产品的认知是很不利的。

等梳理完框架以及流程之后就可以先跟boss或相关同事提前进行沟通,在大方向以及思路一致的情况下再开始撸需求文档,如果在思路框架都没有保持一致的情况下,就直接上手开始画原型撸文档,后面如果一旦思路或者框架需要调整,可以快速的进行修正。

接上面的例子:关于登录注册模块需求的实现,做完竞品调研,根据自身产品特性可以确定功能模块以及流程,比如内容型产品,前期降低登录门槛,可以直接使用第三方登录,同时获取用户的基础信息以及注册账号。

三、扣细节

框架流程有了,就可以开始第三步最终交互设计的完成和需求文档的撰写,在前面思路以及流程梳理清楚的基础上,开始画原型写文档,整个过程会相对顺畅很多,避免走很多弯路。

交互设计以及需求文档撰写算是产品基本功,在框架流程完善的基础上,再开始画原型撸需求。可能很多人最开始做需求文档的时候会纠结于用什么画原型、原型要不要高保真、文档的格式是怎么样的?

在最开始撸需求文档的时候,我也会纠结要用什么原型工具,Axure用很多了,要不要尝试一下墨刀?原型太丑了,是不是做的更好看一些?需求文档应该怎么输出:直接在原型标注输出还是输出标准的文档?也会网上搜各种类型的文档进行借鉴模仿。

后来在不同的团队输出过各种样式的需求文档,不再纠结于原型以及文档的格式。文档只是用来承载你的思路和方案的载体,用来跟开发测试团队沟通的媒介,还有很重要的一点就是留底(谁应该来背锅)。至于输出的格式以及文档的风格,还是看团队风格以及个人习惯,在符合团队风格的基础上,怎么高效怎么来。

需求文档也是一个持续迭代优化的过程,就实际经验来说,不可能一次性写出一个完美的需求文档,在需求推进的过程中,随着需求评审、开发、测试,需要不断的进行优化调整,要做及时好变更记录,快速的同步相关的同事,以免因为信息不同步导致功能出现误差。

到这里你总算撸完了一套需求文档,可以稍微松一口气,开始进入进行需求PK环(撕逼环节),在撕逼和背锅的路上开始狂奔。最后需求终于上线了,你想着可以松一口气了,然而等着你的是更多的需求以及文档……

文章由PM28网编辑,作者:海阁,如若转载,请注明出处:http://www.pm28.com/3117.html欢迎投稿

联系我们

在线咨询:点击这里给我发消息

邮件:403567334@qq.com

工作时间:周一至周五,9:30-18:30,节假日休息