我在中小型项目 SuperCell 模式实战经验

软件工程师罗小东，多年平台架构设计和落地经验，这里主要是针对于中台化项目交付与传统项目交付的一些心得体会。

理念

Supercell 游戏开发公司内部有一套技术平台，旨在提供支持 Supercell 开发的多款游戏的共享工具、技术和基础设施。这个中台包括了各种组件和服务，如玩家账户系统、社交网络功能、统计分析工具、虚拟货币交易系统等等，这些工具和服务都可以在 Supercell 开发的不同游戏之间进行共享和复用。

让 Supercell 游戏开发团队更加专注于开发游戏本身，而无需重新开发已经存在的功能或迎合特定游戏的需求。同时，这也能够促进 Supercell 内的知识共享和协作，并且降低整体开发成本和风险，这也是中台架构的由来。

概述

在过去几年中，一直专注于中台架构和项目的开发。尤其是在处理中小型项目方面，积累了一些的经验。以下是一个典型案例的分析，将从实践中总结出的心得和经验。

SuperCell 模式在交付和团队优化方面有明显的不同。只是说感觉相对于网上各种理论来说，各种概念的解释来说，原来初衷的理念更加符合，而我想要的也是这个模式，而不是网络上被各种名词和概念所淹没的中台模式，有时候会把一些简单的事情说得太过于玄乎，而没有体现初衷，这也是为什么标题使用 SuperCell 的原因。

起初听到芬兰 SuperCell 模式时，原本觉得有这个可能，但是过程当中的体会没那么深，对外交流的时候，各种底气还是来自于一些材料，但是当真正自己在用 SuperCell 模式(也就是中台)的时候，你会发现，这个结构在一定的程度上确实将团队的结构还有能力进行了优化处理，而且整个流程过程会更加顺利，这里主要从几个角度进行阐述：

1. 项目中的中台组织结构是怎么样的；

2. 过程怎么分工处理同时做好前端的支撑；

3. 过程的一些常见问题和规避操作；

   
   

不同于大厂的中台交付模式，但团队和经验不同，因此我们只针对中小型项目进行说明，我有我思。

过程

在过程中，做了很多的职责分离，这里针对于原来的数字中台运营方式来进行，角度阐述也是从这个运营思路。

项目中的中台组织结构是怎么样的

传统项目的组织结构会一个项目从各个层级跟到尾，可能管理团队多个方面，而这里略有不同。

在这个大数据项目里面，我们的组织结构基本上对项目经理的职责还有中台人员的职责进行了调整（这里不提商务）。

在传统或者一般的项目里面，项目经理对接的职责和范围可能会比较大，在项目组里面人员权限也比较大，调动的人员可能从下层的开发和底层的技术人员可能都会涉及，而在中台的组织结构里面，我们把项目结构进行了两层拆分，分成了中台层和项目层，而项目经验对接的只是每层的负责人。另一个是项目的实施过程也进行了拆分，分多个阶段，一个是中台的产品交付和业务需求的实施交付，还有另一个是中台后期的支撑。

感觉这个过程好像跟一般的项目过程，比如甲方乙方等实施交付区别不大，我第一感觉也是如此，但是实际并不是。

这个阶段之间的分隔，在传统项目交付里面并没有那么明确，而且人员意识还有团队意识，过程的沟通，交付产物等，各个角色支持力度等需要更加的明确，怎么说的呢，就是在前期一些培训阶段的时候，问题最多不是技术，反而是这个阶段之间的实施问题。常常会出现，要么就是业务进到中台层里面，要么就是中台层进入到业务里面，类似的情况，往往是缺少阶段处理的意识，这个就会形成一定的交付隐患。

中台层要做的是架构方面和一定范围能力的技术的支持，但是不要介入到业务里面，业务场景最合适的业务层的解决办法，中台需要提供的是平台级的能力，因为中台层要支撑的不仅仅是一个项目，而是多个项目，这个需要在支撑阶段提出明确的支撑能力，哪些有，哪些没有。

业务只需要根据中台的能力来进行场景的规划，如果需要的或者确实没有的而一定需要用到的，或者提交需求到中台即可，而不是等着中台解决业务问题，形成两边的死循环。

在前期的组织结构初期，就做了明确的沟通要求了边界，明确划分哪个阶段参与和明确提出计划和时间。

过程怎么分工处理同时做好前端的支撑

传统项目可能前期有需求还有原型等之类的，或者需求调研之后才会考虑到实施，这里也略有不同。

在数字中台上会带有一部分基础的业务能力，还有一些通用的服务组件，在项目确定开始之后，基本上实施计划和工作就已经开始，另外加上是一些数据类项目，通用的组件更多，而我们要做的是数据输入层，也就是数据调研和采集，这个前期都有一定的模板和样例，在项目开始的前一周，实施的准备条件就已开始部署，交付出第一版本给客户演示的时候，差不多是项目开始后的两三个星期左右，后面就是培训使用。

