09 中台落地第四步：中台的建设与接入（Delivery）
你好，我是王健。
通过上一节课介绍的内容，我们最终拿到了一个作为切入点的中台场景，并且通过业务梳理识别出对于数据、流程、功能的复用需求，并结合MVP原则，找到第一个快速验证的需求集，结合前台的接入条件，形成了第一个小的中台建设冲刺计划，并以终为始，在开始前确定好中台建设的验证指标，有了需求、计划、验收条件。
如果能够顺利通过企业内部的立项审核和流程，那么恭喜你，你已经有了第一个正式的中台项目。
接下来就进入了D4的第四个阶段，也就是最后一个但可能也是时间最长的交付阶段了。
而交付的第一步一定是要组建一支有战斗力的队伍，中台的建设需要的能力与传统产品还是有比较大的差别。给你分享一个孙志岗老师的中台人员能力模型，我认为非常有启发，希望也能帮助你理解中台对于团队能力的要求。这个模型孙老师写过一篇文章，文章中还提到了中台建设过程中一些难点，我会把文章统一放到最后一篇总结中作为扩展阅读推荐给你。
模型中的“爱多思”指的是网易教育中台。
当组建了一支成型的中台建设团队之后，其实后续的建设工作就和我们一般的项目或产品的建设过程类似了。但是因为中台所处的特殊位置，对产品界定要求和对建模的难度，都比其他终端产品的复杂度要高一个级别，所以我们建议采用精益的产品研发流程，保持小步迭代、快速建设、快速度量、快速反馈、快速调整的流程，保证中台建设是一个持续演进和被业务驱动的过程。
精益产品研发流程
这里叫精益产品研发流程，主要是面对中台建设过程中的不确定性，引入精益思想来实现价值的定义和快速流动及度量，再结合敏捷开发实践，让整个软件开发过程轻量、迅速、敏捷、价值驱动。
精益这个词相信你应该并不陌生，上一讲我们讲到的MVP就来自于精益创业。市面上大家还经常提到精益软件开发、精益生产制造等等，本质上都是将精益思想作用于某一个垂直领域的成果。
精益思想之所以流行，关键在于其定义了一套完整的思想框架，而最终核心目标就是消除浪费、创造价值。在中台的实际建设过程中，我们也建议引入精益思想，结合到软件的开发过程中，小批量快速开发产品，快速引入度量，基于测量的数据快速对于之前的需求假设进行验证和认知，并基于此做快速的调整。
这里你可能会有个疑问，敏捷和精益到底有什么区别？
其实精益和敏捷现在确实是常常掺在一起来讲的，我发现很多时候大家并没有搞清楚两者的区别。简单来讲，敏捷关注的是价值确定的情况下，如何通过小步快跑的迭代方式按节奏交付价值；而精益关注的则是在价值并不确定的情况下，如何用最小成本，快速定位到真正价值点。
我们发现，由于中台建设的复杂度非常高，所以将精益思想结合敏捷思想应用到中台的建设和开发过程，再配合后边马上会谈到的中台运营机制的建立，可以让我们更好地应对中台建设过程中的各种问题，例如最经典的中台边界界定问题。
至于我们具体的做法，你可以参考下图，其中涉及的工具和实践都是比较成熟了，这里就不做展开了。其中最主要的就是通过数据运营，也就是基于度量指标的持续验证，来对之前做的需求价值假设做快速验证，并且不断调整，在精益思想中就叫尽善尽美。而团队要做的就是不断地加速这个反馈环路的运转速度。速度越快，我们应对不确定性的能力就越强，交付中台产品价值的能力也就越强。
当然整个过程是一个复杂的系统性工程，一般都会涉及到像云化工程，微服务及服务化能力构建，Devops相关能力构建，数据运营能力构建，敏捷精益过程改进，遗留系统服务化改造，架构守护与演进，以及与中台相关的治理与运营架构构建等工程。
中台的运营、治理与演进
除了中台的建设过程，同样不能忽视的就是对于中台建设过程中的持续治理及演进，以及真正接入了前台之后对于中台的运营管理。
目前市面上我们碰到的很多中台建设过程中的困难和问题，在我看来都是没有做好中台的治理与运营导致的。对于中台的整体治理和运营机制，目前业界的理解也不太一致，毕竟中台作为一个企业的平台类产品，服务的不是企业的最终用户，所以和互联网里经常提到的基于产品的用户侧运营还不太一样，中台在位置上更像是企业内部的一个服务企业前台应用的ToB产品。
而对于企业内部的toB平台类产品如何做运营，也是目前业界比较关注的点。今天我就讲几点我认为比较关键的部分，注意这几个问题，能让我们在中台建设过程中少走一些弯路，少遇到一些坑。
而第一步要搞清楚的，就是中台产品的用户划分。
看到这里相信你肯定会疑惑，中台作为企业内部的平台类产品，所有的前台都应该是中台的潜在用户，尤其又都是自己企业内部的兄弟部门，为什么还要为前台用户做划分呢？
这就是有意思的地方，也是我在过去中台建设过程中吸取的教训。一开始我们在中台建设过程中，也并没有对于前台做任何划分，一视同仁、平等对待。
但是中台作为一个公共服务部门，一定会碰到多个前台的需求、排期、质量要求、非功能需求出现不同的情况，甚至也会经常出现多个前台之间的需求或是非功能性需求彼此矛盾的时候。而中台的资源有限，且有自己的愿景，不可能无条件地满足所有前台用户的诉求，往往就会陷入疲于应对的状态，对前台的响应和服务质量也会急速降低。
怎么办呢？问题的根本在于，虽然我们说中台是企业级能力复用平台，但我们经常会忽略的一点就是，如果我们采用产品化的思维来构建中台，那中台中所沉淀的能力并不是产品的全部，还需要再加上NFR（非功能性需求）或是我们常说SLA（Service-Level Agreement，服务等级协议）才是产品，因为不同的前台用户之间，不只是对于中台产品的功能本身有着不同的诉求，同样对于NFR或是SLA也有着不同的诉求。简单举个例子，比如核心业务对于中台的SLA稳定性的要求可能是5个9，性能是5毫秒；而一个新的创新型应用，可能还没有用户，就不需要有这么高的要求。
Offering = Capability + SLA/NFR
既然如此，如何利用有限的资源，服务好不同用户的不同诉求呢？答案就是对于前台用户基于需要的能力和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级用户开始第二轮中台建设的推进。
至此，通过中台的用户分层和运营机制，就可以构建不同层次的运营体系，从而实现资源的合理调配。我们也就避开了前面提到的中台建设过程中的各种问题和陷阱，对用户分级运营，从而解决需求矛盾、排期冲突、资源紧张、推广缓慢等问题。
总结思考
本次课我们从一个中台项目的启动开始，引入了精益产品研发流程，把精益思想和敏捷实践结合到中台的研发建设过程之中，加快价值流动、快速反馈、快速调整，从而更好地应对中台建设过程中的复杂度和不确定性。
之后我又给你分享了中台建设过程中的运营与治理机制。我并没有深入到运营机制的细节之中，而是从整体思路上，强调了如何对用户进行分层治理，合理调配精力与资源，通过用户的分层SLA机制来实现中台建设的平滑推进以及产品化演进。
所以，最后还是要强调一下，中台建设的过程是一个长期且艰苦的过程，不但需要企业具备技术、业务、组织的基础，还需要做好持续探索和演进的决心、耐心和准备。
最后给你留几个思考题：
- 你所在企业的中台建设过程是什么样的？与文中提到的方法有哪些相同和不同呢？
- 你所在企业的中台运营与治理机制是什么样的？有没有做用户划分？是不是存在文中提到的一些需求排期冲突、资源不够、响应变慢等问题呢？
期待你在留言区分享自己的案例和思考，也欢迎你把今天的内容分享给身边的朋友，我们下一讲见！
- 毛毛 👍（12） 💬（1）
1.把用户分层，这样会让3级用户的高优先级需求得不到及时响应。如何解决 2.文中公式的capability的高低如何评判，需求带来的收益？需求实现的难度？
2019-09-25 - wangfangyi@微信 👍（5） 💬（2）
专家，您的听众有很多小白，可以说是中台领域的小孩子。但是专家，您的课听完了，我还是不知道中台长啥样。 必须有感性的认识。需要形象的告诉我大象就是大，老鼠就是小。 不能只描述怎么是大，怎么是小 希望再增加一节课。举一个形象例子，展示中台的典型模样。
2019-10-25 - 钱 👍（14） 💬（8）
😂阅完后，已不知老师在讲什么，应该是认知层次还没到，作为技术人员核心关注的是一个东西的原理是什么？怎么实现的？有几种实现方式？那种方式是最佳的？关注的东西范围不是特别大，一个人也能搞定，不过项目管理或者一个企业级的项目从0到1，涉及多个核心业务线，需要的知识就不仅仅是技术了，沟通能力、项目推进能力、跨部分协作能力、撕逼能力、甩锅能力、向上向下管理能力一样都不能少，建设中台除了这些还需要敏捷思维、精益创业、DDD、持续跟进、产品推销、团队建设等等能力。 由于目前还不是管理者，有些高层会议未曾参加，知道的信息也是上级传递的，我在我司的中台建设中主要是负责好自己的一亩三分地，核心能力是业务熟练度+技术实力+产品思维，所以，理解整个中台是怎么建设的估计有些吃力也在情理之中。
2020-02-06 - . . 👍（2） 💬（0）
中台建设，小步迭代，敏捷快速见效
2020-03-30 - Alex 👍（2） 💬（0）
内部用户分级，有点内部市场化的意思。不同等级的用户给与不同的服务。当然客户付出的成本也不一样。前台就是中台的客户。用内部市场化的角度更容易理解。
2019-10-15 - 亚东 👍（2） 💬（2）
敏捷说的是开发过程，是对开发人员，工程人员。精益讲的是产品人员，产品经理。
2019-10-09 - 下一道彩虹 👍（2） 💬（0）
应该是第七遍读了。给我个人的感觉D1-D2-D3做的是同一件事的三个不同层次或粒度。D1是个免费版，发散让一般人收不拢；D2是个普通咨询版，能收拢但只解决到架构层次；D3是个包含线上某些服务的咨询版，可以发散到设计中了。 因为各中台需求不同，通用性中台落地方案不好再深入讲下去。 王老师，我知道这样理解可能有失偏颇，但脑袋还是忍不住这样去归纳。。。
2019-10-09 - 三生 👍（0） 💬（0）
这样用户划分之后确实服务了核心业务，但是同时也会导致其他服务接入的复杂性，造成业务脱节，后续支持接入后又会造成迁移，实际还是业务紧急但是无法快速响应并且需求把控调度都比较复杂导致。
2024-07-28 - zhou 👍（0） 💬（0）
我们建设中台没有做用户分层，但大体思路差不多，先找到种子用户，然后配合建设，建设完成后，等级降低后，培养下一个种子用户，
2022-07-14 - 有恒 👍（0） 💬（0）
中台是tob平台，不面向最终用户，三层用户分类的思想，受到启发。
2022-04-05 - Ngzhilin 👍（0） 💬（0）
看到这，觉得作为中台建设的牵头人，沟通能力是最为重要了。
2021-12-01 - 风 👍（0） 💬（0）
老师，如果企业要建设中台，就必须要与服务的用户划分清楚，要使用中台服务就要付出资源或者资金吗？如果前台觉得中台服务还不如自己搞，那中台服务的建设会不会更难推动？
2020-11-07 - 小炭 👍（0） 💬（0）
中台建设对于技术的能力要求其实没那么高，反而对于业务架构方面的能力有很高的要求。
2020-11-07 - 亚东 👍（0） 💬（0）
我感觉中台一定要云计算化，这样才能实现产品化。弹性是非常重要的。
2019-10-09