supercell公司负责一款游戏的每个团队平均只有 5 到 7 名团队成员。团队有充分的自由，他们可以自行决定开发什么样的产品，之后就会以最快的速度推出公测版，让市场来评判，来验证产品的好坏。一旦产品不成功，则迅速放弃，此时不但不会有任何惩罚，反而团队会举杯庆祝，之后立即做出调整继续迅速寻找新的方向。
要想让这个机制得以正常运转，必须有一个前提，就是产品的构建时间要足够短，试错的成本要足够低，这样才能保证团队在大量的试错中，通过不断从失败中学习，持续迭代调整，尽快找到正确的方向，让创新成功的进度条快速前进。
而背后支撑这个机制得以实现的，就是 Supercell 经过 6 年时间沉淀下来的游戏开发过程中那些公共的、通用的游戏素材和算法。基于这些像乐高积木一样的基础素材和算法，才可以同时支持几个小团队在几周时间内像搭积木一样快速研发出一款新游戏。
上面这个小故事一直被认为是触动阿里巴巴下决心建中台的原因，姑且不论这个因果关系的真实性，阿里巴巴倒确实在国内成为了第一个吃中台螃蟹的公司，并陆续引起了国内一众互联网公司甚至传统行业公司建中台之风。但这阵风刮了几年后的现状是，阿里巴巴又成为了第一个拆中台的公司，所谓合久必分分久必合，无论建还是拆，都有其成立的理由，但如此纠结往复的背后折射出的，其实是中台建设和推广之难。
在笔者看来，中台之类的平台，都可以分为初建期、推广期和服务期三个不同的阶段，中台之类的平台要能够顺利诞生并茁壮成长 ，必须克服这三个阶段面临的困难，这里面有技术方面的复杂度和挑战、有业务抽象能力面对变和不变边界的复杂度和挑战，更有技术和业务之外的管理和人性的挑战。在我看来，技术和业务的挑战其实都是能战胜的，更难解决的其实管理和人性的挑战。因为笔者曾经作为一个建立过平台且担任过平台型团队的管理者，我深知建立并推广类似中台这一类的平台在处理管理和人性等问题上是多么的困难。
在上一篇文章《产研团队组织架构设计》里，我们最后聊到，作为公司的公共平台团队，比如基础架构团队、中台团队等，在初期可能会面对如何找第一个客户的问题，但随着支持的业务线越来越多，自身的资源又可能会慢慢成为瓶颈，就好比人怕出名猪怕壮，当你影响力变大了，幸福的烦恼也就随之而来了。所以，在不同的时期，我们要解决好不同的问题，才能将我们好不容易建好的平台和服务推广出去，进而实现价值。
今天，就来聊聊我在平台建设和推广的过程中碰到的那些管理和人性问题以及我的应对之道，希望这些经验能够帮助大家建好和用好自家的中台。
正好我在百度期间，某段时间也曾负责一个平台型团队，经历了我们开发的平台从0到1以及从1到n的过程，这个过程也是一路艰辛，克服了很多障碍和问题，最终这个平台在部门内外顺利推广应用，接入了大量的产品线。
因此，接下来就跟大家聊聊，一个平台型团队从0到1把平台做起来，以及从1到n把平台成功推广应用，都会经历哪些困难以及我们是如何解决的。
-
平台初建期
这个时期的主要任务是完成平台的设计和开发，技术上的复杂度是如何进行公共部分抽象、梳理和界定平台和应用的边界以及平台自身的架构选型和设计等，这部分主要是业务和技术上的问题，在这里就不赘述了。
这个时期涉及到一个管理上的问题，就是平台的开发资源如何协调。我们之前都是一个个的team负责不同业务系统的开发，没有专属的平台开发资源。
这里一般有两种方式，一种是直接成立专门的平台团队，一种是从各个业务开发团队抽调资源成立虚拟平台团队。
我们采取的是第二种方式，而且我也更建议在资源不是很充裕的情况下，优先采取第二种方式。第二种方式还有两个好处：
-
没有硬性地把平台团队的人和业务团队分离，毕竟人都是有自己的归属感的，让抽调的人暂时还是归属原来团队，只是临时支持平台开发，从个人心理上更好接受一些，对人员稳定性更好；
-
而且，一旦人还是属于原业务团队，其原团队的leader也自然会持续关注到平台的相关信息，当然我们的做法更直接，会把各业务团队leader主动拉进来，作为1.0项目干系人，会参与我们的各种重要会议，受到各种相关文档和邮件。为什么要这样？因为我们平台后续要推广啊，这些业务方就是我们的客户啊，一方面我们得维护好“客情关系”，另一方面，让leader及时准确了解平台的信息，对后续接入平台是有帮助的，毕竟没有一个人愿意痛快地购买一个之前听都没听过的产品吧；
这里顺带要提一下的就是，对于被抽调的人，这段时期的绩效或okr是需要做一下调整的。
通过上面这种方式，我们的1.0平台也算是顺利的搭建起来了。
-
-
平台推广期
平台建好了，接下来的事情就是找客户了，也就是我们得把我们的平台推广出去。
前面一步我们讲到，我们在1.0建设初期，把各个业务团队leader拉进来维持好客情，就是为了接下来的推广能够更顺利。
但是事实证明，客情维护有用吗？有用。毕竟我们在推广我们的平台的时候，各业务线leader明面上都还是挺客气的，也都表示欢迎接入平台。但一旦落实到实际接入工作，各种问题就来了：时间紧任务重、业务开发压力大、接入需要成本人手不够、接入后怕出问题、出问题担心平台是否能及时跟进等等。
所以，和客户的感情基础其实有了，差的是临门一脚，我们需要帮客户打消顾虑，为此，我们采取了一个措施：每接入一个业务，我们都派若干平台的工程师加入到项目组。这样做有两个好处：
-
平台工程师的加入，肩负两个任务，一个是在项目过程中，对平台的使用进行培训以及出现问题的时候随时支持。一个是他本身也参与到项目开发中，为业务方解决资源问题；
-
平台工程师在参与业务开发的过程中，能够站在客户的角度，体验我们平台的接入成本、开发成本、易用性、稳定性、性能等问题，相当于直接拿到了平台使用反馈，便于后续平台的迭代升级；
-
通过上述的方式，我们顺利拿下第一个业务，随着第一个业务接入的上线，后续的业务接入就顺利得多了。
- 平台服务期
随着接入平台的业务越来越多，这个时候逐渐暴露出两个问题：
-
平台的开发资源逐渐成为瓶颈；
-
如何处理不同客户的差异化需求和排期冲突；
缺资源可以靠招聘，但我们也要考虑平台投入的ROI，不能一味招人。我们在招聘之外采取的解决方案是，将平台进行公司内部开源，让有兴趣参与的工程师都能参与平台建设，这样做有几个好处：
-
解决了平台的开发资源问题；
-
为业务开发工程师提供了一个参与技术复杂度更高的项目的机会，对提升其技术能力有帮助；
-
进一步提升了平台在公司内部的知名度，为扩大推广打下了良好基础；
作为一个公共服务部门，一定会碰到多个前台的需求、排期、质量要求、非功能需求出现不同的情况，甚至也会经常出现多个前台之间的需求或是非功能性需求彼此矛盾的时候。而平台自身的资源有限，且有自己的愿景，不可能无条件地满足所有前台用户的诉求，往往就会陷入疲于应对的状态，对前台的响应和服务质量也会急速降低
如果我们采用产品化的思维来构建平台，那平台中所沉淀的能力并不是产品的全部，还需要再加上 NFR（非功能性需求）或是我们常说 SLA（Service-Level Agreement，服务等级协议）才是产品，因为不同的前台用户之间，不只是对于平台产品的功能本身有着不同的诉求，同样对于 NFR 或是 SLA 也有着不同的诉求。简单举个例子，比如核心业务对于平台的 SLA 稳定性的要求可能是 5 个 9，性能是 5 毫秒；而一个新的创新型应用，可能还没有用户，就不需要有这么高的要求
如何利用有限的资源，服务好不同用户的不同诉求呢？答案就是对于前台用户基于需要的能力和 NFR/SLA 做用户划分
最常见的就是三层用户划分机制（3 tiers customer segmentation）。通过对于前台用户的分层，我们就可以为不同层次的用户指定不同的需求响应机制、不同的沟通管理机制、不同的服务质量控制机制、不同的问题处理及升级机制等等。自然不同的服务类型作为前台用户也需要付出不同的成本或是资源（人或钱），甚至前台与平台可以通过签署 SLA 来实现对于前台用户的服务承诺
举个例子， 当我们开始平台建设时，可以只找到一个或是两个种子用户，作为 Tier1 级别的用户来服务。对于这个种子用户的需求作为最高优先级的需求来对待，并建立例行的沟通机制和服务响应机制。因为此时的服务还处于初建时期，还不是特别的成熟，所以可以采用“免费”的方式动用企业的战略资源来进行建设。这样，对于前台用户来讲，资源是免费的，而且是一对一式服务，自然也会乐意配合到平台的建设过程中。
当平台建设到一定阶段之后，对于种子用户的服务已经接近稳定，有了一定的能力沉淀，也能释放出一定的资源了，就可以利用释放出来的资源开始为 Tier3 层的用户构建自助服务控制台（Self-Service Console），并着手构建平台产品的运营团队，制定 Tier3 层的 NFR/SLA。在很多互联网企业，这个过程常常由于做出来的自助服务控制台比较粗糙，看起来也像是对于平台服务的增强和可用性优化和治理的过程，大多数就是一个白屏幕，加一些的配置选项，所以常被称为“平台的白屏化”。
当平台的自助服务控制台创建完成，Tier3 层次的 SLA 也构建完成后，我们就可以重新签订 SLA，将之前的 Tier1 用户迁移到 Tier3 层次，即完成之前种子用户从定制化服务到自助式服务的迁移过程，从而释放出更多的资源用于接入新的前台用户。
如果由于种种原因，无法一步到位实现服务的完全自助化，还可以通过构建 Tier2 层的 SLA，也可以通过重新签订 SLA，将之前的 Tier1 用户迁移到 Tier2 层次，通过“自助 +VIP 服务”的方式，保持对前期种子用户服务连贯性的同时释放出尽可能多的资源。
此时我们就已经有了三层的用户划分机制，可以在企业内更大范围地发布 Tier3 的自助式服务，通过这种方式实现更多用户的接入。同时，因为已经释放出一些平台的资源，我们就可以继续选取下一个关键的种子用户（一般是关键业务），作为新的 Tier1 级用户开始第二轮平台建设的推进。
至此，通过平台的用户分层和运营机制，就可以构建不同层次的运营体系，从而实现资源的合理调配。我们也就避开了前面提到的平台建设过程中的各种问题和陷阱，对用户分级运营，从而解决需求矛盾、排期冲突、资源紧张、推广缓慢等问题。
其实建中台就好比建人设，推广中台就好比推销自己，背后的某些道理是相通的。当你能够更好地管理好自己的人生，相信你也能够更好地管理好团队。从管理实践中思考人生，希望和大家一起痛苦并快乐着。