中台上线半年,我总结出了“七宗罪”

中台火热,实际建设却有七宗罪。

中台大家肯定不会陌生,所以小胖不必做过多的解释了。今年有幸参与到公司中台项目的建设中,弹指一挥,从开始的方案设计、到上线、到推广,也过去了接近一年的时间。

回首这段岁月,小胖总结了中台设计、开发、推广中的“七宗罪”,本着中台还是一个大方向的大前提下,你或许以后也会遇到。

中台上线半年,我总结出了“七宗罪”

第一宗罪:怎么处理2B业务与2C业务的关系

首先,我们很理解中台之所以建设的意义和目的,就是要精简系统、肃清机构,从而提高效率、降低成本。

不是所有的公司和系统都需要中台,只有经过了几年甚至几十年沉淀的系统才适合做,因为面对尾大不掉的情况,是时候进行一些创新了。

但是,这时候“历史原因”就往往成为制约我们进行再设计的一条拦路虎。我们说中台就是要避免“重复设计”,但是看似同样的功能如某些营销工具,在2B和2C的产品设计中对于规则和细节的要求是不一样的。

理想与现实也往往存在较大差距。因此,在新中台的创建和旧平台的迁移过渡阶段,有时候需要一些灵活的处理,尤其是在资源有限的前提下,首先要保证业务的正常运行,不必一定要拘泥于所谓的条款和规则。

第二宗罪:账号体系也许是整个项目中最大的坑

如果你认为账号只是负责登录、很简单的,那就大错特错了,可能还会受到严重伤害。

目前市面上的“中台”许多都是对已有系统的重构和再组合,因此,多个系统在账号体系上的设计是存在很大差异的,不仅仅是登录、授权、权限区分等,登录的性能也会受到很大的挑战。

因为按照目前按照功能模块授权的设置方案,对于高权限的用户来说,在打开页面的时候需要加载很多内容出来,对性能的要求很高。

还有,一定要把所有权限相关的功能一次搞定,不论这个项目到底是分了多少期来做,做的越早越好。

第三宗罪:多系统间技术框架和数据库的使用

天下大势合久必分,分久必合。中台其实也是类似的一种理念,但是多个系统在重新解构、重构的过程中,虽然于前端我们通过设计、UI进行统一,但是对于中台来说更重要的还是后台架构和数据库的搭建。

小胖就遇到几个系统竟然用了不同系统框架和不同数据库的问题,可能开始设计和开发的时候并没有觉得有多么别扭,但是当开始使用的时候才知道有多酸爽。

第四宗罪:用户体验很难统一

对于一些还未形成自己统一UI和设计交互规范的公司来说,多个系统的合并简直就是噩梦。

系统中的使用用户是分多个的,比如商家端、用户端、供应链端、财务端,等等,每个角色都有自己所需要的一套流程,并且对于一些职能部门,他们早已经习惯了十几年如一日的操作流程,突然你要统一规范,还告诉人家特别好用,他信你就鬼了。

第五宗罪:利益关系的处理

这里的利益关系主要分为两种,一种是原有业务的使用者,尤其是新老业务间的利益冲突,另外一种是作为研发体系部门之间的利益分配问题。

比如,一个功能新业务觉着简单点就好,但是老业务一定要经过几个节点才可以使用,因为两者之间安全性和易用性的要求是不一样的,这里怎么融合两者的利益关系至关重要。

另外,中台作为一个保姆式的产品,许多功能是偏向后台的,因此前台是看不到你的,如果有了成绩那么就是前台的成绩,如果出了问题就是后台的锅。

因此,怎样分配好前后台的利益,也是让产品经理和老板们头疼的问题。

第六宗罪:项目推进如无头之蛇

中台的搭建是一个跨部门、跨平台、跨业务的工作,怎样调动各方的积极性,怎样更好的让各方发挥出自己的实力,怎样保证项目可以顺利、保质保量上线,就是摆在我们面前的一个关键点。

乌合之众讲人群是缺少统一意见的,尤其是当不同利益的人聚集到一起的时候。如果一件事让一个人做,他可以3天做完,如果同一件事让3个人做,可能需要30天才能做完。

中台项目推进的痛点在于大家很容易各自为政,加上帮派之别,一件简单的事情很容易搞得很复杂,凡事都要走流程、各种邮件确认,非常影响大家的效率。

第七宗族:项目推广似老汉推车

我们说产品做出来了,赶紧推广吧。

Too Young,Too Naive!

第一代的中台产品注定是不怎么受待见的,因为刚做出来系统的稳定、系统的用户量都还没有起来,反而是各种大大小小的问题接踵而来,让你应接不暇。因此,对应这类产品的推广便也可想而知,不会特别快,需要你要保存尽量大的耐心。

不是为了吐槽而吐槽,希望这些痛点你之前遇到过以后就不要再遇到了;为了更美的以后,总结一些不美好的过往案例,一定程度上可以让后续很美好。

特别申明:本站的主旨在于收集互联网运营相关的干货知识,给运营小伙伴提供便利。网站所收集到的公开内容均来自于互联网或用户投稿,并不代表本站认同其观点,也不对网站内容的真实性负责,如有侵权,请联系站长删除。

0