小产品的“中台思维”解决方案

0 评论 5600 浏览 47 收藏 12 分钟

对小产品来说,中台思维同样可以为产品与业务的发展起到帮助与推动作用,那么小产品的中台解决方案一般要注意些什么呢?

前端时间,小汪报名了一个中台建设的课程,觉得很是受益,于是回来就跟舍友来福嘚瑟,鼓吹中台好啊,中台化发展大势所趋啊。同为产品经理的来福深思了一会儿,说到:“可是我们公司就只有一款产品啊……那要中台来能有什么用呢?”

小汪深思了一会儿,对来福说,让我们先看看中台是什么吧,梳理一下些许会有什么启发?

01 什么是中台

相信在看本文的产品经理已经看了不知道多少遍各种中台的来源、中台的定义了,这里就简述一下。

1. 基本特征

中台提炼并沉淀了各个业务线的共性需求。

2. 中台目的

将共性需求转化成平台化、标准化、模块化的功能,以接口或服务的形式再提供给前台各业务使用。

3. 中台价值

对于整个公司而言,极大的减少了“重复造轮子”,同一个问题不需要每个业务线都想办法自己解决一次。让各业务线更关注于业务拓展与创新,研发更敏捷。

02 小产品的繁琐问题

小汪说,中台的目的就是为了解决那些日益增加的重复工作,你们虽然只有一款产品,但是有没有遇到什么经常要重复的工作?

来福思考了一下,说到,我们虽然只有一款产品,核心场景明确,但是我们经常会围绕这个场景进行拓展,搞很多形式的活动进行拉新、促活、促进用户消费等,如果说什么事情总是要重复做,那还是有一些的:

  • 活动:因为我们的活动很多,而且每个活动形式差别比较大,尽量避免用户对相同的形式的活动感到疲乏、让用户每次看到都能“眼前一亮”。所以我们的活动每个都是定制开发的,研发花了大量事情在做活动上。
  • 对接:为了推广我们公司的产品,我们开始尝试跟多个APP合作,把我们产品的功能内嵌到他们的APP中,每次对接对方都会提各种要求,如UI、用户体系、支付订单同步等,我们就跟要重做一套那么麻烦。
  • 数据:我们的数据是用第三方公司提供的现成的数据平台,每次加功能就做对应的埋点,但是数据平台的功能非常有限,有些订单数据我们又不愿意让对方采集,所以就每个月运营定时从后台导出订单制作报表。
  • 其他:虽然我们只有一款产品,但是我们有APP、微信H5、微信小程序三个端,里面的注册登录、支付、分享逻辑都是互相独立的,但是绝大部分前端新场景,都绕不过要用到注册登录、支付、分享的。

来福继续说:因为我们重运营,如果非得发展中台,那么搭建一个活动中心出来肯定是首要任务,但是我们的技术也评估过,要做一个那种一拖活动就出来的平台,十分复杂耗时。其次选择应该是搭建自己的数据平台。

03 中台思维

尽管网络上各种中台知识铺天盖地,现实中绝大部分公司可能还处于发展期,手头也就一款产品,对他们来说并没有搭建中台的必要。

对于发展期的公司而言,如何快速的解决眼前的问题经常会变得“特别重要”。俗话说,头痛医头脚痛医脚。这就会导致一个问题,等公司业务量开始爆发后,发现过往埋下了很多的“坑”,想拓展新的业务时,发现举步维艰。

领导认为,不就是复制一个功能改改就行了嘛,技术却发现,前人留下的代码、功能丝毫不具可复用性,什么需求都要重新做。于是搭建中台就在这时候顺理成章的登上了舞台。

如何避免未来少走弯路,不要等到搭建中台的时候才后悔莫及当初为何没规划好,这就需要“中台思维”。

中台思维就是把中台建设中的“提取共性需求”、“标准化、模块化”、“让业务更灵活”用于指导日常的产品设计工作。

1. 提取共性需求

就像来福描述的他们公司的产品,我们已知注册登录(用户)、支付、分享这三个功能是会被一直用、重复用的,还有数据统计,未来形成规模后一定会独立出来的。

