上篇文章我们聊到，中台并不是一开始就有的，而是系统为适应需求的快速迭代而产生的。具体来讲，中台其实是将系统的通用化能力进行打包整合，通过接口的形式赋能到外部系统，从而达到快速支持业务发展的目的。
那么，究竟怎么做做中台呢？从产品层面，中台本质上是将后台的逻辑层抽象出来的一种系统模块，其目的在于快速的支持业务发展，因此，个人认为，中台实际上是站在“快速响应需求迭代”角度的一种产品设计思维。
从实习至今，踏入互联网行业从事产品经理一职已有2年，复盘一下，最初自己的思维是“业务提什么我做什么”，伴随着不断的踩坑和公司的“中台化战略”，思维也逐步转变为“业务提的这个是要达到什么目的，其他业务会不会也有这个需求，它对商家，消费者及平台的价值分别是什么”。在此，把自己思维的转变和大家稍作分享，请不吝赐教！
在日常的工作中，尤其是在类似于京东、阿里、百度等这样的大厂中，每个需求涉及上下游多个系统，这些系统都分布在不同的事业部，因此带来以下众多问题：
1、系统复杂，无法快速拿出产品方案
2、多重对接，沟通成本巨大
3、系统间耦合性较大，牵一发而动全身
基本上因为以上问题，新的业务需求无法快速满足。当一个业务诉求牵涉到系统较多时，如果没有较高的可预期收益或者是政治类需求，基本上会被搁置甚至就此搁浅。
因此，作为一名合格的产品经理，从产品/系统角度，我们就需要考虑以中台化的思维去进行方案设计：
通用性
对于业务需求，要跳出需求看本质，理解业务方的真实需求是什么；要跳出模块看全局，理解这个需求的实现，除了对消费者、商家的价值，要看到它对平台的价值。
例如之前负责的订单导出功能，其实用户需求很简单：快速导出数据，进行业务分析，但是站在平台角度，平台富有对用户数据保护的义务，因此需要考虑从数据及用户层面做权限控制；同时也考虑到商家不仅需要导出订单，后续可能导库存、商品及其他业务数据，因此需要考虑产品的通用性，以降低后续开发的成本。
总之，作为平台性产品，要站在上帝视角来设计产品，这样才能“普度众生”。
结构化
在方案设计上，要做到通用性，需要将通用能力从解决方案中抽离出来，与业务场景进行解耦，从而实现“业务场景-通用能力”系统架构，
还是拿订单导出举例，刚开始设计订单导出时，权限控制，导出任务创建，导出数据下载，订单业务耦合，其他业务接入时费事费力，还有可能对现有业务产生影响。因此才将订单导出的通用能力从业务场景中解耦出来。
标准化
将通用能力与业务场景解耦只是第一步，我们要将通用能力进行打包，形成一套标准化模版，以接口化的形式赋能到外部的业务场景，供业务场景按照标准化的形式进行接入和开发，降低其他业务导出的开发成本。
以订单导出举例，我们将“权限控制”，“创建导出任务”，“下载导出数据”封装为不同的接口，形成导出中心，提供给不同的业务场景。
可拓展
到这一步，已经形成了“单通用能力对应多业务场景”的系统架构，若业务侧有定制化需求，可从业务场景角度进行单独定制，以致于不会对其他业务场景产生影响，也提升了定制化需求的研发效率。
小结一下：本周就先写到这里吧，下周写点什么呢？
