中台产品,要做什么不做什么?

21 评论 8163 浏览 29 收藏 11 分钟

#本文为人人都是产品经理《原创激励计划》出品。

不同产品具有各自的“能力边界”,作为产品人,你知道一款中台产品应当做好哪些工作、具备哪些能力吗?当面对需求时,你能否判断该需求应不应当开发?本文作者就结合实际工作经验,总结了中台产品的“三做”与“三不做”,也许可以解答你的困惑。

在入职公司前,笔者只知道产品分为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。

显而易见,这种做法是不合理的。如果中台产品人将这样的方案推上需求评审会,不仅不会得到研发负责人的认可,还可能会被各位研发同事怼。毕竟,谁也不愿意做工作之外的工作,而我们产品人更不能因为自己身上不背负开发的重任,就随意接需求,把一堆额外的任务丢给开发。

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

四、写在最后

本文主要描述了笔者在真实的工作场景中遇到的问题,并从问题中归纳总结出做中台产品的三大原则。以上仅作为笔者的经验,供各位读者参考。而各位读者对于中台的思考,需要从实际出发、在实际工作中总结专属自己的经验,方可在中台领域内快速成长。

俗话说,读万卷书不如行万里路。对于刚入门的产品新人来说,不论看过再多道理、再标准的指导原则,也许都跟纸上谈兵无甚区别。实践是检验真理的唯一标准,关于中台产品到底应该如何做,相信一千个人有一千个哈姆莱特。

 

本文由 @一颗半柚 原创发布于人人都是产品经理,未经许可,禁止转载。

本文为人人都是产品经理《原创激励计划》出品。

题图来自Unsplash,基于CC0协议。

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 中台的具现就是接口没错吧

    回复
    1. 通常情况下是通过接口的方式将中台能力提供给各个业务线,但是根据不同的业务需求也会有不同的方式(比如只传输数据,可以用消息队列等)

      回复
    2. 请教一下大佬,先目前一些普通的项目应该都是小中台的形式,是通过接口或者队列来交互,那有些人说的大中台用通俗的说法该如何解释了?

      回复
    3. 大佬不敢当,个人愚见:中台都是通过接口或队列等其他形式向各业务线提供支持,所谓的小中台和大中台的说法只是中台在整个企业中所占的比例大小。在企业中,中台所占的比例越大,就可以叫大中台,中台所占比例越小,就叫小中台。

      回复
    4. 了解了,言简意赅

      回复
    5. 感谢支持~

      回复
  2. 好文章,做中台产品要把握的标准,列举得通俗易懂

    回复
    1. 感谢支持,元旦快乐~

      回复
  3. 好文章,受益良多

    回复
    1. 感谢支持~

      回复
  4. 楼主,如果业务方强势,又该怎么办呢?

    回复
    1. 那当然就需要产品比业务更强势~~确定不做的需求,拒绝时一定要有充分的理由,不给业务反驳的机会

      回复
  5. 受益了

    回复
    1. 感谢支持~

      回复
  6. 如果有的需求业务线自己做,导致用户体验问题咋办?之前遇过一个案例,需要中台的扫码工具支持扫A业务线的售后码,售后码这个类型是有些定制,但如果业务线自己做就是在前台再增加一个扫码入口,加上中台的扫码,两个扫一扫入口,用户很难辨别用哪个

    回复
    1. 如果确实是业务线的定制需求,就业务线自己做,中台不做。这样一来就只有业务线做扫码工具,也就不存在两个扫一扫入口了。

      回复
    2. 没看懂,中台不是有扫码工具支持么?只是不支持售后码。他意思好像是别的业务条线可能,不会用到这个码的识别,不具备上中台的背景。业务线再做扫码工具就会有两个入口。为啥回不存在?没看懂

      回复
    3. 根据0风的问题,有这两种可能:
      1、中台已有扫码工具,A业务线已有售后码,0风的疑问是:售后码属于定制,按我的文章思路应该由业务线自己做,最终结果是中台有扫码工具,A业务线有售后码、扫码工具,这两个扫码工具用户不知道该用哪个?
      2、A业务线已有售后码,目前扫码工具还未做,0风的疑问是:扫码工具是A业务线来做还是中台来做?
      按我原来的理解,是第二种可能,因此我认为中台目前应该还没有扫码工具,所以我说不存在两个扫码入口。现在看来可能是我理解错了,应该是第一种可能~

      回复
    4. 再说解决方案,1、既然中台已有扫码工具,且属于定制功能,就由A业务线自己做售后码、扫码工具,中台下线扫码工具的服务。2、A业务线来做。
      在0风的问题中,售后码和扫码工具应该是被合并为一个需求了,因此在以上的回答中,我也将二者进行了合并。此外,个人还有一个问题:售后码是定制需求,由A业务线来做没问题,但是0风并未说到扫码工具是否是定制需求。如果扫码工具是通用能力,那由中台来做是没问题的,不知道0风为何会提到A业务线再自己做一个扫码工具?如果扫码工具是定制需求,当时又为什么是中台做了这个需求呢?

      回复
    5. 1. 扫码是中台通用能力,目前各个业务线前台都接入了扫码入口,包括A业务线~
      2. A业务线现在需要支持扫售后码这个类型,但中台扫码不支持这个类型,属于定制需求~
      3. 下线中台的扫码工具不妥,因为中台扫码解决了通用需求~
      4. A自己做的话,就得前台再增加一个扫码入口专门用于扫售后码,加上通用的扫码入口,前台就出现两个扫码入口,对用户来讲就会有不知用哪个的问题~
      5. 所以我感觉这种业务线自己做会产生体验问题的定制需求,中台是否也要考虑做呢?

      回复
    6. 原来如此,这种情况下,我建议:
      1、就售后码这个定制需求,向除A业务线之外的前台做需求调研,各团队是否会用到售后码?如果有其余团队表示希望接入售后码,那么问题迎刃而解,多条业务线需要的需求,中台来做,即扫码工具支持扫售后码。
      2、如果除A业务线外没有其他团队要使用售后码,那么我个人倾向于A业务线不接入中台,自己做扫码工具+售后码。

      回复