美文网首页产品经理工作流程
产品经理的工作流程——下篇

产品经理的工作流程——下篇

作者: 加铭 | 来源:发表于2021-06-19 11:18 被阅读0次

    今天接着把在产品经理的工作流程-上篇中,没写完的内容续上。剩下的模块包含:功能设计、需求评审和测试迭代。

    我在上篇说到,产品经理完整的工作流程是:获取需求——需求分析——用户画像——竞品分析——业务流程——功能导图——原型设计——需求评审——需求文档——上线测试——持续迭代。

    我们将竞品分析后面的流程分为三大模块,分别是「功能设计」、「需求评审」和「测试迭代」。

    其中「功能设计」模块中,涉及业务流程、功能导图、原型设计、需求文档的输出;「需求评审」模块涉及需求评审会、PRD修改;「测试迭代」模块,涉及上线测试、持续迭代的工作。

    这并不意味着,产品经理的工作只有上述流程的内容,这里只是将我对产品经理的理解进行一个抽象,形成一个可学习、可梳理的流程化说明,切不可生搬硬套,要有自己的理解。

    接下来,就分别对这三个模块展开说明。

    01 功能设计

    在上篇中,我们做的工作,都属于前期调研的范畴。前期调研结束,确定好了产品功能范围和用户画像后,就可以进入功能设计阶段了。

    功能设计包含,业务流程、功能导图、原型设计这三部分。在画原型图之前,我们需要先完成业务流程图和功能导图,这样在画原型的时候,可以减少原型中,元件布局紊乱、信息架构不当或功能点遗漏等情况的发生。

    业务流程图

    业务流程图是以业务需求为出发点,以图形的方式描述系统任务和业务流程。一个好的业务流程图,可以帮助团队成员快速理解业务和需求,提高团队协作效率,降低沟通成本。

    业务流程图,主要体现完成一个任务需要经过哪些流程,而不描述流程中的具体功能和操作。以滴滴打车乘客侧为例,简单的业务流程图就是:

    滴滴打车(偷懒了)

    滴滴打车中,每一个出行场景对应的业务流程都不一样,正确的业务流程图,是要将各业务场景的流程都体现出来。

    业务流程图,最好可以清晰地体现核心业务流程。比如即时体验类的App,高德地图的核心功能是导航,那么业务流程图中用户使用导航的流程要表达完整,其它的附属功能如生活服务、离线地图、路书等功能,不必体现。

    业务流程图,比较好的工具有visio、Prosess on,使用Axure自带的Flow元件库也可,但对于跨职能的业务流程没有上述两种直观。

    功能导图

    功能导图是以思维导图的形式,将各功能进行分组归类,形成信息架构。在前期构想的时候,我们可以发散地将所有功能都穷举出来,然后再对功能进行信息分层处理。以 微信-我 功能导图为例。

    微信-我功能导图

    原型设计

    对着流程图和功能导图,我们基本可以在脑子里构想出产品雏形了。使用原型工具,可以将我们的设想中的产品形态具象地表达出来。

    原型图中,我们需要先对一级功能进行合适的布局,即搭产品框架,如微信的底部导航栏——首页、通讯录、发现、我,就是微信的一级功能,在一级功能下还有二级、三级等子功能。

    微信低保真原型

    在上图中,我们可以发现,微信在“我的”一级信息层级下,对二级信息进行了功能分类和布局,将不常用的“设置”功能放在了最下面;为了让用户更常使用视频动态的功能,微信将摄像机icon放置在了右上角,比较显眼且用户手指好触达的地方。

    原型图中,不要求界面多么美观,但求布局、功能分层、业务逻辑流畅。

    02 需求评审、测试迭代

    原型设计完成,一般会先和产品总监再确定一下产品形态,确定完成后才进入产品需求文档(Product Requirement Document ,俗称PRD)撰写阶段。

    曾经的我,也在PRD形式上纠结了很久,到底哪一种PRD模板更好?是直接在原型里面写逻辑,还是在word里面写呢?

    不管哪一种形式,文档只是用来保证成员对产品需求理解的一致性,什么形式主要取决于成员的阅读习惯,但如何让文档更易于阅读,确实是需要产品经理们多花心思研究的。比如能用流程图的,不用表格,能用表格的不用文字,使用伪代码语言更利于开发阅读。

    PRD完成后,需要组织相关人员开需求评审会。如何组织需求评审会议呢?

    1、确定会议上要用到的材料已准备好,一般就是PRD、业务流程图、 功能导图;

    2、定好会议室和会议时间,提前1-2天通知相关人员参加,并提前将PRD发送给相关人员查看;

    3、产品经理需要保证对所提需求理解透彻,能够回答其他人的质疑;

    4、控制会议节奏,在会议上5分钟之内没有结果的议题,会后讨论;

    5、向开发人员获取开发工时(单位:人/天或人/时),以确定排期。

    所以,成功的需求评审会产出的结果是:成员已了解产品需求、明确工期。

    剩下的工作就是,跟踪开发进度和测试了,上线后持续迭代。

    03 写在最后

    产品经理的工作流程基本就是这些了,每个公司对产品经理的要求不同,涉及的工作内容也不同,所以产品经理的工作流程并没有标准的SOP这一说。

    不管工作流程是怎样的,产品经理在工具、文档形式上无须太过纠结,多提高行业认知和产品思维能力,拉开差距的永远是思维层面上的,而不是工具层面上的。

    THE END

    在跌跌撞撞中成长,在此记录工作思考和读书思考,便于巩固。

    如内容有不足之处,欢迎交流,一起学习、成长。

    相关文章

      网友评论

        本文标题:产品经理的工作流程——下篇

        本文链接:https://www.haomeiwen.com/subject/blbryltx.html