当你接触一个产品,并且决定对这个产品重构的时候,首先就是要了解这个产品的所有功能以及功能之间的关联关系。尤其是 to B 的后端产品,每个产品都有大量不同的角色和权限,经常导致新用户无法快速的了解和使用。
作为产品经理,当你接手一个产品时,首先就是要掌握整个产品的所有功能的关联关系。尽管PRD文档或者产品白皮书能够让你快速了解这个产品有哪些功能,但是功能之间的逻辑关系仍然可能不够清晰(完全取决于上一个写文档的人是否认真)。
我的方法是,不论是否有相关的PRD文档,在决定产品重构时,第一步就是自己把这个产品的全部的角色、菜单、权限甚至于每个页面上的每个功能都是做什么的,整理成一个脑图,并且标注上自己认为不合理或者需要改进的功能点。如果这个产品有复杂的流程,最好还要写清楚产品应用的流程是怎样的,确定流程是否合理。
以最近重构的一个应用:在线选课为例,简单讲讲产品经理在重构过程中都做了什么。
在线选课,旨在给K12的学校用户提供校本选修的选课功能的一个应用,可以支持教师申报课程,教务管理员审批,学生在特定时间选课的功能。
(1)梳理流程和主要角色对应的权限和菜单
在线选课涉及到三个角色:管理员、授课教师及学生。先需要整理出原有产品设计的流程和拥有的菜单。可以看到,大部分复杂的流程和功能都集中在管理员端。
(2)对整个产品的流程进行优化,并且需要达到最后你想达到的目的
to B 后端产品的特点就是功能多、角色多、菜单多、逻辑复杂。在重构时,假设产品是有固定流程的,那么将你认为合理的、符合逻辑的流程标识出来。然后在充分调研的情况下,对一些没有任何用处的、不通用的功能砍掉。最后整理成一个菜单、角色、权限的功能列表。整个过程其实和做一个全新的产品类似,梳理流程,梳理功能,梳理角色。甚至于因为有一些原有的逻辑和设计缺陷,你不得不重新思考设计产品的新方法。继续以在线选课为例,原有系统流程不清晰,重构的目的是要让用户在没有培训的状态下就能快速使用和了解对应的功能。因此在重构新版时,需要标识出新流程及新流程上的一些需要解决的问题。如图所示(脑图内容未全部展示)。这其实和写一个完整的PRD没区别,但是用脑图的方式反而让整个流程更加简单明了,而且效率更高。
(3)原型设计阶段
在原型设计阶段,你需要和UED(如果有)部门进行深入的探讨如何让流程更加清晰。这个流程清晰不仅仅体现在界面的展示上,包括一些提示信息及使用帮助都能让你完善整个流程,减少用户使用的培训成本。在原型设计上,就不多做赘述,如果能整理出来清晰的流程却画不出来清晰好用的原型,那可能你需要一个专业的交互设计师来拯救你的产品重构了。最后画好的原型建议让用户体验一下,或者是让其他的产品经理体验一下,提出一些意见,说不定有些就会成为产品的亮点。
(4)协调资源,给老板画个大饼
在产品重构中,需要用改进的目标和试图达到的效果让老板知道你在做的这个事儿很重要,能够提升销售量和减轻工作量。同时你还要跟研发、测试讲清楚,重构的目的是为了让别人少来骚扰他们,保证大家对重构这个事儿没有怨言。毕竟重构,还是一个很费事费力的事情,基本上一个后端产品想要完全重构到没有bug,少说半年,多则一年。