我15年初加入阿里的前半年，观察到当时的交易平台已经无法很好的对业务进行敏捷支撑：人手不够，加班严重；排期时间很长，经常延期；共建机制，协同困难等问题。本文是在当时背景之下，提出中台概念以及构建TMF2.0框架之前，所记录我观察到的问题和一些初步想法。

一个平台是否成熟有很多的考量指标，比如平台是否稳定、是否易于扩展、是否能很好的支撑业务等。在我看来，平台对业务是否支撑得好不仅仅要看平台对成熟、复杂业务是否支撑得好，还要看对于新小业务是否支撑得好。对于一个高速发展的行业，每年甚至每月都有创新型业务要发布上线。如果平台的准入门槛很高，每个创新业务都需要花费大量的研发、集成、调试的时间才能运行在平台上，很可能就会失去宝贵的机会窗口。

平台不仅仅要对成熟业务做支撑，同时还要能更好的支撑新小业务的快速试错

新小业务都有一个成长规律，在早期业务模式验证阶段，需要的玩法比较简单，希望能频繁的发布快速试错。我们以电商领域为例，在成熟的电商体系下，有众多复杂、庞大的平台，如交易平台、商品平台、营销平台等。虽然这些平台对于天猫、淘宝各种业务模式、玩法都支撑得很好，但对于新小业务而言，这些模式、玩法在早期并不适用，他们希望平台能按照自己的要求做一些裁剪。

我们以“汽车金融”这个业务为例，该业务在最初概念试错的几个月，不需要提供优惠券，并且也不涉及到实物物流发货过程，也不涉及到金本位相关的资产相关的内容。他希望能够在早期快速的迭代并能做到自主发布，而不是跟随平台每周一次的发布节奏。但这种非常合理的要求在早期交易平台上都难以得到满足：

  • 早期的交易平台的下单流程是硬编码方式写死的。整个流程，无论什么业务，都必须要与优惠系统、物流系统、卡券平台等系统对接。新业务开发时，必须要确保整个下单过程与这些服务的集成不会出现调用异常，一旦有异常出现，就需要与相关系统协调看如何屏蔽错误。
  • 商品单价计算逻辑也没有很好在平台中得到解耦，也没有提供可扩展机制。汽车金融业务的商品单价是来源于支付宝的微贷系统。最终，该业务也只能以硬编码方式，在平台计算商品单价的地方，与其他业务的代码混在一起去编写相关计算逻辑。这部分代码因为可能会影响到其他业务，所以代码在发布上线前，必须经过严格的全网回归验证，以确保不会对其他业务产生影响以及资损。
  • 汽车金融业务的发布节奏因此也必须跟随平台版本的节奏，只能耐心的等待每周一次的全网回归验证后，才能进行发布，无法按自己的意愿随时发布。

汽车金融业务团队的技术人员不清楚各平台的实现细节，他们认为这些平台是成熟的、强大的，这些需求应该是很简单，应该一两周就可以集成完毕就可以发布上线的。但最终经过业务与平台团队的反复沟通、需求澄清、方案评估后，才发现之前认为“理所应当”就可以支撑的功能，原来都是不确定或者是不支持的。计划也从之前的一两周变成了至少需要三个月，工作量也从之前的2人周变成了4人月，而之前业务上承诺交付时间也已迫在眉睫……

这样的故事每天都在重复，平台如何才能不成为支撑业务团队的瓶颈，关键在于：

  • 平台的能力是否可以外化并暴露出去，各行业的业务团队能清楚的知道平台具备什么样的能力；
  • 平台对外提供的可扩展性是否足够，业务团队能自助式无侵入式的进行业务逻辑定制
  • 各行业定制的业务逻辑，相互之间不能产生影响，能做到各行业的业务定制独自、自主发布；

平台需要能给业务在可复用模式上的支撑，助力业务的发展

故事一：一次产品和平台关于业务需求的对话

