全方位拆解技术中台：一家低调研发大厂的实战案例

上周三（2月15日），IGDC国际游戏开发者大会（暨2022广东游戏产业年会）在广州召开。

百奥技术中心负责人韩标在大会上分享了他们公司在搭建技术中台方面的经验：从职能定位、人才建设，到管控机制、保障体系。从这篇演讲中，葡萄君也隐约看到了一家游戏公司中台建设从无到有的过程。

最近四、五年来，游戏行业关于中台的讨论逐渐由浅入深。不仅许多大厂在中台上投入了顶级的人员和资源配置，中小团队也纷纷讨论、验证中台的可行性。

许多公司发现，中台建设（尤其是技术中台）不仅起步很难，更是一项长期投资，需要耐心和恒心才能看到成效。例如我们的一位技术中台负责人读者就曾表示：游戏技术中台要想起作用，没有3年都很难。

百奥技术中心负责人韩标

一家游戏公司的技术中台可以做什么？应该怎么做？以下是韩标的演讲整理（为便利阅读体验，内容有所调整）：

韩标：分享一下过去几年我们公司在引擎中台建设的思路。第一部分，介绍中台的定位和职责；第二部分，介绍中台内部的部门和岗位设置；第三部分，介绍管控中台工作质量、效率的机制及其体系化；第四部分，介绍中台技术团队人才建设的方向。

01 技术中台的定位和职责

我们对（技术）中台部门的职责做了一个梳理，总共分为专家服务、质效保证体系、创意孵化、专业人才任用与发展、资产整合与配置五个部分（详见下图）。

根据岗位划分，中台内部每个组都对应着不同的职能。TA（技术美术）组主要负责手游项目渲染管线的定制与优化，材质效果、3D研发工艺的实现与优化，以及渲染新技术的研究和落地。

客户端（引擎）组主要负责公司内通用框架和组件的开发和维护、相关编辑器、工具链的开发维护、疑难问题的技术攻坚，重大技术方案的评审，客户端相关的标准及对应性能优化，还有前沿技术的预演及落地。

服务器（后端）组和客户端组类似，在不同的条线上承担同样的职能。AI就是在游戏开发的生产环节、创新玩法方面做探索和落地应用的尝试。

最后一个是集成，目前行业内可能比较少见。这是我们在常规开发以外独立出来的一个职能，除了负责UI界面的拼接，还包括其他美术资源引擎类的集成工作，制定规范以及规范检查。同时，集成也负责开发环境支持和一些技术问题的跟进处理，这个主要针对非技术同学，比如说美术、策划在搭建Unity环境过程中遇到问题，也是由集成负责。

02 内部分工和组织架构

在梳理项目和中台关系时，我们考虑过两种方案。第一种是早期方案，每个项目组不同的模块都是由对应中心负责人直接管理的，项目组负责人并不参与对这些组主管的考核与管理。这个对应的模式就是中台负责制，也就是以垂直方向的线条为主的一种管理。

由于在中台搭建早期，TA、引擎这些岗位其实专家并不多，人数有限，又要服务多个项目，所以主要是按专业细分来内部分工。

以TA为例，我们发现如果某一个同学负责多个项目角色方面的材质，因为他要同时负责多个项目，对每个项目具体情况、深度问题的了解及其处理速度，其实就比较难保障。专家人才资源丰富之后，我们就做了对应调整：不同项目分别有一个跟进的TA组，这样就可以保证对项目组的支持力度和响应速度。同时，考虑到研发成本和技术复用，TA组之间也有灵活分工。引擎、集成也是同样的一个划分方式。

项目组成员包括后端和前端。后端开发往往有多名服务器开发工程师，而前端因为业务比较重，我们是把战斗、剧情、业务组分别独立出来。以剧情为例，我们的PV、过场动画、AVG对话、3D剧情，还有战斗演出，每个项目都会有一个剧情组的同学专门跟进这一块的技术开发和实现。同时，技术中心的TA、引擎和集成点对点地去跟进项目，但编制是属于中心。

后一种思路就是项目负责制（属地管理制），由这个项目组的负责人（一般就是制作人）全面地去管理自己的整个团队。现在我们中台仅仅是提供专业技术的指导和支持，以及在各个项目初始阶段承担技术主管的职能，最后形成了一个条块结合、双线管理的模式。也就是说，项目的负责人和中台同时主持前端、后端的考核。

