揭秘中后台产品工作流程:从需求到上线的关键步骤

0 评论 2533 浏览 10 收藏 14 分钟

本文提到的产品经理工作流程,主要来源于本人在日常工作中的总结凝练,并不适用于所有公司的实际工作流程,仅供各位大佬参考,欢迎大家批评指正哦。

一个中后台产品项目从最开始接到需求到最后开发完成上线,这期间产品经理到底运筹帷幄了哪些事情?经过了哪些流程?一个需求到底是怎么完成的?

本文将对产品经理的大致工作流程进行阐述,因为本人做的是中后台系统方向的产品,所以讲述的流程和C端产品经理的工作流程多少会有些出入,当然我会尽量从更广的维度上去概述产品经理的工作流程,争取把平常的工作流程都覆盖到,后续再写文章对各个流程做详细的介绍。

一、需求收集

所有的产品需求,必定会有一个需求的来源。

常见的需求来源有:

1、业务人员提需

业务方在使用产品的过程中,会反馈产品的bug、体验、流程等各方面的问题。

此处的业务人员,你可以将其理解为一个泛称,它可以是客户、老板、领导等各个使用产品的角色。

2、技术人员提需

技术方案的升级迭代,有时也需要产品的同步支持。或者可能会有技术上一些解决问题的手段,需要产品化和平台化,方便各部门员工的使用。

3、产品规划

产品规划,需要适应公司战略方向,所以当战略方向有所调整时,产品规划可能也要跟着有所变动,这个时候,就会有新的产品需求出现。

二、需求记录

产品经理不可能一下子把所有需求都做完,总要有一个先后顺序,所以就会涉及到需求的记录管理。

一般产品经理会将需求放到需求池中,记录清楚需求的提出人、提出时间、需求描述/需求场景、需求类型、需求进度等信息。

产品需求池要秉承一个宽进严出的原则,在需求收集阶段时,可以广泛的收集需求,不用太过于深究需求的合理性,主要就是做好需求的记录,便于后期追溯和需求分析。

三、需求分析管理

需求分析到底分析个啥呢?主要就是弄清楚需求的真伪、价值收益、成本、本质、优先级等,进而综合考虑有哪些需求要做、什么时候做、谁来做、投入多少资源等。

四、需求评审立项

所谓评审立项,各个公司的方式更是五花八门,有的公司需要需求发布,讲明需求背景、收益、成本等各个条件,各个有关部门的老板们觉得ok了,这个需求才能安排开发人力,正式提上日程;有的公司产品总监一个人就能拍板做不做一个需求。

虽然立项的方式有繁有简,各不相同,但立项这个步骤是不可省略的,这标志着一个需求从冷冰冰的需求池中正式提了出来,踏上了即将上线的路程,所以产品经理需要重视立项这个步骤。

五、需求调研

有同学可能会问了,在需求分析管理阶段,不是已经分析过需求了吗,为什么又要有需求调研这一步,两者有什么区别吗?

需求分析管理,产品经理解决的是要不要做一个需求的问题,而需求调研,解决的是如何做的问题。

特别是b端产品,涉及到较为复杂的业务场景,以及不同用户角色间的需求差异,所以在做需求时,就需要通过调研,了解业务实际,综合的考虑需求实现方式,避免需求场景遗漏,或出现顾此失彼,考虑不全的情况。

至于具体的需求调研方式,常见的有访谈法、问卷调研、观察法等,产品经理可以根据自身实际情况,灵活掌握并判断使用什么方式。

六、竞品分析

不管是B端产品还是C端产品,竞品分析都是一个做好需求的利器,大到产品架构,小到功能交互和文案,都能通过竞品分析来获取灵感。

因为很多东西,你空想的话是很难想出来的,而且还会浪费很多时间,所以要善于使用竞品分析,站在巨人的肩膀上。

正所谓天下文章一大抄,就看你会抄不会抄。做竞品分析肯定不是让你原封不动的照搬人家的东西,那样的话,一是不道德,甚至有法律风险,二是可能并不符合需求的实际情况。所以竞品分析更多的是提供方向和灵感,就算是抄,也要有差异化,做到“因地制宜”。

七、需求方案设计

对于新人产品经理来说,这一步往往是最让人期待和激动的,就好像学了好久的车,终于可以上路行驶了一样。

不过新手上路,总会碰到一些意想不到的情况,如果没有什么经验,或者考虑不周,难免会有些磕磕碰碰,出产品的需求方案也是一样的道理,需要谨慎细致,考虑全面。

出需求方案,并不是一上来就开始画原型写prd,而是还有一些前置工作需要做。

需求调研清楚后,产品经理需要绘制相应的用例图/业务流程图/产品结构图/系统交互流程图/状态图等各种需要的图,不过这些也要看具体需求的复杂程度,并不是每个需求都要画一堆图出来,产品经理可以根据实际情况,判断是否需要以及需要绘制哪种图。

