备注：文中所述的中台，特指电商业务中台。
一、“屏障”思维的由来
回顾当时的中台内外环境，正如上边图中描述的那样。
因为中台在此之前，一直处于在能力建设和项目集中攻坚的阶段，对公司对业务我们的交付原则是先有后优，导致中台在内部建设投入的资源几乎为0。
这种现在回想起来，只想别人不想自己的做法，其实是我的一个失误。
因为问题集中爆发，不仅导致了中台内部的并发事情压力很大，同时业务对中台评价负面也让大家情绪很低。
二、定位问题与解法
面对以上状态，其实感官上我们都能知道有很多问题，但是我们还是想要比较系统化地全面定位下问题。
于是，我们开始了较大范围的内部产研访谈和外部反馈收集。
我们将问题归纳分析之后，按照以中台为中心，大概有3个大的交互角色：上游业务方、终端用户、下游业务方。
接下来，我们分别展开讲解：
1.上游业务与中台之间
1）问题：沟通成本比较高，交付质量与效率低，对接感受不太好
经过深层次的分析，我们发现沟通成本高，是因为我们面向的沟通节点太多，画了一张图：
中台面向的上游业务有很多，而中台子域也有很多。它们之间的信息往来，基本就是以上杂乱的线条。
站在业务视角，中台纵深逻辑复杂以及横向联动性强，造成每个业务需要与中台多个人进行沟通，并且可能前后反复，对接效率降低；
站在中台视角，每个子域，都会同时遇到有多个业务方与他沟通，响应质量变差，更别提能够前置去了解业务动态，做动态预留和架构设计了。
于是，就形成了整体沟通成本高，对接感受差的结局。
2）解法：中台BP机制&中台平台化系统建设
面对以上2个问题，我们找到了2个解题举措：
第一个，是减少沟通节点，进而提升整体沟通效率，即形成“BP机制”的屏障。
第二个，是减少非必要沟通，让系统沉淀取代人，即形成“平台化系统”的屏障。
①重构沟通协作节点
从业务视角来看，如何减少我的沟通节点呢？答案是一对一服务。
其实就是中台BP的概念，这个BP概念其实很多人可能一点都不陌生，公司内很多部门也基本都设置有BP角色，例如hrbp、财务bp等。
中台面向业务设置BP，应该能解决业务与中台沟通1V1。但中台与hr、财务还有一点不同，那就是对内对接成本也很高，因为中台内部各产品域其实专业跨度非常大，例如支付、财务、物流、营销等等。
所以，对业务的BP（第1重身份），有时候可能很难做到内部全局cover。那怎么办呢？只能设置项目产品负责人（第2重身份），来具体横向协作中台内部各域的产品实现。
以上BP的设置，并不代表要新增人员，而只是让人具备多重身份而已。
加上中台自身垂直方向，产品天然的岗位职责（第3重身份），一个中台PM可能最多会具备3重身份，画个图：
图中，大家能很容易看出来，业务与中台内部各域的关联关系，由之前很杂乱的状态，变为了以上较为有序的状态。
在协作中，角色职责清晰，整体对业务大体做到了1V1。
当然，这个要想完全做到很完美的状态，几乎不可能。因为对中台产品的要求太高了。
既然对业务的良好理解做到超前判断，又要对内部全域系统做到全面了解，还有对上对下的强大沟通协作能力。
下图中，大家感受下大中台产品域的分类：
能胜任以上多重身份的人才，我们称之为“业务架构师”。
不过，这个也是过去在实践中，得到的唯一最优解。我们只能不断完善和迭代，多多培养这样的人才出来。
②系统代替人：减少成熟场景下人的参与
以上BP机制，我们解决了信息流转节点杂乱的问题。
对业务对接成本和效率来讲，确实有了很大的提升。
但是，大家对中台产品来讲，从一个需求到落地，中台所做的事情比之前应该是没有任何减少的，甚至还由于身兼多重身份变得更多了。
所以，做到节点有序和减少还不够，还需要让信息流转的次数变少和流速变快。
那怎么做呢？
分别是：规则中心、配置中心、开放平台、综合查询，我对它们也都有详细的描述，见下图：
其实，以上系统的核心，就是将重复的事情结构化，变为系统化，然后在业务与中台之间建立漏斗。
一方面，可以让业务自助解决一些问题，这样信息就不用穿透到中台。如开放平台、规则中心、综合查询。
另一方面，通过系统化的方式，让实现一个需求的过程变得有指引有配置，速率提升。如配置中心。
当然过程中，我们还做的有后台系统统一导航、中台对接人导航等等，道理也是类似。
2.端用户与中台之间
业务与中台之间的矛盾解决了，中台产研面对另外一类用户也会遇到难题。
因为这些用户就是我们的终端用户，即服务的线上C端买/卖家（回收会有C1卖家）和B端商家，还有一部分是线下作业人员（例如仓储物流等）。
相对业务方这一内部项目需求用户来讲，终端用户遇到问题一般都是紧急的线上问题，要求要及时响应。
1）问题：用户穿透到中台产研，没有缓冲层，造成热点严重
中台本身提供交易能力，横跨用户交易的全部生命周期。一旦遇到问题，跟中台的关联度是极大概率。
而中台本身的产品资源是稀缺的，我们有的岗位基本就是1个人，甚至半个人。
那么，就很容易会产生严重的热点问题，导致产品精力受到牵制，会关联影响其他更多的事情处理效率。
一段时期内，中台各个方向的PM，基本都是以上的状态，99+的消息铺开全屏幕，天天看消息看不过来。
2）解法：引入产品运营角色，工具赋能给运营
从中台产研视角来看，如何减少咨询和干扰呢？
面向以上问题，我们找到了解题思路：
就是必须在组织层面增加节点，招聘产品运营角色，形成“缓冲区”的屏障。
产品运营角色，需要发挥2个作用：
一个是由外到内，起到收拢信息、过滤信息、转化信息的作用，提升产研处理信息的有效性；
另一个是由内到外，起到沉淀解决问题方法、宣导培训用户的作用，提升上游自助解决问题，减少问题到中台。
另外，除了解决线上问题之外，产品运营角色还会牵引各种对接sop的建立，让问题流转机制趋于更加有序。
过程中，产品需要花费一些资源，做一些小工具，赋能给运营，提升解决问题的效率。
3.中台与下游（非生产系统，如客服、大数据、财务）之间
以上中台打交道的两类用户，其实都会比较显性，在交付上一个是“最重要”业务方，一个是“用户第一”的用户。
那其实还有一类用户，我们会较难注意到他们，因为他们属于非生产系统，一定程度上不会影响用户交易进程。
但是，他们确实也服务着公司内部很多中后台的业务用户。例如，客服、大数据、财务等。
那中台与他们之间会存在什么样的问题呢？
1）问题：中台业务数据分散，会造成下游与上游业务多点对接，成本高，数据统一性差
因为处于下游，很多时候，他们没有太多话语权，所以过程中，慢慢也就会接受了很多现状，不向上游提需求或提需求上游没空“搭理”。
以上造成最直观的结果，就是下游需要兜底中台没有封装掉的业务场景，需要一对多去进行解决问题。
画个图，大概就是这个逻辑：下游业务需要对接除中台之外，还需要跟很多业务个性化信息去做识别和交互。
那这时候，下游各个业务的实现成本，其实是比较高的。
2）解法：中台核心数据分散问题统一化
那怎么办呢？还是用我们的屏障思维来解题。
即中台数据统一化项目，将下游业务依赖的发散场景收敛到中台，由中台与下游一对一交互。即形成“数据统一化”的屏障。
画个图解释逻辑如下：
在这里，中台用框架包住了业务个性化的触点，逻辑还是个性化，只是不对下游感知了，中台变为了和下游对接的唯一触点。
到这里，我们将中台对接的3类用户，所遇到需要建立屏障的情况做了详细说明。
总结一张图，便于大家记住。
到这里，就是我过去在中台建设实践中，关于“屏障”思维的一些思考。
其实，也都不是很多东西一开始就能想到，而是遇到问题一点点去解决，后续慢慢形成的归纳总结。
见招拆招，只要一心去解决问题，就必然会有所悟、有所得。
本文由@减形简远原创发布于人人都是产品经理，未经作者许可，禁止转载。