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

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

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

01 什么是中台

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

1. 基本特征

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

2. 中台目的

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

3. 中台价值

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

02 小产品的繁琐问题

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

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

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

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

03 中台思维

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

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

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

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

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

1. 提取共性需求

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

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

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

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

2. 标准化、模块化

形式标准化：

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

功能模块化：

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

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

3. 让业务更灵活

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

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

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

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

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

1. 发掘共性需求

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

2. 评估需求痛点

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

3. 制定标准、设计模块

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

4. 持续推广、价值复盘

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

总结

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

本文作者 @iCheer

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！