阿里的电商平台目前支撑了大量的垂直行业的业务，这些行业在交易主流程上大致相同，但在一些分支场景下又有自己的行业特色。曾经有个行业的产品跟平台的设计人员沟通平台是否能满足业务的诉求。

平台：“你们业务想做成什么样？需要哪些功能？有什么具体的场景、约束？”

行业：“嗯，我们业务没啥很特别的，我们的业务场景和规则和..嗯，和天猫超市基本一致，但在这几个地方有点差别...blablabla...”

平台：“......”

上面这段对话场景在业务团队和平台团队之间经常发生。当平台同学进一步细问：“你们和天猫超市究竟哪些场景是一致的？”这个问题时，业务团队往往也不清楚“天猫超市”业务究竟是如何的。

平台：“天猫超市的这段做过定制的业务逻辑，你们也需要吗？”。

行业：“嗯，这段业务逻辑，我不太确定，应该不需要吧”。

发现问题所在了吧，这个行业的业务团队只是看到天猫超市和他们有一定程度上的业务相似性，但天猫超市的业务模式、业务场景等，他们也只是了解一些外在的表现。

故事二：一次需求分析到上线的过程

我在刚加入到交易平台时，曾负责过一个需求，叫做村淘二阶段物流。这个需求大致是指将之前一些快递公司不能配送到村的订单都配送到县里的村淘驿站，再由村淘驿站里的村淘合伙人负责再通过二次配送，将这些包括配送的村里，同时村淘合伙人要收一笔二次配送的费用作为佣金。这个需求相比之前的交易履行过程有这些不同：

  • 物流配送分为两段，第一段是快递公司负责配送，第二段是村淘合伙人负责配送；
  • 物流总费用有两部分组成，一部分是付给快递公司的，另一部分是付给村淘合伙人的；
  • 一旦村淘合伙人开始配送了，配送服务已经生效，配送费用会打给村淘合伙人。后期如果产生商品退换行为，已经发生了的配送费用，村淘合伙人是不会退还的；
  • ……

这个需求的确不是很复杂，我跟着当时交易团队的师兄去参加需求评审会以及技术方案评审会。产品在介绍完业务需求后，师兄思考了一下，提到这个需求和之前做过的一个“运费险”的需求非常类似。比如，都是费用分两笔，并且一旦服务履行后就不退还；费用都是两个不同的收款方等等。然后，技术方案的结论是，该需求参考之前的“运费险”需求的技术方案。

产品很开心，师兄很开心，我也很开心。毕竟有个非常类似的需求已经做过了，技术上肯定可行，而且还可以参考，这个需求看来可以一周搞定。

在回到座位上之后，我开始打听之前的“运费险”需求是如何设计与实现的。突然发现，之前做“运费险”需求的主要设计师已经退隐江湖（离职）。之前参与过这个需求的其他同事并不多，而且也不太了解细节。最后能给到我的建议是“搜一下insurance这个单词，看下哪些地方代码有这个关键字”。最后事实证明，这一招也并不太管用，在交易下单系统中，我搜出了有2000多个有这个关键字的地方，经过检查发现大多数和“运费险”无关。而且，有些当时支撑“运费险”的服务已经被重构下线，被另外一个服务/系统所替代。

最终，我只能老老实实的回到原始业务需求，开始做场景分析、开始设计主要的实体对象、分析处理时序以及定义主要的上下游服务以及相关的接口参数。之前预估一周搞定的需求，最终是两个人做了一个多月。

与这个类似的故事，每天都在发生着。比如，天猫做了一个预售的玩法，国际化团队也希望在自己的平台上引入预售。最终发现没有其他任何成型、与行业无关并经过高度抽象可复用的程序包，只有一些原始需求描述文档可以借鉴，并基于这些原始需求文档重新做一次分析、设计、编码、测试。

所以，平台如何能够沉淀可快速场景级复用的资产，是助力新小业务快速敏捷上线的关键！