在入职公司前，笔者只知道产品分为B端C端、PC端或移动端等；入职公司后，才知道原来还有一种产品叫做中台产品，与前台产品、后台产品同属于一个分类。在查阅资料的过程中，笔者发现中台并不是今年才出现的概念，而笔者在此前作为一个产品求职者，却从未关注过，深感惭愧。
于是，笔者在边摸索边踩坑的状态中，开启了职业生涯之路，也在接下来的实际工作中总结出了关于中台产品的三个“要做”和“不做”。
一、要做通用能力，不做定制能力
故事发生在今年7月。彼时，笔者还是一名刚入门做中台的产品新人，进入职场仅一个月。
笔者所在的中台团队下，积分模块刚完成了服务升级，需要在公司范围内寻找相关团队接入中台，避免相同服务在多处维护，浪费人力资源。笔者的任务，就是引导业务团队A将原来的服务迁移至中台，由我们中台对积分模块进行统一管控。
在初步需求沟通过程中，问题很快就浮出了水面。在业务团队A原来使用的系统中，获取积分的途径是固定不变的，但是每次可获取的积分数量是可变的，且操作人员可以在前端展示页面中输入任意一个大于零的自然数，允许灵活修改。而在我们中台的积分模块中，获取积分的途径是代码里预置好的，每次可获取的积分数量及积分获取规则也是在代码里预置好的，这些数据均不能在前端展示页面中人为修改。
于是，业务团队A提出希望中台在页面中增加一个可配置的文本框，用于操作人员灵活配置发放的积分数量。由于缺乏实战经验，对于这个需求我迟迟拿不定主意，于是我找到身经百战的研发负责人，询问他的建议。
研发同学立刻听出了团队A的弦外之音，原来是想让我们中台给他们做定制化需求呢。于是当机立断，给出建议：我们中台不做定制需求，如果他们非要积分可配置化，那就先酱，再酱，最后再酱，OK。笔者表示感谢：原来如此，我本来还觉得他这个需求蛮合理，差点就同意了~
最后由笔者的leader牵头组了一个会议，业务团队A同意将原有的积分获取规则进行管理和整合，对于每次可获取的积分数量，也整理出一些可选值在代码中提前预置好，操作人员可以在这些可选值中灵活配置。
二、要做预处理，不做过度处理
在笔者刚入门做中台产品的时候，曾经做过这样一个需求。在电商订单盛行的当下，可能会由于运营配置错误、用户巧妙“薅羊毛”、被黑客攻击系统等原因导致积分不正常亏损，因此要对积分支付过程中可能出现的风险进行控制。
经过一番思想的碰撞，笔者最终产出了一份自认为比较完整的解决方案：
前台各业务端在系统中埋点，将用户的操作日志数据传给我们中台，中台自行落库得到日志数据库。
中台对原始数据进行计算，得出多个数据指标，这些数据指标大多是对用户的历史消费习惯进行概括，比如积分消耗区间、每次支付行为平均消耗积分数量等；已经计算好的数据指标用于支撑风险判断接口，以每次交易的基础数据作为请求参数，比如本次交易需支付的积分数量等。
接口逻辑大概可以归纳为：将历史消费习惯与本次交易做比较，如果本次交易的数据与历史消费习惯不符，则将本次交易风险等级置为y，需通过对应的校验才可继续完成交易。
但是当笔者与leader沟通想法的时候，却得到了leader“你还是不懂中台”的评价。
leader指出中台最多做到日志统计报表这一步就够了，而风险判断接口的各种判断应该由各业务端根据不同的应用场景，做差异化的处理和判断。
笔者幡然醒悟，中台产品对原始数据做预处理的目的是更好地服务各前端业务线，但忌过度处理，或是做了本该各业务线做的工作。
后来笔者查阅了很多文章和书籍，恶补中台的概念及设计思想，终于找到了比较合理的解释。
《中台产品经理宝典》一书中，作者将互联网公司的研发中心比作一个厨房，将研发新产品的过程比作做菜，从而将做菜这个过程拆解为：买菜、配菜、炒菜三个步骤。买菜小哥作为后台，为中台提供最基础的原料；配菜小哥作为中台，统一对菜做预处理，完成洗菜、切菜动作；炒菜小哥作为前台，则根据不同烹饪方式最终完成口味不同的菜品。
在这个例子中，如果配菜小哥不仅完成了洗菜、切菜的动作，还顺手完成了炒菜小哥的任务，则会导致炒菜小哥无任务可做，那么人员组织架构将会变得很混乱。
三、要判断需求是否符合产品定位，不要盲目接需求
中台向各业务团提供通用能力，目的是为了减轻各业务团的重复工作量，而不是为了减轻各业务团的工作量。要注意区分工作量和重复工作量，仅两字之差，其含义却相去甚远。
举个例子：
- 团队A需要开发功能模块a和功能模块b，最终得到一个完整的产品x；
- 团队B需要开发功能模块a和功能模块c，最终得到一个完整的产品y；
- 团队C需要开发功能模块a、功能模块c和功能模块d，最终得到一个完整的产品z。
那么功能模块a、功能模块c就是重复工作量，而剩下的功能模块b、功能模块d皆属于工作量，分别归属不同的团队。
笔者所在的中台团队下设不同领域的产品研发团队，分管不同的业务领域。
其中，在订单领域内，常常出现这样的情况：团队B需要与中台对接得到功能模块a和附加小功能e。功能模块a属于订单领域，由中台团队下的订单产研团队负责开发；而附加小功能e不属于订单领域，由中台团队下的其他产研团队负责开发。
由于附加小功能e的开发量比较小，团队B不愿意多对接一个团队，因此常常会有需求，希望订单产研团队直接开发功能模块a和附加小功能e，完成后对接给团队B。
显而易见，这种做法是不合理的。如果中台产品人将这样的方案推上需求评审会，不仅不会得到研发负责人的认可，还可能会被各位研发同事怼。毕竟，谁也不愿意做工作之外的工作，而我们产品人更不能因为自己身上不背负开发的重任，就随意接需求，把一堆额外的任务丢给开发。
更重要的是，作为一名中台产品人，把握需求的边界应该是我们的基本功~
四、写在最后
本文主要描述了笔者在真实的工作场景中遇到的问题，并从问题中归纳总结出做中台产品的三大原则。以上仅作为笔者的经验，供各位读者参考。而各位读者对于中台的思考，需要从实际出发、在实际工作中总结专属自己的经验，方可在中台领域内快速成长。
俗话说，读万卷书不如行万里路。对于刚入门的产品新人来说，不论看过再多道理、再标准的指导原则，也许都跟纸上谈兵无甚区别。实践是检验真理的唯一标准，关于中台产品到底应该如何做，相信一千个人有一千个哈姆莱特。
