运营后台怎样进行重构呢?运营后台重构的基本原则

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

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

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

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

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

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

运营后台重构的基本原则

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

目的和预期收益明确

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

节奏的把控

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

良好皧