编辑导语：过往的营销其实都是在经营产品，将其宣传出来，让更多用户来消费产品。当将产品销售出去后，产品的经营与用户的经营成为了二者利益平衡的杠杆，如何寻找二者平衡最优解，本文通过中台概念对产品经营进行分析，以此寻找二者平衡解决点。

前言——产品的价值

在谈论游戏中台之前，我想先和大家聊聊产品的思考，由此去引申中台的思考。

无论自然界、人类社会，抑或浩瀚宇宙，一切事物从整体上都在向着无序化迈进，这就是熵增的过程。

随着信息化的快速发展以及疫情冲击下的“后遗症”，我们越来越能明显感觉到，当下社会似乎很难按照既定的规则运转下去，熵增现象越来越明显，而当下的业务重心也慢慢的从经营产品偏移到经营用户。

过往很多行业甚至当下一部分传统行业的营销都是在经营产品，简单来说就是怎样将产品宣传出去，卖给若干个消费者。而经营用户将这款产品卖给这个客户后，可以让他重复购买若干次，与此同时还可以带动若干个客户，让这若干客户重复购买……以此类推。

期望值的公式=概率x结果/收益

所以，期望值的大小是由概率的大小和收益的大小二者共同决定的，所谓寻找最大期望值也就是在概率和收益之间找到最佳的组合和平衡，并以最大期望值来指导我们的行动。显而易见经营产品的期望是远小于经营用户的期望值。

那么在现有经营产品的前提下，如果更好的去经营用户呢？之前有提到说，产品是依照于一套既定的规则下的产物，那在这套熟悉的工作流之下，是否能够通过经验的积淀，开发流程与接入流程的规范下去提升工作效率，以便更好地去经营用户呢？

本篇内容主要内容在于通过中台的概念去提升经营产品的角度，而非大篇幅的经营用户，或许会在未来的文章中去展开讲讲，敬请期待。再回到游戏中台来说，或许它的存在就是我们寻找最佳平衡的解决方案。

一、游戏中台的思考

互联网中台的起源的故事与发展的历程想必大家早已经熟知，我也不再去引用于赘述。然而游戏行业的中台却很少提及，我想借着这个机会和大家一起探讨探讨，当然毕竟只是我的一家之言，肯定会有片面的地方还请谅解。

回到中台的核心内容：简而言之就是系统组件化，避免重复造轮子，提升开发的工作效率，降低或减少人工与时间的成本。这么看或许说辞有些模糊，其实中台的设计往往无法脱离业务，所以在概要定义下中台的边界是无法明确的。

俗话说风险与机遇并存，在中台概念火热的背后也存在着盲目跟风，许多本该不属于中台领域的东西被莫名的堆积到中台范畴，从而导致中台失去了原有的核心价值。并不是所有的公司或者部门都需要“中台化”，中台化其实是由为“中心化”、“平台化”演变而来的。

随着企业规模的膨胀、业务复杂度的提升等过程中不断暴露出来问题，以及对于各部门或者各项目组之间协作的要求就会越来越高，对于已经具有一定的中心化趋势且存在多条业务线并行的情况下，工具、内容、协作等模块不断抽象出中心内容，但各模块又相互独立存在于各个平台，亟待一个中央模块去连接和组合，那么此时建设中台就很有必要性。

二、游戏中台的组成

一个中台部门的搭建不是想当然，除了需要自己强劲的“内功”底蕴之外，还要有八面玲珑的“外功”去搭建。因为中台的所有需求发起点都来源于项目组，以满足项目组需求去搭建组件与功能而非去虚空想象需求。

再加上中台项目往往不像项目那样会直接创造利益价值，所以在前期立项就会面临从里到外的重重阻力。当然这部分内容与各企业的战略规划相关，在项目管理中划分在启动过程组的阶段需要着重去分析考虑的事情，而本次内容更多针对于规划、执行过程阶段。

游戏中台体系是由技术中台+业务中台+数据中台等构成。其中业务中台又可以拆分为运营中台、内容中台和营销中台，当然每个企业对于中台的范畴或命名不尽相同，但万变不离其宗。

