软件工程师罗小东，多年渠道架构规划和落地经历，这儿首要是针对于中台化项目交授予传统项目交给的一些心得领会。
理念
Supercell游戏开发公司内部有一套技能渠道，旨在提供支撑Supercell开发的多款游戏的同享东西、技能和根底设施。这个中台包括了各种组件和服务，如玩家账户体系、交际网络功用、统计剖析东西、虚拟货币交易体系等等，这些东西和服务都可以在Supercell开发的不同游戏之间进行同享和复用。
让Supercell游戏开发团队愈加专心于开发游戏自身，而无需重新开发现已存在的功用或迎合特定游戏的需求。一起，这也可以促进Supercell内的常识同享和协作，并且下降整体开发本钱和危险，这也是中台架构的由来。
概述
在过去几年中，咱们一向专心于中台架构和项目的开发。尤其是在处理中小型项目方面，咱们积累了丰富的经历。以下是一个典型事例的剖析，咱们将从实践中总结出的心得和经历。在23年的第一季度，团队完结了一个约为百万级的大数据项目。咱们采用中台产品和ISV（事务组）合作伙伴的方法进行交给。
SuperCell形式在交给和团队优化方面有明显的不同。仅仅说感觉相对于网上各种理论来说，各种概念的解说来说，本来初衷的理念愈加契合，而我想要的也是这个形式，而不是网络上被各种名词和概念所淹没的中台形式，有时分会把一些简略的工作说得太过于玄乎，而没有体现初衷，这也是为什么标题运用SuperCell的原因。
起初听到芬兰SuperCell形式时，原本觉得有这个或许，可是进程当中的领会没那么深，对外交流的时分，各种底气还是来自于一些资料，可是当真正自己在用SuperCell形式(也便是中台)的时分，你会发现，这个结构在必定的程度上确实将团队的结构还有才能进行了优化处理，并且整个流程进程会愈加顺畅，这儿首要从几个角度进行论述：
-
项目中的中台安排结构是怎样样的；
-
进程怎样分工处理一起做好前端的支撑；
-
进程的一些常见问题和躲避操作；
不同于大厂的中台交给形式，但团队和经历不同，因此咱们只针对中小型项目进行阐明，我有我思。
进程
在进程中，做了很多的责任分离，这儿针对于本来的数字中台运营方法来进行，角度论述也是从这个运营思路。
项目中的中台安排结构是怎样样的
传统项目的安排结构会一个项目从各个层级跟到尾，或许办理团队多个方面，而这儿略有不同。
在这个大数据项目里边，咱们的安排结构基本上对项目经理的责任还有中台人员的责任进行了调整（这儿不提商务）。
在传统或许一般的项目里边，项目经历对接的责任和规模或许会比较大，在项目组里边人员权限也比较大，调动的人员或许从下层的开发和底层的技能人员或许都会触及，而在中台的安排结构里边，咱们把项目结构进行了两层拆分，分成了中台层和项目层，而项目经历对接的仅仅每层的负责人。另一个是项目的施行进程也进行了拆分，分多个阶段，一个是中台的产品交给和事务需求的施行交给，还有另一个是中台后期的支撑。
感觉这个进程如同跟一般的项目进程，比方甲方乙方等施行交给区别不大，我第一感觉也是如此，可是实践并不是。
这个阶段之间的分隔，在传统项目交给里边并没有那么清晰，并且人员认识还有团队认识，进程的交流，交给产品等，各个人物支撑力度等需求愈加的清晰，怎样说的呢，便是在前期一些训练阶段的时分，问题最多不是技能，反而是这个阶段之间的施行问题。常常会呈现，要么便是事务进到中台层里边，要么便是中台层进入到事务里边，相似的状况，往往是缺少阶段处理的认识，这个就会构成必定的交给危险。
中台层要做的是架构方面和必定规模才能的技能的支撑，可是不要介入到事务里边，事务场景最合适的事务层的处理办法，中台需求提供的是渠道级的才能，由于中台层要支撑的不仅仅是一个项目，而是多个项目，这个需求在支撑阶段提出清晰的支撑才能，哪些有，哪些没有。
事务只需求依据中台的才能来进行场景的规划，如果需求的或许确实没有的而必定需求用到的，或许提交需求到中台即可，而不是等着中台处理事务问题，构成两头的死循环。
在前期的安排结构初期，就做了清晰的交流要求了边界，清晰区分哪个阶段参与和清晰提出计划和时刻。
进程怎样分工处理一起做好前端的支撑
传统项目或许前期有需求还有原型等之类的，或许需求调研之后才会考虑到施行，这儿也略有不同。
在数字中台上会带有一部分根底的事务才能，还有一些通用的服务组件，在项目确认开端之后，基本上施行计划和工作就现已开端，别的加上是一些数据类项目，通用的组件更多，而咱们要做的是数据输入层，也便是数据调研和采集，这个前期都有必定的模板和样例，在项目开端的前一周，施行的准备条件就已开端布置，交给出第一版别给客户演示的时分，差不多是项目开端后的两三个星期左右，后边便是训练运用。
而这个进程事务端在进行事务的处理的开发，中间加上客户的时刻状况等等，这个事务型开发的时刻在一个月左右，由于在中台上也包括技能devops，在这个进程都会自动同步到用户测试环境，这个进程时刻相对来说，也比较从容，事务团队进程中需求的文档和手册等处理，中台团队会有一些训练，这个训练时刻大概是前面的三天左右时刻。其它的便是等数据调研这部分的成果，完结之后数据采集到数据中台里边，进一步的分层、计算、接口等获取到指标，输出给事务方，这部分首要是中台的进程中的操作，同步带好事务端的人员怎样运用，带好流程。
这个进程中一个比较大的领会是人物定位和分工上，还有时刻点的把控上等都会比较清晰，会有一些卡点，可是相对于以前传统项目方法来说，这个会愈加清晰。
进程有碰到的一个时刻是过年时刻，在这个时刻后，基本上事务演示的第一版别也就出来了，在给领导层做演示，得到必定的认可后，基本上就走验收流程。前后大概是两个月的时刻，其它的时刻点会有一些运维和办理的操作，这部分在事务上，也在移交到运维层面上，在项目上投入的资源也进一步的减少。
这个进程中的一个比较清晰的领会便是时刻，时刻点上会比较清晰和按时，如果说事务组在缺少数据中台产品的支撑和中台团队的支撑，是基本上不或许在这么短的时刻出的成果，而中台团队没有前期的积累也基本上不太或许会跟事务组和项目施行等配合得好。甚至在施行进程中，由于事务组一向做的是事务组件（咱们把事务组件分开和微服务化），在交给施行进程才发现这个项目是一个比较大的项目，触及到模块那么多，这也是本来考虑的，事务组要做的是做好事务场景需求就可以，其它的中台层给好支撑点。
别的一个要素是中台和事务组的磨合，初期的项目会有一些磨合，如果这个进程没有做过，或许会消耗一至两周的时刻点，这个需求考虑的。
进程的一些常见问题和躲避操作
进程一向强调人物和责任，事务组和中台组就做好自己的工作就可以。
在这个进程中，也会有很多的坑点，一些不留意或许也会构成项目后期的问题，相似于技能债，大致列了几个问题：
1. 防止让事务组触摸太多的技能概念而忽视事务
在中台会有很我技能概念和学习层面，这个进程简略使事务组的技能人员深化到技能层面，比方微服务、容器化、主数据、Hive等，它需求的是一个模板和运用阐明，而不是研究阐明，依据事务场景来进行模板输出就可以，后边依据个人兴趣去学习即可，重点是给出运用事例。比方数据采集，跟事务组人员说“发送到数据总线”或许他们会模糊一下，可是跟他说“发送到这个API接口”他就立马明白。
2. 施行进程中台文档的产出
文档资料的产出是进程中特别需求留意和加深的，也是中台组的要求，这儿对事务组的要求由项目经理，可是中台组的要求是必定要有文档的产出，这个文档的产出并不是仅仅一个项目，而是多个项目都有在运用的时分，这些文档和沉淀对中台组来说含义就比较大，实现的输出的含义也比较大，一起对文档有比较严厉的要求，格局还有内容等，构成高质量的文档，这部分不管在哪个项目都做了强制性的要求，一起便利后期更新迭代等。
3. 防止两个组之间相互切换和沉入
中台切入事务，事务切入中台，这个是前期特别简略呈现的问题，只需求一个简略的场景，在讨论进程中，如果没有这个认识，就会变成中台组在做事务组件开发的状况出来，或许事务组提要求了，然后中台组依据特定（留意是特定）修改中台组件的状况，后边一种是咱们特别简略呈现的，并且也特别头大，有些状况下确确实实是中台组加个字段或许加个功用会比较简略，可是这个特点是某事务特有的，实践上这个进程从事务组做保护会更好。比方咱们会用电信厂家的接口发送短信，而不会给个单独给某个事务设置接口，除非说这个接口有多行业公共的特点，那再统一集成。
当然，还有周期、工时、支撑、商务等挺多方面，这些首要依赖于进程的团队的状况和办理方法进行处理，这儿就不做过多的论述。
总结
在前期多个中小型项目中，咱们建设中台体系的进程虽然有听说中台形式的优点和优势，可是身边比较少成功的事例（除了一些大厂），或许说在运用了并没有发挥出它自身应该有的作用，结合起来发现并没有到达降本增效的层面，反而发现进程愈加复杂和麻烦，最终发现或许还没有本来单体应用的简略。
这些以前见到其它堕入的比较多，从自己的心得来说，这些是一个进程点，可是要到达终点，这个需求比较大的，并且长期的团队实战和不断迭代升级进程，上面是在这方面的心得领会，希望或许给一些参阅。
