近几年，中台的概念被炒的火热，行业大佬们都给出了很好的解释，在这里我就不当搬运工了，先谈谈我理解的中台吧。中台是什么呢？中台就是将一些高度相似的业务系统，公共需求，整合到一起，开发给前端使用，最大程度上减少研发重复开发，比如说电商中台搭建，阿里提供的大中台，其实也是将一些基础的业务服务整合一起，例如淘宝、天猫相似的公共模块：会员管理、营销活动、商品管理、订单管理、评价系统等，这些高度相似的需求统一管理，开放给前端使用，即可以同时支持多条业务线运作，又充分解耦，前端可以根据自己的业务形态，定制个性化需求。虽然行业不一样，但是方法论是通用的。

由于公司战略变化，现推出多款面向不同用户群体的社交app，为了兼容多条业务线，最大程度降低开发成本，中台化建设迫在眉睫。本人有幸参与了公司中台搭建项目。在搭建中台之前，对公司现有的业务再一次做了梳理，如下图。

社交后台主要分为三个业务后台：审核、运营、风控后台，还有两个基础数据后台。在2019年暑假期间，公司推出了一款海外版社交app，正式进军海外市场，为了快速抢占市场，抓紧上线，后台并没有做长远规划，直接克隆一个后台给到了海外版本。但是随着业务的发展，运营、审核同事都需要来回频繁切换两个后台来进行日常的工作，增加了运用成本，同时研发维护成本也大大增加，每个模块的一个小改动，都需要同步到两个后台，做大量的重复性工作。直到2019年年底，公司又决定推出两款社交app，如果还按照之前克隆的方法，后续的维护成本只会成倍增加，后台越来越臃肿，无法支持多条业务线并行，不得不开始着手中台建设。接下来，我将以社交中台项目出发，分享一下我搭建审核中台的思路和最终的产品方案。

审核中台思路

先跟大家分享一下，我自己琢磨出来的做后台产品的方法论，在日常工作中，我都是套用这套方法论分析需求，很实用！具体的思路如图所示，审核中台的搭建，我也是运用这个方法论来理清需求，完成产品方案，接下来，我以审核中台项目为例，详细介绍一下方法论的使用。

一.理清现状

首先，我们要理清现状，上面有提到，由于公司战略变化，由原来的单产品业务线，扩展到多产品业务线的形式，原有的后台，无法满足需求，需要搭建一个支持多业务线并存的中台。那么，现有的后台，存在哪些问题呢？
1.每个app都有一个后台，审核人员需要来回切换工作台，增加操作成本，人力安排难度加大。
2.审核后台根据前端模块划分，例如：前端有一个类似朋友圈的功能，我们后台就对应了一个朋友圈审核功能，前端又有一个类似话题的功能，我们后台又会对应一个话题的审核功能，就算前端这两个功能产生的审核内容都是相同的类型：文字+图片的形式，但是后台还是两个模块分开审核的，造成后台功能模块重复臃肿。
3.审核形式欠妥，针对组合内容进行审核，例如文字+图片，只要一种不合规，整个内容都不可见，这样会导致内容量下降，对于早期的产品来说，内容量是基础。
4.审核结果固化，无法快速监管强度。比如：几天前，锁骨尺度图片允许传播，几天后，监管突然加强，锁骨图片不允许传播，这样就导致几天前放出去的锁骨图片涉嫌违规，然而审核结果已经固化，无法自动处理，只能通过回查历史数据，按照现在的标准重新审核，造成大量的人力浪费。

这四个问题一直困扰着审核后台，一直想解决，却没有一个很好的时机，这次公司战略的变化，刚好促成了审核后台的重构，也可以一并将上述问题解决。为了彻底解决遗留问题，我们想到了如下的解决方案：

1.统一重复后台，实现一个后台支撑多条业务线 。

2.规范审核模块，按照内容形式区分审核模块，实现与前端功能解耦，只针对内容本身做审核。

3.内容审核时，只隐藏不合规的内容，尽可能保留用户分享的资源，提高平台内容体量。

4.审核流程标准化，采取对内容打标签的审核形式，自定义外显（审核通过）规则，实时同步市场监管尺度，实现快速响应，历史内容也统一处理，一劳永逸。

二.需求目标

了解了产品的现状以及存在的问题，我们要进一步思考审核中台的目标是什么。制定了目标，就像找到了灯塔一样，明确了前行的方向。审核中台项目的目标，其实分为如下两个方面：

1.后台统一化，同时支持多条产品业务线

2.审核模块标准化、规范化，能够快速响应市场监管尺度

三.使用场景/对象

在明确了需求目标过后，带着目标与需求方了解需求，其实在与需求方沟通过程中，需求方对中台化的理解很弱，这个时候产品经理应该带着强指引的态度与需求方沟通，帮助需求方理清现状，做出决策，推着需求方一步一步落实。
回过头来看看这次项目的目标用户是哪些呢？审核中台面向的对象：审核人员+质检人员。审核人员就是对用户提交内容的进行评估，及时判断内容是否合规，质检人员侧重评估审核人员质量，及时发现不合理的审核决策。

四/五/六.上下游业务/涉及功能模块/数据交互

理解透彻需求方的使用场景和业务流程之后，可以开始着手产品方案设计。首先分析一下系统的整体框架，本项目所涉及的上下游模块、数据走向，如图所示，app端收集用户内容，传输到第三方机器审核，进行第一轮评估内容质量，根据不同的机审返回结果，扭转数据到审核中台进行人工审核，为了评估人工审核的准确性和及时性，后续会抽样人工审核结果至质检中台，进行再次评判。

梳理完整理框架过后，将目光集中在需求本身，即审核中台。之前在分析现状的时候，已经罗列出了审核中台的种种弊端，同时也提出了有针对性的解决方案，现将零散的解决方案整合成完善的产品方案，如下图所示，审核中台将分解成：审核模块、规则配置中心和数据统计三个模块。

七.业务流程图

梳理完如上信息，相信此刻产品经理已经对需求有了全面了解，可以正式开始产品原型设计阶段。此阶段最重要的一点就是先整理出相关模块的业务流程图，你会发现，在整理流程图的过程中，不仅加深对需求的了解，还参透了不少需求细节，异常情况的考量。当然业务流程图最好要包含数据扭转、操作权限、状态变化等。

八.原型设计

经历了以上的思考，此刻的你脑海中的原型已经呼之欲出了，现在就打开axure，将脑海里的原型还原就好了。

总结

以上八个步骤就是我做后台产品的方法论，不管是宏观分析大项目，还是微观分析小的优化项目，都很有效果。在这分享给各位，希望能对您有所帮助。

ps：下篇文章将继续讲解我的产品方法论在【审核中台之审核模块】原型设计的运用，敬请期待！