热搜:


在入职公司前,笔者只知道产品分为B端C端、PC端或移动端等;入职公司后,才知道原来还有一种产品叫做中台产品,与前台产品、后台产品同属于一个分类。


在查阅资料的过程中,笔者发现中台并不是今年才出现的概念,而笔者在此前作为一个产品求职者,却从未关注过,深感惭愧。于是,笔者在边摸索边踩坑的状态中,开启了职业生涯之路,也在接下来的实际工作中总结出了关于中台产品的三个“要做”和“不做”。


一、要做通用能力,不做定制能力


故事发生在今年7月。


彼时,笔者还是一名刚入门做中台的产品新人,进入职场仅一个月。


笔者所在的中台团队下,积分模块刚完成了服务升级,需要在公司范围内寻找相关团队接入中台,避免相同服务在多处维护,浪费人力资源。笔者的任务,就是引导业务团队A将原来的服务迁移至中台,由我们中台对积分模块进行统一管控。


在初步需求沟通过程中,问题很快就浮出了水面。


在业务团队A原来使用的系统中,获取积分的途径是固定不变的,但是每次可获取的积分数量是可变的,且操作人员可以在前端展示页面中输入任意一个大于零的自然数,允许灵活修改。


而在我们中台的积分模块中,获取积分的途径是代码里预置好的,每次可获取的积分数量及积分获取规则也是在代码里预置好的,这些数据均不能在前端展示页面中人为修改。


于是,业务团队A提出希望中台在页面中增加一个可配置的文本框,用于操作人员灵活配置发放的积分数量。


由于缺乏实战经验,对于这个需求我迟迟拿不定主意,于是我找到身经百战的研发负责人,询问他的建议。


研发同学立刻听出了团队A的弦外之音,原来是想让我们中台给他们做定制化需求呢。


于是当机立断,给出建议:我们中台不做定制需求,如果他们非要积分可配置化,那就先酱,再酱,最后再酱,OK。


笔者表示感谢:原来如此,我本来还觉得他这个需求蛮合理,差点就同意了。


最后由笔者的leader牵头组了一个会议,业务团队A同意将原有的积分获取规则进行管理和整合,对于每次可获取的积分数量,也整理出一些可选值在代码中提前预置好,操作人员可以在这些可选值中灵活配置。


二、要做预处理,不做过度处理


在笔者刚入门做中台产品的时候,曾经做过这样一个需求:


在电商订单盛行的当下,可能会由于运营配置错误、用户巧妙“薅羊毛”、被黑客攻击系统等原因导致积分不正常亏损,因此要对积分支付过程中可能出现的风险进行控制。


经过一番思想的碰撞,笔者最终产出了一份自认为比较完整的解决方案:



前台各业务端在系统中埋点,将用户的操作日志数据传给我们中台,中台自行落库得到日志数据库。


中台对原始数据进行计算,得出多个数据指标,这些数据指标大多是对用户的历史消费习惯进行概括,比如积分消耗区间、每次支付行为平均消耗积分数量等;已经计算好的数据指标用于支撑风险判断接口,以每次交易的基础数据作为请求参数,比如本次交易需支付的积分数量等。


接口逻辑大概可以归纳为:将历史消费习惯与本次交易做比较,如果本次交易的数据与历史消费习惯不符,则将本次交易风险等级置为y,需通过对应的校验才可继续完成交易。


但是当笔者与leader沟通想法的时候,却得到了leader“你还是不懂中台”的评价。


leader指出中台最多做到日志统计报表这一步就够了,而风险判断接口的各种判断应该由各业务端根据不同的应用场景,做差异化的处理和判断。


笔者幡然醒悟,中台产品对原始数据做预处理的目的是更好地服务各前端业务线,但忌过度处理,或是做了本该各业务线做的工作。


后来笔者查阅了很多文章和书籍,恶补中台的概念及设计思想,终于找到了比较合理的解释。


《中台产品经理宝典》一书中,作者将互联网公司的研发中心比作一个厨房,将研发新产品的过程比作做菜,从而将做菜这个过程拆解为:买菜、配菜、炒菜三个步骤:


  1. 买菜小哥作为后台,为中台提供最基础的原料;


  2. 配菜小哥作为中台,统一对菜做预处理,完成洗菜、切菜动作;


  3. 炒菜小哥作为前台,则根据不同烹饪方式最终完成口味不同的菜品。


在这个例子中,如果配菜小哥不仅完成了洗菜、切菜的动作,还顺手完成了炒菜小哥的任务,则会导致炒菜小哥无任务可做,那么人员组织架构将会变得很混乱。


三、要判断需求是否符合产品定位,不要盲目接需求


中台向各业务团提供通用能力,目的是为了减轻各业务团的重复工作量,而不是为了减轻各业务团的工作量。要注意区分“工作量”和“重复工作量”,仅两字之差,其含义却相去甚远。


举个例子:


  • 团队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。


显而易见,这种做法是不合理的。如果中台产品人将这样的方案推上需求评审会,不仅不会得到研发负责人的认可,还可能会被各位研发同事怼。


毕竟,谁也不愿意做工作之外的工作,而我们产品人更不能因为自己身上不背负开发的重任,就随意接需求,把一堆额外的任务丢给开发。


更重要的是:作为一名中台产品人,把握需求的边界应该是我们的基本功。


四、写在最后


本文主要描述了笔者在真实的工作场景中遇到的问题,并从问题中归纳总结出做中台产品的三大原则。


以上仅作为笔者的经验,供各位读者参考。


而各位读者对于中台的思考,需要从实际出发、在实际工作中总结专属自己的经验,方可在中台领域内快速成长。


俗话说,读万卷书不如行万里路。


对于刚入门的产品新人来说,不论看过再多道理、再标准的指导原则,也许都跟纸上谈兵无甚区别。


实践是检验真理的唯一标准,关于中台产品到底应该如何做,相信一千个人有一千个哈姆莱特。