极客时间已完结课程限时免费阅读

09 | 中台落地第四步：中台的建设与接入（Delivery）

09 | 中台落地第四步：中台的建设与接入（Delivery）-极客时间

09 | 中台落地第四步：中台的建设与接入（Delivery）

2019-09-25 王健 来自北京
《说透中台》
课程介绍

讲述：王健

时长13:29大小12.35M

你好，我是王健。
通过上一节课介绍的内容，我们最终拿到了一个作为切入点的中台场景，并且通过业务梳理识别出对于数据、流程、功能的复用需求，并结合 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 机制来实现中台建设的平滑推进以及产品化演进。
所以，最后还是要强调一下，中台建设的过程是一个长期且艰苦的过程，不但需要企业具备技术、业务、组织的基础，还需要做好持续探索和演进的决心、耐心和准备。
最后给你留几个思考题：
你所在企业的中台建设过程是什么样的？与文中提到的方法有哪些相同和不同呢？
你所在企业的中台运营与治理机制是什么样的？有没有做用户划分？是不是存在文中提到的一些需求排期冲突、资源不够、响应变慢等问题呢？
期待你在留言区分享自己的案例和思考，也欢迎你把今天的内容分享给身边的朋友，我们下一讲见！
分享给需要的人，Ta购买本课程，你将得9元
生成海报并分享

赞 7

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
08 | 中台落地第三步：中台的规划与设计（Design）
下一篇
10 | 总结：中台落地工具资源汇总
unpreview
 写留言