我们也整理了技术中台与项目负责人、公司高层、美术、测试或者其他中台在协作上面临的挑战。造成冲突的原因，可能是个人的技术成就与整个公司整体的发展不完全一致，也可能是看问题的视角不同。协作中有很多岗位同时参与，信息在传播中也可能会衰减或缺失。

职责之间的灰色地带也可能形成冲突。比如说性能优化会涉及到多个岗位，每个岗位具体负责什么，一些标准、流程如何制定，具体的优化任务如何分配，如何排查分析，如何验收，这些我们一开始可能会尽量去做梳理，但是也不可能一开始做得那么到位，所以也会存在冲突。识别了相关方和常见冲突的来源之后，我们的主要思路还是在冲突发生之前制定处理流程和规则。

还有一个比较普遍的问题是，一个技术方案选型或者说底层框架、组件设计，到底是以通用性为主，还是说要尽快把它做出来以满足项目组的需要，这也是潜在的冲突来源。

03 技术团队人才建设

团队建设方面，和大家熟知的三角形或者说倒三角结构有点不同，椭圆形分布更适合当前我们团队和手游项目开发的需求。

因为我们不少内部机制的分工是按专精化分工去设计的，所以具体到团队人才建设上我们就提出了一专多能的方向。每个人都有一个主攻方向、一个副攻方向；同时，每个专业条线都要有一个专家以及多个能手。这种思路的优势，一方面是追求复合型人才，另一方面也有利于团队提高沟通效率，灵活分配工作，开发团队更加健壮，总的项目成本也会更低，更能适合当下的环境。

新项目通过创意评审、正式启动后，公司会考虑从中台挑选合适的专家，把他们的编制转到项目组定点服务，就地参与核心功能开发，同时培养新人。当项目组开发团队成型、稳定之后，这部分专家可以留在项目组，或者逐步调回技术中心后，再派出支持其他项目。

04 保障机制及其体系化

我们的质量、效率（保障）体系总体上贯穿开发、测试以及上线这三个大的阶段。

我们总结认为，质效体系的基础可以体现或者说积累在整个研发过程的最左侧，比如说引擎、框架、组件、工具链、编辑器以及内部的知识库（包括内部的技能培训、案例库、经验总结、事故集，还有相关的制度、流程和规范等），以及对应的组织架构。这也是进入开发阶段的基础。

质效体系在开发阶段主要体现为任务管理平台和自动化，在测试阶段主要体现为真机性能测试、兼容性测试、协议安全测试、服务器压测平台等集成，各个环节、流水线尽量自动化去运行，而在上线阶段主要体现为同时对我们的版本、产品、过程质量进行监控和复盘。也就是说，在高质量的结果以外，我们也要追求高质量的过程，在循环迭代的过程中不断丰富质效体系最左侧的部分。

下面通过几个相关制度或者流程建设的例子来具体说明。其一，我们规划了一些对应不同项目阶段的技术评审。进行技术评审是为了提前发现风险、发现问题。比如第一次封闭测试，就要做客户端性能、兼容性或者其他测试。有一定用户量后，也会有对应的技术评审、服务器压力测试等工作。每个项目阶段我们都会开展技术评审，以管控技术方面的风险。

其二，我们确立了一个版本分支工作流，在标准的GAT工作流基础之上做了定制和调整。除了不同职能的5个开发分支，分版本之后还有月版本分支。如果验收测试通过，确定发布日期，就会在周分支上合并到的Hotfix（热更新）分支。如果线上的分支发生了BUG，需要紧急修复，我们就是在Hotfix分支上直接进行处理。这样就可以保证周分支、月版本分支以及我们的主干开发是隔离的，互不影响。最上层的Master（主）分支是只读的，不会进行修改，各分支开发完毕之后都会同步到Master分支上打好标签。为了减少复杂度，我们还把包括海外在内所有不同地区的版本都放在同一个版本上进行开发，对应的翻译以及本地化都在克隆的分支上进行操作，以方便后续的迭代。

其三，我们对业务功能开发流程进行了梳理。待开发的功能，开单后首先在任务管理平台上显示待办，随后进入交互设计环节，待UI资源制作完后，集成进行界面拼接，拼接完成后才会开始安排开发的工作。开发完成后，策划会针对主要功能和需求点做初步确认；初步确认后，QA进行测试验收；最后，是策划做最终的验收。如果有新增的迭代优化内容，我们会重新开单进行管理，不会回到原有工单。我们还提前梳理了整个线性流程，制定了每个环节到另外一个环节流转的条件、对应负责人。