其中技术中台可以拆分为：引擎平台、工程平台、技术美术平台、AI平台等。

运营中台可以引申为：内容平台、营销平台、用户平台、工具资源平台（GM向）。

拿运营中台来说，采用多租户模式，通过运营中台为不同的游戏项目作为单独的实例提供组织服务。实现多个租户之间共享中台组件，以达到提高复用效率减少开发时间与人力的目的。

三、如何建设游戏中台

1. 权限管理模型选用

常见的有ACL 访问控制列表、DAC 自主访问控制（ACL拓展）、MAC 强制访问控制、RBAC 基于角色的访问控制，每种的优点、局限性等常规内容可自寻搜索此处不再多赘述。我个人是采用RBAC的模型进行运营中台的设计的：

定义：

• 规定角色可以对哪些资源进行哪些操作
• 规定主体拥有哪些角色 当一个操作

同时满足a与b时，允许操作。

• 场景：运营后台管理系统
• 适用资源：不同游戏项目组

说明：RBAC的思想，来源于现实世界的企业结构。比如销售角色，拥有查看客户信息的权限。当一个销售人员小王入职了，可以把销售角色赋予小王，那么小王就拥有了查看客户的权限。这种方式，避免了ACL模型下，每次新人入职，需要逐个配置资源表的情况。同样，权限变动也变得很方便，只要修改角色，即可实现多用户的权限修改。

局限性：RABC并不总能满足所有权限的场景。比如，我们无法对游戏运营角色，进行个体定制。比如，游戏运营角色拥有创建、删除的权限。如果我们要对运营人员小李，去掉删除的权限。那么，我们就必须创建另一个角色，来满足需求。如果这种情况很频繁，就会丧失角色的统一性，降低系统的可维护性。

2. 运营中台

对于游戏运营中台来说一定是多租户模式，不同的游戏项目组共用相同的系统或程序组件，并且仍可确保各用户间数据的隔离性。

针对不同游戏的业务方提出的游戏运营管理需求，通过建立将功能层面高内聚、低耦合的通用游戏运营管理系统，以提供业务多重用性、系统易维护性、功能高扩展性的解决方案。

同时为满足各个游戏项目组的应用管理需求，设计开发通用的游戏运营系统。基于通用的服务端接口级的功能响应，打通与其他服务之间的数据交互，提供支持多租户、自助接入、并具有自由拓展性的系统及服务。

3. 营销中台

随着玩家数量的增长，用户、游戏内容等数据源急剧膨胀、维护玩家的生命周期变的困难、运营方案迭代缓慢等问题的显现，营销管理平台应运而生。基于对数据驱动业务增长以及精细化运营的迫切需求，需要延长玩家在游戏内、游戏外的生命周期：

• 帮助运营快速获取数据，实现灵活高效的洞察，促进业务快速迭代
• 帮助运营分析行为和业务数据，快速提高业务转化与玩家留存
• 帮助运营管理用户生命周期，精细化运营及智能增长
• 打通分析-决策-行动完整闭环

营销平台定位为建立行为分析产品体系，整合多种运营策略和工具，打通增长、精细化运营闭环，目标降低产品分析、运营的时间人力成本，提升整体效率，丰富扩展产品增长和内容运营能力。

4. 专题活动中台

专题活动中台算是非必选的一项架构，是否构建取决于业务对于此类需求的依赖程度，在游戏行业中较为多见。

要首先判断在以往的消费类/活跃类的游戏活动中是否可以抽象出通用的组件，或者是高频重复出现的活动场景。例如宫格抽奖、转盘等基础规则元素，周期性的特殊节日等素材积累就具有很强的通用性和高复用性。

可以理解为简单的换皮活动，这些都可以由业务属性来做灵活的配置组合。而对于日常的广告图、盒子图、背景图或banner等可以积累为素材，虽然这些内容或许带有自身很强的定制属性，但作为素材的积淀还是可以考虑保留的。比如同一个圣诞主题的活动背景，如果时间紧的话，换一些关键元素是不是也可以在另一些项目中使用呢。

（1）提高活动复用率和复用效率

