实战经验:运营后台产品的重构

产品经理就业特训营,专门为大学生和准备转型做产品的人量身定制,60天线下培训,包就业!了解详情

运营后台如何进行重构呢?作者结合自身经验,分享了自己的几点看法。

首先先放一张文章结构图:

运营后台是公司内部人员使用的操作平台,服务于产品的支撑和运营活动的展开。对于运营的同学来讲简直就是命根子,但是我们会发现绝大部分的运营后台用起来体验超级烂(默哀十分钟),而且bug成筐,随处可见反人类的交互设计。那么运营后台为什么会如此难用。

对于绝大分的创业公司和团队来讲,为了解决生存问题,首要解决的一定是面向用户的产品的快速迭代,先把功能迭代上去再考虑其他。这个时候会有一些零散的解决运营需求的小后台,有的甚至连最简陋的后台也没有,直接操作数据库(开发GG内心OS),如果有些东西修改比较频繁,开发就会编写一段脚本,直接用脚本录入。所以这个时候的运营后台的演化路径是这样的:“开发大爷直接改动数据库——运营用脚本录入——一些零散的小后台功能——一个整体的可用后台。”

但是随着产品的快速迭代和公司规模的扩大,运营后台的主要矛盾已经从有没有上升到好不好、人效高不高的层面。这时候运营后台就不得不进行大规模改造了,我称之为后台重构

那么运营后台如何进行重构呢?有没有可以一些可以借鉴的方法和规律呢?接下来我会从运营后台重构的基本原则、产品层面规划、

运营后台重构的基本原则

  • 目的和预期收益明确
  • 把控好节奏
  • 良好的兼容性和可扩展性
  • 良好的可复用性

目的和预期收益明确

首先就是要明确重构的目标和预期收益,这个对于不同的公司和团队见仁见智。总体来说就是一定要明确我这个后台是“为WHO在什么情况下解决WHAT问题”,实际上给给自己的后台建立边界,确定烛台需求和目标,才能够有的放矢的区进行设计。例如我对自己的运营后台的定义就是“为整个运营团队提供效率支撑和业务管理工具”

节奏的把控

资源永远是稀缺的,所以重要的东西一定要先行。当你面临一大堆的东西要做的时候,可能需求池都无法装得下,,这时候就要平衡成本和收益,重构产品尤其如此。对于运营后台的重构,最重要的还是先满足现阶段的需要,在完成现有需求的同时逐步的加入重构要素,在不知不觉中完成整个后台的重构。很多事情到了不得不做的时候才是最重要的。除非你手里的资源多的足够支撑你大刀阔斧的改造,否则还是选择温水煮青蛙的方式慢慢改造吧。

良好的兼容性和可扩展性

良好的兼容和扩展性是最见功底的地方,一般到你手里的一坨后台功能,而且这些功能往往是不同的开发大爷做出来的,除了应用层的混乱之外,底层的兼容性和可扩展性也会是一个大问题。往往你要改动一个功能,开发会说做不了,很大原因就是底层的混乱。所以在重构时要三思“和别的功能有没有关联和冲突、改动能不能兼容、新来的能不能扩展”,这样的后台系统才是一个底子硬的好后台。

可复用性强

同时后台还要有很强的可复用性。做运营后台就像搭积木,而一些组件化的产品模块就是我们手中的积木,如果我们在自己的产品中能够提前抽象出一些组件化的产品,能够避免重复造轮子,大大降低产品研发和后期维护的成本,达到事半功倍的效果。

原则有了,下面的就是具体的操作方法了。重构后台会面临一筐一筐的问题,不能被现有的问题牵着鼻子走,要仰望星空脚踏实地:上天就是做好业务层的规划,入地就是要做好基础设施的建设。

基础设施

账号和权限体系

运营后台产品,最重要的就是账号权限系统了。权限系统一方面控制着什么人可以操作什么事情,保证敏感的事情只有核心人员才可以做;另一方面也是业务流和业务模块的第一道分流设施。这个模块会根据业务场景的不同而进行不同的设计,对于内部的运营后台产品,个人推荐用“账户-角色-权限”三级的权限模型,这套模型能够满足绝大多数的后台产品需要,而且维护起来成本也低。权限控制一般会采用两种模式,一种是后端API限制,另一种是前端交互层限制,这个就根据业务场景灵活使用。