而这个过程业务端在进行业务的处理的开发，中间加上客户的时间情况等等，这个业务型开发的时间在一个月左右，因为在中台上也包含技术 devops，在这个过程都会自动同步到用户测试环境，这个过程时间相对来说，也比较从容，业务团队过程中需要的文档和手册等处理，中台团队会有一些培训，这个培训时间大概是前面的三天左右时间。其它的就是等数据调研这部分的结果，完成之后数据采集到数据中台里面，进一步的分层、计算、接口等获取到指标，输出给业务方，这部分主要是中台的过程中的操作，同步带好业务端的人员怎么使用，带好流程。

这个过程中一个比较大的体会是角色定位和分工上，还有时间点的把控上等都会比较明确，会有一些卡点，但是相对于以前传统项目方式来说，这个会更加明确。

过程有碰到的一个时间是过年时间，在这个时间后，基本上业务演示的第一版本也就出来了，在给领导层做演示，得到一定的认可后，基本上就走验收流程。前后大概是两个月的时间，其它的时间点会有一些运维和管理的操作，这部分在业务上，也在移交到运维层面上，在项目上投入的资源也进一步的减少。

这个过程中的一个比较明确的体会就是时间，时间点上会比较明确和准时，如果说业务组在缺少数据中台产品的支撑和中台团队的支撑，是基本上不可能在这么短的时间出的结果，而中台团队没有前期的积累也基本上不太可能会跟业务组和项目实施等配合得好。甚至在实施过程中，因为业务组一直做的是业务组件（我们把业务组件分开和微服务化），在交付实施过程才发现这个项目是一个比较大的项目，涉及到模块那么多，这也是原来考虑的，业务组要做的是做好业务场景需求就可以，其它的中台层给好支撑点。

另外一个因素是中台和业务组的磨合，初期的项目会有一些磨合，如果这个过程没有做过，可能会消耗一至两周的时间点，这个需要考虑的。

过程的一些常见问题和规避操作

过程一直强调角色和职责，业务组和中台组就做好自己的事情就可以。

在这个过程中，也会有很多的坑点，一些不注意可能也会形成项目后期的问题，类似于技术债，大致列了几个问题：

1. 避免让业务组接触太多的技术概念而忽视业务

在中台会有很我技术概念和学习层面，这个过程容易使业务组的技术人员深入到技术层面，比如微服务、容器化、主数据、Hive 等，它需要的是一个模板和使用说明，而不是研究说明，根据业务场景来进行模板输出就可以，后面根据个人兴趣去学习即可，重点是给出使用案例。比如数据采集，跟业务组人员说“发送到数据总线”可能他们会迷糊一下，但是跟他说“发送到这个 API 接口”他就立马明白。

2. 实施过程中台文档的产出

文档材料的产出是过程中特别需要注意和加深的，也是中台组的要求，这里对业务组的要求由项目经理，但是中台组的要求是一定要有文档的产出，这个文档的产出并不是只是一个项目，而是多个项目都有在使用的时候，这些文档和沉淀对中台组来说意义就比较大，实现的输出的意义也比较大，同时对文档有比较严格的要求，格式还有内容等，形成高质量的文档，这部分不论在哪个项目都做了强制性的要求，同时方便后期更新迭代等。

3. 避免两个组之间互相切换和沉入

中台切入业务，业务切入中台，这个是前期特别容易出现的问题，只需要一个简单的场景，在讨论过程中，如果没有这个意识，就会变成中台组在做业务组件开发的情况出来，或者业务组提要求了，然后中台组根据特定（注意是特定）修改中台组件的情况，后面一种是我们特别容易出现的，而且也特别头大，有些情况下确确实实是中台组加个字段或者加个功能会比较简单，但是这个属性是某业务特有的，实际上这个过程从业务组做维护会更好。比如我们会用电信厂家的接口发送短信，而不会给个单独给某个业务设置接口，除非说这个接口有多行业公共的属性，那再统一集成。

当然，还有周期、工时、支撑、商务等挺多方面，这些主要依赖于过程的团队的情况和管理方式进行处理，这里就不做过多的阐述。

总结

在前期多个中小型项目中，我们建设中台体系的过程虽然有听说中台模式的好处和优势，但是身边比较少成功的案例（除了一些大厂），或者说在使用了并没有发挥出它本身应该有的作用，结合起来发现并没有达到降本增效的层面，反而发现过程更加复杂和麻烦，最后发现可能还没有原来单体应用的简单。

这些以前见到其它陷入的比较多，从自己的心得来说，这些是一个过程点，但是要达到终点，这个需要比较大的，而且长期的团队实战和不断迭代升级过程，上面是在这方面的心得体会，希望可能给一些参考。