一般较为常用的是流程图和产品结构图,流程图帮助产品经理在动手画原型之前,梳理清楚主干、分支和异常流程,避免遗漏关键场景;产品结构图一般包括了产品信息和功能,基本上产品结构图画好后,产品原型图就能跟着画出来了。

不要一上来就画原型的另一个原因,是因为在主要流程还没有梳理流畅时,原型画起来会很慢,而且很容易出错,而错了改起来又很麻烦,费时费力,还不一定能把逻辑搞清楚。

所以可以先用低成本的流程图理清逻辑,利用流程图跟业务和技术去沟通,如果发现错误还能及时修正,避免后续大反工。

做完前置工作,再画原型、写prd就会流畅很多,即使发现没有考虑到的地方,也能很轻松的进行修改。

八、需求方案评审

需求方案出来后,如果没有其他情况的话,接下来的一个大动作就是要需求评审了。

需求评审对于很多产品经理,不管是新手老手,都是一座山,被怼互撕那都是常有的事情。所以产品经理不仅要平时和研发同学搞好人际关系,而且要尽可能的把需求文档写好,在实现需求的同时,也要考虑研发成本。

评审前

可以把方案发给关键的业务和技术人员看一看,避免用一个有巨大逻辑漏洞的方案来进行评审,否则那种感觉真的会很难受。

另外,大家都很忙,召开评审之前,一定要确定好参会人员,约好大家的时间,将方案发到群里,给大家预留看文档的时间。

评审中

对于各方提出的问题,要及时做好记录,如果有会议录制条件的,最好进行录制,一是如果会后有遗忘的点,可以回溯查看,二是留下评审的证据,如果后续有甩不清的锅,可以看看评审记录到底当时是咋说的。

另外,评审结束时,记得让开发给排期,有时较为复杂的需求,技术可能还会有一个技术评审才能出排期(如果涉及到ui介入的,还要有ui设计的排期),总之,要及时跟进要排期,防止需求开发被一拖再拖。

评审后

需要将评审中提到的需要改动的点,或者是一些待办事项总结好发给各参会方,如果有群的话也可以发到群里,并艾特全体成员。有针对某个人的待办,也可以再单独私发一次,防止对方遗忘。

九、跟进开发进度

ui、前后端、测试的排期给出后,接下来一段时间,产品经理的主要工作就是跟进开发进度了。

跟进开发进度,除了单纯的过问开发进度,保证开发按计划进行之外,还要积极配合前后端的开发。

因为有些问题在评审中可能并不会暴露出来,对于前后端在开发中抛出的问题,产品经理要及时处理,做出决策,毕竟在没有项目经理的情况下,产品经理一般是会作为需求的主owner的,一定要对得起岗位名称中“经理”这两个字,做一个负责任的产品经理。

在开发过程中,原则上是不做大的需求改动的,如果有需要改动比较大的情况,只要不是本期必须要实现的功能,也不是碰到技术不能实现的功能点,都可以考虑放到下一期需求迭代中,确保当期需求顺利开发完成,避免拖泥带水。

十、走查测试

需求开发完并联调后,前后端一般会给出一个走查环境(也可以叫测试环境),产品经理需要根据需求文档进行走查测试,排查问题,由开发人员及时解决。

走查时也要注意,一定要细致全面,如果在走查过程中有什么新想法,或者发现哪里由遗漏(prd中没写,但是却需要的),小改动可以跟开发人员协商直接在当期做了,如果是大改动的话,只要当期需求能跑的通,尽量把改动点放到下一期进行迭代。要是因为产品经理执意加需求导致需求开发延期,那么这锅是绝对摘不掉的,一定要注意。

测试工程师介入测试,可以和产品经理走查并行,也可以在走查之后进行,具体什么时候开始测试,可以看公司的工作习惯和需求的难易程度,一些太小太简单的需求,可能不需要测试工程师的介入,走查没问题即可上线。

十一、上线验收

终于迎来了这关键的时刻了,激动人心啊。

但是也不要高兴的太早哦,产品上线后,产品经理也要进行线上验收,如果涉及到灰度发布,后续还要看什么时候全量发布上线。

为什么上线前也走查了,也测试了,上线后还要再检查一遍呢?因为产品上线并不是像打开一个开关一样,点击一下上线就上线了,在上线过程中,有可能会出现各种各样的问题,这都会影响产品实际到线上的效果,产品经理要和前后端开发人员一起,防范并处理产品上线后可能出现的风险。

十二、撰写操作手册

产品终于成功上线了,对于中后台产品,或者是B端产品来说,较为复杂的需求上线后,需要撰写操作手册,并组织相关培训,方便业务人员的使用。

十三、数据分析

产品上线后,到底能不能被用户认可,就要通过相应的数据分析来体现了,如果产品上线后,压根就没什么人用,那么很有可能这个需求就是个伪需求,或者是缺乏相应的运营手段支撑。

本文由 @向上的小霍 原创发布于人人都是产品经理,未经作者许可,禁止转载。

题图来自Unsplash,基于CC0协议。

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!