产品犬校有同学提问：对于中台产品，经常会需要与上游业务产品讨论边界，中台有现成的通用能力，但是业务希望定制。某个功能谁来处理、某个信息上游是否需要感知 etc.
举例：
支付中台有静默代扣能力，但是业务希望指定扣款顺序。于是讨论中台应该修改其封装的能力，或是提供原子代扣能力让业务层自己调度。
风控中台有通用的决策能力和审核能力，但是由于审核会涉及到不同的业务流程，于是讨论风控中台是否应该剥离审核模块、由各个业务系统独立完成。

我自己的思考是，
1.从实现层面考虑：这个需求，是否能被抽象成中台能理解的逻辑？如果不能被抽象，必定依赖其余的业务逻辑，那应该就是业务系统自己做。
2.从拓展性而言，这个需求对于中台的通用性程度有多高，是否应该被泛化为中台通用能力以复用？
3.判断当前需求，由业务侧承担的实现难度有多高。
坦诚地，因为自己是作为中台产品的角色，我自认为主要受不安全感驱动，在模糊的边界地带打架时，总是希望把自己的产品做得大而全，反感提供原子能力，怕失去「往前走」的机会。但是自己也知道这个不利于系统拓展、维护以及整体的产品架构。但是一直没有很清晰的方法论去指导自己的判断原则。
另外就是这样的讨论经常非常细，且极容易深入技术层面，很多时候回头来觉得这种讨论没有多大产品价值有点浪费时间。
因此想请教群内的各位，自己作为中台/业务对接上游/下游时的思路。

避免重复建设、重复开发

就拿第三方支付举例，现在市面上常见的第三方支付公司由宝付、连连、通联、银联电子、京东支付、快钱、微信支付、支付宝等。如果没有中台的时候，A业务线需要第三方支付的时候，需要自己把上述的支付通道对接一遍，并处理好各种异常场景和逻辑，还有对账、差错处理、退款等；B业务线需要第三方支付的时候，也需要把上面的工作重新做一遍。

这个时候中台的价值就来了，对内统一封装支付能力，包括主动支付、代扣、协议代扣、代付、退款等，提供「原子接口」接口供内部业务部门使用，对外整合各家支付通道能力，结合支付成本、可支持银行、支付能力等做路由管理。

但是上述能力，需要一次性全部开发完成么？不需要！

我有一个简单的判断原则就是：业务是否需要。业务都不需要的能力，我做出来给谁用呢？

中台产品的角色说尴尬也尴尬，说不尴尬也不尴尬，既然公司有这个岗位和分工，那么各个业务线都依赖你，但是如果你提供的解决方案或者能力，满足不了业务部门的需求，那对方就有可能考虑另起炉灶或者自力更生。

作为中台产品，我给自己的角色和定位就是「乙方」。

专业能力需要由专职团队提供

一个完整的风控中台系统包括：授信风控（授信准入、授信额度、风险定价、授信反欺诈）、贷中管理（交易风控、交易反欺诈、额度管控、定价管理、贷中预警）、贷后管理（分案策略、催收评分、渠道策略）。
这么复杂的事情，是需要有专门的风险团队负责整体的风险管理工作的。

不知道为啥Patrick公司内部为啥冒出来拆分到各自业务线去完成审核的想法，但是从风控角度来说，不管是什么样的业务流程或者业务形态，需要风险介入管控的时候，根据各自业务流程在关键节点介入即可。同样风控中台提供相应的「原子接口」即可。

提供灵活、便捷、稳定的服务能力

既然中台作为「全村的希望」，稳定肯定是第一原则，一般都是99.99%可用性。
然后对外提供的能力，其实更多是以API接口形式为主，所以对中台产品来说，具备一定的技术背景、逻辑思维、抽象能力都有助于更好地理解业务、归纳总结经验优化中台方案。
比如说我在前东家从0到1搭建设计的风控系统，不光是梳理主要的业务流程图、业务系统调用逻辑、顺序，数据上报、回传逻辑等，连接口文档都是我定义的，包括加密加签方式、各个接口的字段清单、报文格式、字典表等。

以上是我做中台跟业务上下游对接的一些经验分享，做了这么多年之后，我从来没有「不安全感」，反而是越来越坚信一个好的中台方案可以节省业务的成本、提升整体效率的，这也是中台的价值和魅力所在。

中台的服务能力

我现在的思考方式其实是放弃了提供大而全的服务能力，改为尽量支持90%的业务免研发接入（提供封装服务）、同时支持10%高度成熟复杂的业务调度接入（提供原子能力）。

这个思路没有问题。不过在评估需求优先级的时候，对中台来说，我评判标准是：合规需求 > 老板需求 > 业务规模 > 定制需求 > 通用需求。

关于这几类需求，我做点解释：