对于活动而言,可能每个活动的表现形式都不一样,可能有抽奖的、互动游戏的,还有丰富的逻辑规则穿插其中,想要运营在界面上一拖拉,一个活动就建好了,这是很不现实的。但是有两点可以抽象出来的:

  • 活动所需的获取商品、订单、用户信息,甚至分享、支付、优惠券等功能,大部分活动都会用到,并且最终目的也就是促活或者促进用户下单。
  • 活动的“形式框架”,第一种框架是活动的形式固定下来了,每次就换个皮肤;第二种框架是将抽奖、用户助力、集卡这种功能独立出来,加上不同的规格,再换上不同的皮肤,然后就形成性的功能。

虽然只有一款产品,但是很多业务场景是会重复用到一些表层或者底层功能的,辨别并抽取出这些功能来,这是中台思维的第一步。

2. 标准化、模块化

形式标准化:

例如一个系统中存在好几种形式的订单,是否能进行归类、合并,而不是多一个业务就再搞多一套订单出来。不同的业务场景、功能下,都可能用到分享,分享后的样式、接下来的流程可能各不相同,但不妨碍将分享样式、分享后的行为进行归类整理,避免又来一个新场景后又重新接一套分享,不便于样式统一、分享行为统计,增加开发周期。

功能模块化:

例如用户注册登录,定义好用户信息的字段、通用登录页面样式后,形成用户注册登录模块,对于前端而言就是形成一个统一的登录页面或登录框。任何业务场景需要用户信息时,如果发现没有用户信息则引导用户到注册登录界面,然后用户注册登录完就返回对应的业务场景;如果业务对登录有特殊的需要,只需要唤起注册登录页时,按照标准提供所需字段、页面配图,注册登录页就可以按业务所需呈现。

标准化和模块化相辅相成,标准化是为了方便模块化,而模块化的目的就是支持标准化调用。

3. 让业务更灵活

让业务更灵活,不仅是个目标,更是一种思想,在产品设计的时候,就应该思考:

  1. 这个功能未来会不会再用得上?
  2. 万一未来用户很喜欢这个功能,功能本身具有多少发展的空间?
  3. 未来会不会有别的或类似需求,可以使用这个功能改改就能对付?
  4. 这个功能未来可不可能跟别的功能整合?

只有思考了这些,才能避免做出来的功能是“一次性的”,就为了解决某个很确切的事情“定制的”的。

04 小产品的“中台思维”解决方案

尽管你的公司只有一款产品,业务场景也不算丰富,我们可以用如下的办法,寻找可以优化的切入点。

1. 发掘共性需求

找到不同业务场景都会用到的功能,有些业务场景表象各不相同,需要抽丝剥茧才能发现底层相似的内核。对于小产品而言,有时候产品上功能本来就没几个,这就需要有前瞻性,结合业务发展方向,探寻更可能被复用的功能。

2. 评估需求痛点

研究所有可能复用的功能,与技术沟通模块化的成本、复用模块和每次重做一套的成本差别,与运营沟通这些功能打通对于未来业务场景、数据统计是否有利。最终根据需求本身的价值、研发成本、实现统一的可行性,确认优先级。

3. 制定标准、设计模块

由产品牵头,对需求程度高的功能,标准化调用的字段、前置条件、后续流程,由技术确认着手点,是在下个版本中做一个新模块出来,又或者对已有某个流程节点的该功能进行改造,以后有用到这个功能的都调用这个模块。

4. 持续推广、价值复盘

在后续每个版本中,用到同样或者类似的功能时,就调用已有的模块并且对该模块进行不断的升级优化。同时与技术、运营复盘,确认该模块对新业务、新活动的上线解决了多少时间、人力成本,进一步为运营带来了多少价值。以作为未来持续推荐“中台思想”的着实依据。

总结

中台是一个实实在在的系统,而“中台思维”就是把未来要做的事情,先在现阶段打好基础,不要等到业务或者产品技术排期遇到瓶颈时,再来想办法解决问题。

 

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

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!