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

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

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

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

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

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

运营后台重构的基本原则

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

目的和预期收益明确

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

节奏的把控

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

良好的兼容性和可扩展性

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

可复用性强

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

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

基础设施

账号和权限体系

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

列表和搜索

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

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

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

与列表相关的还有：

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

用户基础信息

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

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

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

应用层的设计

入口层级的设计

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

分类原则：

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

业务流的合理规划

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

业务流程的规范

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

产品辞典

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

操作规范

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

产品check list

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

总结

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

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

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

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

题图来自PEXELS，基于CC0协议