本文从『有这个想法』开始,到『测试上线』,解析了一个B端产品完整的工作流程。

之前接手了一个素材管理系统的产品需求,leader主要的意思就是:让这个后台,可以将公司各个部门的素材汇总起来(素材包括图片、视频等),集中管理,方便公司内部资源共享。

当然,作为产品经理,拿到一个需求是需要先进行需求分析的,不是一上来就可劲儿造。下面我将我的工作流程详细的梳理出来,分享给你,希望可以给你带来一些有用的东西,如果文中有你认为不妥的地方,也请海涵。

01 背景

我的公司是一家偏内容型的公司,所以平时各个部门会囤积大量的素材,这些素材主要包括图片、视频等,但是这些素材都分散在各个部门,没有进行有效的管理,所以导致素材的利用率非常低,而且会让个别部门重复工作。

比如:3月份,推广部需要广告部做一个A品牌的宣传视频;5月份,投放部需要广告部做一个A品牌的宣传视频,由于没有对素材进行统一管理,广告部可能会做两个宣传视频,但是推广部和投放部的视频,是可以共用的,不需要广告部再做一个视频,这样就浪费了广告部的时间,增加了公司的运营成本。

所以现在公司内部就需要一个素材管理系统,来对各部门的素材进行统一管理。

02 总结业务问题

公司里边很多可以共用的素材,但是没有进行有效管理,这导致其他部门想要使用某些素材时非常麻烦,需要经过多方人员,流程非常复杂,最终还不一定能找到自己想要的素材。

我之前就遇到过这样的情况:我需要A品牌的宣传图,然后我找到我的主管,问她有没有相关素材,然后我的主管找到了设计部的主管,问有没有A品牌的宣传图,设计部的主管又去问了他手下的设计师,有没有A品牌的宣传图,后来发现有设计师做过A品牌的宣传图,但是该设计师离职了,宣传图在他电脑的某个文件夹里边,就这样,从上午9点半一直到晚上7点多,我才拿到了A品牌的宣传图。这一个过程是非常漫长的,如果有一个素材管理系统,我直接登录进去,搜索A品牌,然后下载对应图片即可,全程不到5分钟,又怎么会浪费这么多时间呢?

总结一下,存在的业务问题就是:现有大量素材储存在各部门的电脑、服务器上,没有统一的管理平台,不利于公司素材的沉淀、共享;同时还会让一些部门重复工作,提升公司运营成本。

解决方案:最终决定,做一个素材管理系统,让全公司的团队都可以使用,需要素材时,登录该系统下载即可;生产素材的部门,定期上传素材。

核心价值:素材管理系统的核心价值:公司内部各种素材的沉淀与共享。

03 核心业务流程

 

  素材系统的核心流程如上图。

对用户来说使用素材系统的流程大致是:找到素材,下载素材;

维护者的使用流程大致是:上传素材、修改素材、删除素材。

04 产品定位

 

  05 功能板块设计

功能板块设计要谨慎,需要根据业务的需求,全面考虑产品后期的各种使用场景,这样功能才能适用于当前产品,这个系统才会被更多的人使用。

对于素材管理系统来说,最重要的功能就是搜索、下载、批量上传。我把删除定为最高权限(只有超级管理员拥有删除权限),因为删除对于素材管理系统来说是最敏感的操作,需要格外注意,这也可以在一定程度上防止“删库跑路”的情况。

06 演进蓝图

演进蓝图可以理解为:先开发哪一块,然后开发哪一块,最后开发哪一块。

系统不是一下子就能开发完成的,需要产品经理将整个开发流程合理的分为 n 期,我自己将此系统分为了4期。

演进蓝图具体有多少期,需要根据业务的特点和开发资源来决定,确定好演进蓝图后,需要和你的leader、对应的开发工程师聊一下,如果有不合适的地方,可以适度调整,这样可以保证项目开发过程的合理性。

07 业务建模

业务建模的作用主要是提炼业务,归纳并设计对应的实体关系(ER,Entity-Relationship),是一些复杂系统不可缺少的一个流程,但是本文的素材管理系统运作原理相对简单,暂时涉及不到。

08 角色与流程

我们需要先定义使用素材管理系统的角色,然后再梳理各个角色使用此后台的流程。

因为素材系统没有涉及多个后台,且角色相对单一,所以我直接将数据库提了出来,让数据库成为了角色与流程图的一部分,这样主要是为了强调数据库的重要性,让用户浏览的都是最新的素材。

制作角色业务流程图时,需要定义角色和细化流程,每个步骤、流程要清晰,不要模棱两可。我在这里给你一个参考。

 

  09 权限管理

权限管理包含两个版块:功能权限、数据权限。

功能权限:用户可以访问那些页面,可以点击哪些按钮等;比如此系统中,设计师角色看不到图片的删除按钮。

数据权限:用户能看到的某页面数据的集合;比如此系统中,设计师角色、运营角色就看不到图片、视频等素材的总数(对于订单管理系统来说,可能就是北京地区的员工看不到天津地区的订单)。

10 界面

当前面的工作都做好以后,就要开始设计原型图了。

素材管理系统采用React框架搭建,在开发时会用到大量的组件,所以在设计原型图时,我遵循的是Ant Design的设计规范,大部分交互效果也是直接参考的Ant Design。这样不仅可以提升我制作原型图的效率,还能节约开发的成本,需要的效果,我会直接将链接附上,这样开发人员一看,就知道我的意思(这也是产品经理在工作时的一个小技巧,有的效果在口头上不好描述,直接给开发看最终的效果就可以了)。

原型图是产品经理的基本功,这里我就不多赘述了。

11 数据埋点

素材管理系统,我用的GA分析工具,用的是全局埋点,没有细化到具体的某个元件上,打算先看看大致的数据,然后再针对具体的元件进行埋点,后期可能会根据这些数据,对本系统进行优化、迭代。

12 PRD文档编写

我个人习惯直接将PRD写在原型图的右侧,这样技术人员在开发的时候比较方便,可以一边看原型图,一边看需求文档。

文档的呈现方式可以和技术人员协商一下,找一个双方都比较喜欢的方式就可以了(原型、Word文档、Excel表格、流程图这种都可以),如果公司有规定,那就尽量按照公司的来。

13 协调排期

下面就可以按照演进蓝图,去找开发排期了。排好期,接着就是跟进、测试、上线。

14 需求管理、迭代

素材系统上线后,我从各部门收集了一些需求,并将一部分需求整理出来,计划年后对素材系统进行一次迭代。

B端产品的需求优先级应当遵循:业务需求 > 用户需求 > 产品需求 的原则,先解决公司业务上的需求,然后解决用户的需求,最后才是产品本身的需求。

我个人习惯用Excel表格进行需求池管理,这样各个字段比较的明确,建议:需求池表格一定要自己做,不要原封不动的借用网上的模板,因为每个公司、每个项目的环境是不一样的,产品经理需要根据自己所处的环境,去制作与之对应的表格。

 

  15 总结

B端产品的工作流程大致如下:

梳理业务现状

总结业务问题

梳理核心业务流程

产品定位

功能板块设计

演进蓝图

业务建模

梳理角色与流程

权限管理

原型设计

数据埋点

PRD文档编写

协调排期

需求管理与迭代

最终需要多少个步骤,需要根据产品本身的特色,灵活的去增加、删除某些步骤,同时还需要根据自己的工作环境,随机应变。