如何成功打造一款中台(PaaS)产品

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了如何成功打造一款中台(PaaS)产品相关的知识,希望对你有一定的参考价值。

       现如今,很多互联网公司在向“大中台,小前台”方向靠拢,通过打造高度可用、高度可定制的中台,来支撑前台业务的快速发展、个性化功能定制。但在构建中台产品(即所谓公司级平台)的时候,如何能成功让一款产品从0到1,即,能顺利诞生,落地,并产生价值呢?这里,我们抛开技术话题,探讨在产品设计规划时要考虑的。

       笔者曾经经历过四次中台产品打造,一次不成功,三次成功。打造一个成功的中台产品,一方面可以提高前台业务部门的效率,减少后续开发投入,还可以通过中台产品,集成前台业务数据,达到数据集成统一接入发布,甚至能发掘潜在客户需求,也有助于对前台需求进行启发。中台成功后,可以在全公司得到重视,进而影响整个公司的技术体系,当然其中个人和团队的获益也是显而易见的;中台不成功,就是没有人用,落不了地,boss认为浪费资源,从而否定产品经理和开发团队的能力(在这儿笔者需要感叹一下,虽然网上经常说开发和产品经理是死敌,其实二者是绑在一根绳上的蚂蚱,再牛逼的开发,如果没有成功落地的产品证明自己,也是空谈技术)。笔者通过复盘总结,得到一些经验和教训,希望读者能引以为鉴、为戒。

       产品诞生前,经常是源于公司前台产品出现大量重复性需求,boss希望能够进行提取抽象,做成中台产品。那么,在这个时候,需要注意遵循2-8法则,即寻找实现20%的功能,来撬动80%的需求场景。那么,具体做法是,产品经理需要收集各个业务线对于此需求的现状、短期的规划、以及未来的考虑。(在这个阶段,最好跟业务线产品经理达成一致,当我们的中台产品上线后,能够立刻接入,一个没有业务线用的中台产品是落不了地的)。通过整理总结各业务线反馈,标出该需求对业务线是否重要?商用价值是否高?未来是否需要?还是无关轻重的?然后,在这些需求中,按照2-8法则,找出撬动80%场景的那20%的功能,然后作为产品的MVP(最小可交付产品)推动实现。(一定要注意,实现尽可能少的功能,满足尽可能多价值高的业务场景)

       设计和开发阶段,产品和架构师(或者主程)必须达到深入沟通,让开发深入理解到此中台产品解决业务线什么场景,核心需求是什么,产品定位是什么,未来会向哪些方向发展。MVP能解决业务线哪些场景,还有哪些场景未解决。架构师基于此,选择合适的技术架构,封装好核心,对未来的扩展留出接口。好的中台产品,往往能无限扩展,比如快速开发平台(Bei...Clou.)能做出无限多的增删改查表单列表功能、前端组件化平台(Pa..Buil...)能搭建出无穷多的页面,自动化测试框架(BAT)能实现无限多的业务线自动化测试集。那么,就需要架构师在这时,设计好中台产品的核心架构,业务线如何使用,以及针对特殊个性化需求的扩展能力。

       一旦MVP上线(第一版),首先要做的不是继续增加功能满足更多的场景。而是要放慢开发脚步,转而去推动业务线进行接入。为什么呢?因为新需求的开发,势必会让中台产品变得“重”(臃肿),增加业务线或客户的使用成本,让中台代码变得复杂难以维护;而此时MVP上线,正是需要向boss和公司业务线展示产品价值的时候,而中台价值的体现,是从业务线那儿得到的,这也关系到boss是否能继续支持投入做这个产品,从而达到良性循环。如果能有多个业务线使用中台产品搭建出前台业务,那么,就可以证明中台确实能够提升开发效率,降低成本,能落地。如果一味逼开发上线新功能,往往团队看不到产品价值,有挫败感,业务线感觉不到你的存在,boss不认可从而不继续投入,导致恶行循环。。

       打造明星客户作为标杆。平台上线后,想要在公司一炮走红,或者让boss一眼就能看到产品价值,认为这是个牛逼的应用,必须打造出来一个标杆产品。以在前端组件化平台(Pa..Buil...)基础上打造个性化主页(Profi..)为例,当时为了推广中台,而推出了Profi..产品。而这个产品让大家眼前一亮,进而后续各业务线产品经理(可能本来没这需求的业务线)理解Pa..Buil...的作用,进而产生把Pa..Buil...应用在自己产品内的想法。

       当业务线开始试用后,势必会提出各种各样的花式需求。。此时,不管是产品还是开发,一定要有拒绝能力,能表示“这个功能暂时支撑不了”,或者通过什么方式扩展,对于业务线需求不能照单全收。要让业务线在中台的设计规范内进行扩展。不能为了实现某个业务需求,而在中台设计上“巧妙”实现,甚至hack中台产品(如果一定要做,也要明确跟业务线表示,中台升级的时候未必支持)。否则,当你的中台升级时,对于老数据的兼容会让你头疼死。

       中台的开发节奏一定要慢,要“小步慢跑”,要留出时间重构代码,填平技术债,不要做过多的临时方案。产品在提出新需求前,需要考虑好对之前业务的影响,对现有各业务线的影响。别出现中台升级,前台挂掉的情况。最好有专门的人去支撑业务线对接,解答业务使用中的问题(没有的话,team leader充当也行)。

 

注意:
第一戒,禁止去满足业务线所有场景。。做平台的产品,一定要懂得取舍,有些功能属于平台必须提供支撑业务线nocode(拿来即用,或者通过简单配置不接触代码即可满足场景);有些功能是平台提供扩展接口让业务线轻便扩展即可;有些功能是平台不支持,需要业务线自己开发。

第二戒,明确中台产品边界,禁止把业务功能渗透到中台产品中。比如,BAT的逻辑是启动Selenium、生成报表、提供版本控制、解析运行脚本、异常封装处理,而“打开登录页面”这种代码,不能出现在BAT的产品代码中。再比如,人才VS中,加载对比项、调用业务接口获取数据、业务接口超时自动开车是人才对比的功能,而加载测评活动列表绝对不能出现在人才对比框架中。这里需要注意,不混入业务,并不是说中台产品运行时没有业务,那就失去了中台的意义了。而是,不要把业务逻辑混到中台逻辑里。简言之,中台必须跟前台严格划清界限,我的是我的,你的是你的,你的逻辑不要进入。当中台产品中,出现对业务的特殊处理,就需要反思,是不是中台产品设计的不够好,需要特殊判断才能支撑业务。

 

总结:
1. 规划阶段,明确业务线现有需求,提取抽象中台MVP,满足2-8法则。
2. 尽早跟业务线约定好MVP上线时间,以及业务线使用时间。
3. 设计开发阶段,跟架构师讲透产品定位、扩展点以及发展方向,架构上要明确业务如何使用,如何扩展。
4. 产品MVP上线后,要推动业务应用,让中台产品落地,不要急于扩展新功能。
5. 后续迭代,要小步慢跑,留出时间重构、填技术债、解决业务问题。

以上是关于如何成功打造一款中台(PaaS)产品的主要内容,如果未能解决你的问题,请参考以下文章

数据中台实战:如何打造可以支撑N条产品线的标签平台

揭秘 vivo 如何打造千万级 DAU 活动中台 - 启航篇

如何成功卖出一款 SaaS 产品,我是这么做到的

智能汽车产品设计中台

启发录-打造用户喜爱的产品

SKG 渠道中台借助 SAE + 大禹打造云原生 DevOPS,提效 60%