列表和搜索

一般进入业务层的操作会有一个列表,例如,列表的作用是“重要信息的展示-操作结果的反馈-历史操作的查询”,典型的列表是这样的:

首先我们要弄清楚列表的整体结构:

  • 整体操作区:搜索、筛选、新增
  • 信息展示区:即各个展示字段
  • 个体操作区:查看、编辑、删除、状态置换等

与列表相关的还有:

  • 列表字段:要明确列表字段的“字符长度、是否允许特殊字符、是否换行、是否空缺”等
  • 分页:如果数据较多的情况下,需要进行分页展示,使得能够快速操作数据。要考虑分页数量,页面跳转等
  • 排序:数据的排序,有主排序规则和次排序规则,通常采用时间轴倒序排列
  • 数据加载:当数据较多的时候,需要进行分段加载,这时候要考虑分段加载和数据本身的

用户基础信息

用户的基础信息实际上就是用户的画像,能够清晰的描述出你的用户到底是什么样。一般来说用户的基础信息两部分,即用户的自身属性和用户的行为属性。

用户的自身属性包括:姓名、性别、学历、收入、所在城市、毕业学校等等用户自身的属性信息,这类信息往往哪个是数据库中能够直接拿到的。

用户行为属性信息包括:手机型号、系统版本、APP版本、所在地理位置、浏览轨迹、行为标签等,这类信息往往需要用户激活后才能进行判断。

应用层的设计

入口层级的设计

主要逻辑是根据运营管理的主体进行分类,并根据相似和差异进行归类。

分类原则:

  • 现有的任何一个模块和功能点都能有自己的分类
  • 一级菜单的分类为管理对象,每个一级菜单下不超过9个二级菜单,每个二级菜单下不超过9个三级菜单
  • 功能越来越多,根据业务发展节奏对已有功能进行整理归类
  • 对新增加的功能进行判断,找到对应的层级入口,如果不能,则在对应的入口下新建

业务流的合理规划

业务流是后台管理中非常重要的方面,最简单直接的例子就是“审批”流,需要多个不同的角色来执行不同方面。具体还是业务导向型的,这里不赘述。这块推荐一个好用的工具“泳道图”来进行设计,确定不同节点不同角色的操作流程。流程图最好能够从两个角度来画,第一种是产品经理常用的动作流程图(适用于前端交互和操作),另一种是状态流转图(适用于后端的状态基流转),基本上这两个图梳理清楚,整个业务流就会梳理的比较清晰了。

业务流程的规范

这里推荐有三个我个人总结出来的好工具,仅供参考

产品辞典

产品辞典是产品的基础信息,是进行信息同步和管理的有效手段。通常包括:重要名词的定义、历史迭代记录、产品操作手册等信息。

操作规范

凡是系统总是人用的,无论系统设计的多么完美,都可能出现人为的操作失误。这时候操作规范就显得尤为重要,用来规范操作人员的使用流程,做到产品的线上线下自洽,同时减小PM和运营之间的摩擦。

产品check list

check list适用于产品设计整个过程中,能够帮我们逐条检查问题,核对核心case,最大程度上降低风险 的工具,能够让我们的产品管理更加精细化,必经已经不是产品的草莽年代了。

总结

运营后台的重构是一件长期而复杂的事情,会受到各种条件的限制而有不同的解决思路。但是总体上来说仍然是明确目标、搭好基础设施、建立兼容性和可扩展性、做好顶层应用设计,同时平衡成本和收益,确定自己的节奏,按照节奏一步一步走。

是的,总有一些坑,你永远踩不完。

本篇先整体介绍一下运营后台重构的原则和方法,后面会把每一个模块详细的阐述。

 

本文由 @迅哥喝茶 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自PEXELS,基于CC0协议

打赏也是一种认可
5人打赏
评论
有话不说憋着难受!
  1. 赞赞赞、希望后续的模块快快更新!如果可以的话、希望可以附带一些圆形的截图也好!感谢感谢、辛苦辛苦!棒棒哒

    回复
    1. 原型截图得处理一下,工作中的原型不会外放的

      回复
  2. 先点个赞

    回复