• 合规需求：信贷业务，合规需求肯定是第一优先级的，如果业务本身有合规性风险，那整体的可行性就大打折扣了，所以一旦出现合规性问题，都得第一时间解决，这是所有业务的基础，不然哪怕是10亿、100亿、1000亿的业务，最终都归于0，比如说之前的P2P业务；
• 老板需求：老板亲自指示提出的需求，也许本身价值不大，但从长远利益或者公司规划战略角度上来说，有深远影响；或者说就是业务部门求情走后门之后，需要开个直通车等等；
• 业务规模：当没有前面两种因素的干扰后，那就公平起见评判需求，比如说A业务线现在每日有10亿放款，B业务每日只有100万放款，两边都给中台提了需求，此时不用想肯定优先支持业务规模大的需求，不然老板就得弄死你。当然不是说100万业务的需求就不重要了；
• 定制需求：中台功过均在此，前期规划再合理或者再全面，但是事与愿违或者业务本身发生了变化，原有的方案无法支持新的业务形态时，需要定制需求；要么业务部门继续按照原有方案硬兼容，要么中台积极配合改造，在这一步如何处理这类需求就决定了中台口碑的好坏了；
• 通用需求：这种需求就是共性需求，各个部门都需要，但是实际上要支持共性需求，可能需要花费的时间和成本都非常高，业务部门等不及，只能先通过定制需求临时方案解决，业务上线后再迭代更新用更好的方案替代。

另外，我说的「乙方」，其实是一种心态。这就是涉及到你说的「边界」问题。

作为乙方，肯定是要满足甲方爸爸的需求，但是也要考虑自身能力和资源的实际情况，说白了这里面就看公司对中台的定位以及你自身的实际情况而说了。如果你觉得做起来太麻烦或者不想做，那就甩回业务部门，如果你觉得有必要或者有价值，不管该不该你做，都可以拿过来。

中台的抽象难题

先说一个结论：中台部门肯定是全公司最熟悉业务的部门，没有之一。

因为每天都有各个业务部门给你提需求，中台作为信息流的汇集点或者说关键点，要做到对各个业务熟稔于心。
要问怎么了解业务，那就是让各个部门给你提需求之前，介绍一下业务背景、业务流程、业务规划及预期等，这就是中台逐步积累和成长快的一个点，相比起业务部门，各自只了解自己手头上的业务，对其他业务知之甚少，但中台就不一样了。

中台可以接触到所有业务，在这个角色上需要有更开阔的视野和心态去面对各种挑战，以及深刻理解业务需求。

中台方案越完整、这时候越不具备拓展性；越需要具备通用性、中台方案越碎片化原子化。

关于这句话，我先说一下我的理解，光从字面意思，感觉咱俩的想法有偏差。

先说一下「完整性」，我理解的是越完整的方案，自然就不需要拓展了。该考虑的业务场景都完备了，那需要拓展啥？不知道你想描述的是不是「耦合」。
举个例子，就拿你熟悉的第三方支付里面常见的绑卡、还款支付流程来说。

常见业务流程：提供绑卡能力（传入四要素-下发验证码-鉴权通过-绑卡成功），提供还款能力（主动还款（需验短/不需验短）、到期代扣）。

这个时候就有不同的中台方案了，比如说绑卡的请求入参：
A、传入用户唯一编号、银行卡号；
B、传入用户唯一编号、银行卡号、银行预留手机号；

A方案就默认用户注册手机号=银行预留手机号，不支持用户有多个手机号的场景；B方案则支持绑卡时提供其他手机号；但A/B方案都有一定的业务背景存在，不一定B就比A好，具体还得根据内部实际情况而定。

然后绑卡接口的返回参数也可以有N种方案，这里我就不展开讲了。

说到怎么做的实操技巧，我有个经验就是「做局部最优解」。面对未来不确定性、当前时间紧迫性的情况下，如果想不出来更好的方案、或者更完美的方案需要更长的时间或者资源去满足时，那当前能快速解决实际问题的方案就是好方案。

所以当我遇到这种场景时，会给业务部门画个饼，当前情况我们先按照A方案协助业务快速上线/解决问题，虽然此处会留个坑，但影响不大，后续B方案出来后可以一劳永逸解决此问题，业务部门再配合改造等等诸如此类。

中台产品经理的价值

我从16年开始做中台产品，后来又做更复杂的风控产品，到现在做业务产品（更偏商务一点）。

我还记得当年刚开始做中台的时候，完全是一脸懵逼，直属领导是CTO，对我定位就是中台产品，说在阿里有一种Title叫做「业务架构师」，职责就是从更高的层面规划整体产品形态以及业务分工等，这既要求有一定的技术背景、又要求有足够的业务知识，而当时我的短板就是不熟悉业务。

经过这么多年的积累和学习，从业务层面来说，我已经能够很熟练地去拆分一个业务的各个模块，搞清楚整体业务流程以及各自的边界及分工。

这就是潜移默化的成长，而我的心态就是「多学点，总没坏处」，另外「别对自己设边界」，这里既是自己工作内容的边界也是自己未来发展的边界。

比如说我们梳理一个业务逻辑，需要用到的工具就是【泳道图】，想画好泳道图的前提条件就是对业务细节和角色、系统分工足够了解和熟悉；比如说接口对接层面的各种顺序和判断，我们就需要用到【时序图】，但这个对技术知识上会有一点挑战，如果你去了解一下，其实并不难，但如果你能把这个也画出来，在需求评审上研发肯定会更尊重你一点；业务逻辑上，如何判断，通过什么来判断，如果你能读懂上下游的接口文档，搞清楚这些逻辑，甚至当你能自己定义这些字段或者逻辑时，是不是能力上又上了一个台阶？

当然你也可以说，这些事情交给架构师、研发去做。但如果你多做一点呢？价值和意义不就体现出来了么。