精选留言(13)

  • 钱
    2020-02-06
    😂阅完后，已不知老师在讲什么，应该是认知层次还没到，作为技术人员核心关注的是一个东西的原理是什么？怎么实现的？有几种实现方式？那种方式是最佳的？关注的东西范围不是特别大，一个人也能搞定，不过项目管理或者一个企业级的项目从0到1，涉及多个核心业务线，需要的知识就不仅仅是技术了，沟通能力、项目推进能力、跨部分协作能力、撕逼能力、甩锅能力、向上向下管理能力一样都不能少，建设中台除了这些还需要敏捷思维、精益创业、DDD、持续跟进、产品推销、团队建设等等能力。 由于目前还不是管理者，有些高层会议未曾参加，知道的信息也是上级传递的，我在我司的中台建设中主要是负责好自己的一亩三分地，核心能力是业务熟练度+技术实力+产品思维，所以，理解整个中台是怎么建设的估计有些吃力也在情理之中。
    展开
    共 8 条评论
    13
  • 毛毛
    2019-09-25
    1.把用户分层，这样会让3级用户的高优先级需求得不到及时响应。如何解决 2.文中公式的capability的高低如何评判，需求带来的收益？需求实现的难度？

    作者回复: 毛毛，你好~ 看的好快……对于第一个问题，3级用户因为付出的资源少，所以需求不如付出资源多的1级用户响应快，自然也能理解。 就跟我们坐飞机下飞机的时候一样，那些买了头等舱的自然可以比我们这些买了经济舱的先走一步，人家还多花钱了呢，那自然经济舱的人也能理解。 如果我觉得我的需求非常非常高，那也可以多花点成本，买张头等舱票，变成1级用户，这样就能享受更好的服务，这样大家就各取所需，根据成本和收益自己评估自己成为一个什么级别的用户。 不过原则是原则，具体实施的时候也有特例，比如万一我突发情况身体不舒服，或是有其他更紧急的事情，可能虽然是经济舱的，也需要先下飞机，这时候头等舱的人相信也能互相理解，灵活应对。 对于第二个问题，capability就是我们前边提到的能力，能力的高低本身其实很难判断，可以找一些指标，比如战略重要性，紧急程度，实现难度之类的。 但也可能根本也不需要判断，我们可以粗粒度的认为所有的能力都是同样的价值，靠SLA来区分Offering的不同。理解这部分可以随便开一个卖公有云的厂商，看看他们对于不同能力以及不同SLA的定价，感受一下他们是如何为capability以及Offering做综合定价的。 希望对你有所帮助~继续交流~

    12
  • wangfangyi@微信
    2019-10-25
    专家，您的听众有很多小白，可以说是中台领域的小孩子。但是专家，您的课听完了，我还是不知道中台长啥样。 必须有感性的认识。需要形象的告诉我大象就是大，老鼠就是小。 不能只描述怎么是大，怎么是小 希望再增加一节课。举一个形象例子，展示中台的典型模样。
    展开

    作者回复: wangfangyi@微信，你好~ 首先感谢你的留言，从你的留言里，我能感受到你的真诚和迷茫。 很多时候我们都希望能有一个直观的、清晰的、感性的认识，这也是我这几年一直在追寻的，也是困恼的。 但是直到现在，我觉得“中台”这个概念目前还没有一个具体而清晰的“形”，更多还是在“神”的状态，既有神而无形。 这一点在我的02中台的种类，或者你可以去外边随便搜一搜“中台”，就能感受得到。有人谈业务，有人谈数据，有人谈技术，每家中台的图画的都不一样，那到底哪个才是中台的典型模样呢？能不能找到一个中台的典型模样呢？ 别说中台，就连大家谈的最多的业务数据双中台，都很难说有一个典型的模样（如果非要找典型，估计也就算是阿里的业务数据双中台了，可以网上查一下，也很容易找到，但相信对你帮助也不会太大）。 那这个问题就变成，如果中台还没有一个具体的“形”，那其“神”有没有价值，我觉得是有价值的，也是我这篇专栏想分享的，中台各种各样“形”背后的神，既基于用户与创新的业务驱动的平台型企业架构（EA），说白话，就是我们虽然找不到一个唯一的“形”，但我们找到一个“能找到形的方法”。 而对于你提到的例子，这个我已经在思考准备了，如果有更新，我也会更新到专栏里，至少能让大家看到中台某一种具体形态到底是什么样的，应该也会有些帮助~

    共 2 条评论
    5
  • . .
    2020-03-30
    中台建设，小步迭代，敏捷快速见效
    2
  • Alex
    2019-10-15
    内部用户分级，有点内部市场化的意思。不同等级的用户给与不同的服务。当然客户付出的成本也不一样。前台就是中台的客户。用内部市场化的角度更容易理解。
    2
  • 亚东
    2019-10-09
    敏捷说的是开发过程，是对开发人员，工程人员。精益讲的是产品人员，产品经理。
    共 2 条评论
    2
  • 下一道彩虹
    2019-10-09
    应该是第七遍读了。给我个人的感觉D1-D2-D3做的是同一件事的三个不同层次或粒度。D1是个免费版，发散让一般人收不拢；D2是个普通咨询版，能收拢但只解决到架构层次；D3是个包含线上某些服务的咨询版，可以发散到设计中了。 因为各中台需求不同，通用性中台落地方案不好再深入讲下去。 王老师，我知道这样理解可能有失偏颇，但脑袋还是忍不住这样去归纳。。。
    2
  • zhou
    2022-07-14
    我们建设中台没有做用户分层，但大体思路差不多，先找到种子用户，然后配合建设，建设完成后，等级降低后，培养下一个种子用户，
  • 有恒
    2022-04-05
    中台是tob平台，不面向最终用户，三层用户分类的思想，受到启发。
  • Ngzhilin
    2021-12-01
    看到这，觉得作为中台建设的牵头人，沟通能力是最为重要了。
  • 风
    2020-11-07
    老师，如果企业要建设中台，就必须要与服务的用户划分清楚，要使用中台服务就要付出资源或者资金吗？如果前台觉得中台服务还不如自己搞，那中台服务的建设会不会更难推动？
  • 小炭
    2020-11-07
    中台建设对于技术的能力要求其实没那么高，反而对于业务架构方面的能力有很高的要求。
  • 亚东
    2019-10-09
    我感觉中台一定要云计算化，这样才能实现产品化。弹性是非常重要的。