• 让每一个上线过的活动都变成可复用的模版
• 通过配置即可上线，无需额外开发

（2）减少（避免）重复性逻辑、接口开发

（3）规范用户信息校验、发奖等通用逻辑，减少测试开发量

（4）做好与外部系统对接的准备

（5）专注页面效果与用户体验提升

四、对于中台产品的挑战

1. 沟通协作挑战

其实我刚开始也是在业务部门，我所面对的业务需求都是较为明确直接和相对轻松的。虽然也是面对多方项目组，但没有中台概念以及不用考虑复用的思维，业务需求也是做的顺风顺水。直到经历业务量不断地膨胀之后，愈来愈多的问题暴露出来。

以对接需求为例，对于不同体量不同成熟度项目组的需求配合的意愿也是参差不齐的。体量大或者收益较高的团队由于他们的业务以及流程脉络较为清晰，一方面需要我们能够支持快速响应，在较短的时间快速迭代日常活动的上线，另一方面他们又不会主动考虑实现的复杂度，不想由于我们的开发进度来干扰他们的排期进度，处于较难调和的沟通。

但也有类似不是很成熟的项目组找我们对需求时，对于需求的描述不是很准确，对于最终功能的表现也不是特别关心，甚至某些时候完全是我们替他们在想需求。所以其实在这过程中大量的精力会分散于不同部门之间的沟通协调，反复对同一个需求进行确认，整个结果确定的周期被无效拉长。

说话这门艺术，还是需要一直学习的。

2. 逻辑抽象能力挑战

如果说沟通协作算作一个中台产品很重要软实力的体现，那么逻辑抽象能力就是一个考验硬性能力的体现了。

因为对于一个中台所要面对的一系列解决方案，都是能够服务于多业务多项目组的，那这这套解决方案的设计不仅需要强大的逻辑思考能力，更要有抽象延展能力，在满足所有的需求同时也能够敏锐的察觉到不同需求之间的公共特性，从而输出一个面向多租户的产品解决方案。

好比说项目组需要运营平台能够支持一个白名单功能，需要满足针对特定的人群执行特殊逻辑。

这看起来是个很简单的需求功能点，但是对于中台产品来说需要挖掘一切可以复用的场景，在满足业务需求的功能前提下，抽象出公共逻辑。很明显这个需求在后期运营中需要复用的场景还会有很多，比如延展到黑名单、活跃用户、大R等用户群体，那么我们就没必要重复造轮子，每次都去开发相同或类似的逻辑。

在实际的业务场景也会有更多更复杂的事情需要解决，这个例子也是起抛砖引玉的作用。

在产品方法论文章中也有提到，有些需求其实是伪需求，还可以继续深挖。白名单功能去抽象拆解，实际就是筛选出一个用户群体，并对这个用户群体实现某种特定的功能。

这样来说的话这个需求就可以这样做：将原本一次性的白名单功能开发，实际转化为用户标签系统的开发。在基于运营平台原有的用户体系，加入用户标签功能，既能满足原有的白名单功能，又可以拓展一系列潜在的用户需求。

3. 其他挑战

从整个产品层面来说，对于中台产品的综合能力要求还是很高的。

一方面，需要有强大的业务拆解能力与功能抽象的逻辑思维能力以及全局统筹的能力，清晰地梳理出业务中的关键路径与业务流，并且能够把控整体的系统迭代能力，在业务实现中也可以把控系统功能完善的节奏。

另一方面，又需要面面俱到的沟通和协作能力，能够在游走在多个业务线之间，不断稀释平台建设的成本分摊精力，与此同时也要满足好业务方的需求，同整个系统的相关干系人一同推动完成整个中台的功能实现。

五、后记

自然规律是由无序变有序，而产品的诞生其实也是这种说法的表现形式之一。我之前也说过，产品就是一套标准规律的运行。而中台更像是整个系统的一个规律体，当随着整个系统的愈发膨胀，才会更加体会到中台系统的作用。

作者：WāngWénhào；微信公众号：阿司匹汪（aspWwang)

本文由@ WāngWénhào 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议。