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

　　运营后台如何进行重构呢？作者结合自身经验，分享了自己的几点看法。
　　首先先放一张文章结构图：
　　运营后台是公司内部人员使用的操作平台，服务于产品的支撑和运营活动的展开。对于运营的同学来讲简直就是命根子，但是我们会发现绝大部分的运营后台用起来体验超级烂（默哀十分钟），而且bug成筐，随处可见反人类的交互设计。那么运营后台为什么会如此难用。
　　对于绝大分的创业公司和团队来讲，为了解决生存问题，首要解决的一定是面向用户的产品的快速迭代，先把功能迭代上去再考虑其他。这个时候会有一些零散的解决运营需求的小后台，有的甚至连最简陋的后台也没有，直接操作数据库（开发GG内心OS），如果有些东西修改比较频繁，开发就会编写一段脚本，直接用脚本录入。所以这个时候的运营后台的演化路径是这样的：“开发大爷直接改动数据库运营用脚本录入一些零散的小后台功能一个整体的可用后台。”
　　但是随着产品的快速迭代和公司规模的扩大，运营后台的主要矛盾已经从有没有上升到好不好、人效高不高的层面。这时候运营后台就不得不进行大规模改造了，我称之为后台重构
　　那么运营后台如何进行重构呢？有没有可以一些可以借鉴的方法和规律呢？接下来我会从运营后台重构的基本原则、产品层面规划来说一下。
　　运营后台重构的基本原则
　　目的和预期收益明确
　　把控好节奏
　　良好的兼容性和可扩展性
　　良好的可复用性
　　目的和预期收益明确
　　首先就是要明确重构的目标和预期收益，这个对于不同的公司和团队见仁见智。总体来说就是一定要明确我这个后台是“为WHO在什么情况下解决WHAT问题”，实际上给给自己的后台建立边界，确定烛台需求和目标，才能够有的放矢的区进行设计。例如我对自己的运营后台的定义就是“为整个运营团队提供效率支撑和业务管理工具”。
　　节奏的把控
　　资源永远是稀缺的，所以重要的东西一定要先行。当你面临一大堆的东西要做的时候，可能需求池都无法装得下，这时候就要平衡成本和收益，重构产品尤其如此。对于运营后台的重构，最重要的还是先满足现阶段的需要，在完成现有需求的同时逐步的加入重构要素，在不知不觉中完成整个后台的重构。很多事情到了不得不做的时候才是最重要的。除非你手里的资源多的足够支撑你大刀阔斧的改造，否则还是选择温水煮青蛙的方式慢慢改造吧。
　　良好的兼容性和可扩展性
　　良好的兼容和扩展性是最见功底的地方，一般到你手里的一坨后台功能，而且这些功能往往是不同的开发大爷做出来的，除了应用层的混乱之外，底层的兼容性和可扩展性也会是一个大问题。往往你要改动一个功能，开发会说做不了，很大原因就是底层的混乱。所以在重构时要三思“和别的功能有没有关联和冲突、改动能不能兼容、新来的能不能扩展”，这样的后台系统才是一个底子硬的好后台。
　　可复用性强
　　同时后台还要有很强的可复用性。做运营后台就像搭积木，而一些组件化的产品模块就是我们手中的积木，如果我们在自己的产品中能够提前抽象出一些组件化的产品，能够避免重复造轮子，大大降低产品研发和后期维护的成本，达到事半功倍的效果。
　　原则有了，下面的就是具体的操作方法了。重构后台会面临一筐一筐的问题，不能被现有的问题牵着鼻子走，要仰望星空脚踏实地：上天就是做好业务层的规划，入地就是要做好基础设施的建设。
　　基础设施
　　账号和权限体系
　　运营后台产品，最重要的就是账号权限系统了。权限系统一方面控制着什么人可以操作什么事情，保证敏感的事情只有核心人员才可以做；另一方面也是业务流和业务模块的第一道分流设施。这个模块会根据业务场景的不同而进行不同的设计，对于内部的运营后台产品，个人推荐用“账户角色权限”三级的权限模型，这套模型能够满足绝大多数的后台产品需要，而且维护起来成本也低。权限控制一般会采用两种模式，一种是后端API限制，另一种是前端交互层限制，这个就根据业务场景灵活使用。
　　列表和搜索
　　一般进入业务层的操作会有一个列表，例如，列表的作用是“重要信息的展示操作结果的反馈历史操作的查询”，典型的列表是这样的：
　　首先我们要弄清楚列表的整体结构：
　　整体操作区：搜索、筛选、新增
　　信息展示区：即各个展示字段
　　个体操作区：查看、编辑、删除、状态置换等
　　与列表相关的还有：
　　列表字段：要明确列表字段的“字符长度、是否允许特殊字符、是否换行、是否空缺”等
　　分页：如果数据较多的情况下，需要进行分页展示，使得能够快速操作数据。要考虑分页数量，页面跳转等
　　排序：数据的排序，有主排序规则和次排序规则，通常采用时间轴倒序排列
　　数据加载：当数据较多的时候，需要进行分段加载，这时候要考虑分段加载和数据本身的
　　用户基础信息
　　用户的基础信息实际上就是用户的画像，能够清晰的描述出你的用户到底是什么样。一般来说用户的基础信息两部分，即用户的自身属性和用户的行为属性。
　　用户的自身属性包括：姓名、性别、学历、收入、所在城市、毕业学校等等用户自身的属性信息，这类信息往往哪个是数据库中能够直接拿到的。
　　用户行为属性信息包括：手机型号、系统版本、APP版本、所在地理位置、浏览轨迹、行为标签等，这类信息往往需要用户激活后才能进行判断。
　　应用层的设计
　　入口层级的设计
　　主要逻辑是根据运营管理的主体进行分类，并根据相似和差异进行归类。
　　分类原则：
　　现有的任何一个模块和功能点都能有自己的分类
　　一级菜单的分类为管理对象，每个一级菜单下不超过9个二级菜单，每个二级菜单下不超过9个三级菜单
　　功能越来越多，根据业务发展节奏对已有功能进行整理归类
　　对新增加的功能进行判断，找到对应的层级入口，如果不能，则在对应的入口下新建
　　业务流的合理规划
　　业务流是后台管理中非常重要的方面，最简单直接的例子就是“审批”流，需要多个不同的角色来执行不同方面。具体还是业务导向型的，这里不赘述。这块推荐一个好用的工具“泳道图”来进行设计，确定不同节点不同角色的操作流程。流程图最好能够从两个角度来画，第一种是产品经理常用的动作流程图（适用于前端交互和操作），另一种是状态流转图（适用于后端的状态基流转），基本上这两个图梳理清楚，整个业务流就会梳理的比较清晰了。
　　业务流程的规范
　　这里推荐有三个我个人总结出来的好工具，仅供参考
　　产品辞典
　　产品辞典是产品的基础信息，是进行信息同步和管理的有效手段。通常包括：重要名词的定义、历史迭代记录、产品操作手册等信息。
　　操作规范
　　凡是系统总是人用的，无论系统设计的多么完美，都可能出现人为的操作失误。这时候操作规范就显得尤为重要，用来规范操作人员的使用流程，做到产品的线上线下自洽，同时减小PM和运营之间的摩擦。
　　产品checklist
　　checklist适用于产品设计整个过程中，能够帮我们逐条检查问题，核对核心case，最大程度上降低风险的工具，能够让我们的产品管理更加精细化，必经已经不是产品的草莽年代了。
　　总结
　　运营后台的重构是一件长期而复杂的事情，会受到各种条件的限制而有不同的解决思路。但是总体上来说仍然是明确目标、搭好基础设施、建立兼容性和可扩展性、做好顶层应用设计，同时平衡成本和收益，确定自己的节奏，按照节奏一步一步走。
　　是的，总有一些坑，你永远踩不完。
　　本篇先整体介绍一下运营后台重构的原则和方法，后面会把每一个模块详细的阐述。