中台大家肯定不会陌生，所以小胖不必做过多的解释了。今年有幸参与到公司中台项目的建设中，弹指一挥，从开始的方案设计、到上线、到推广，也过去了接近一年的时间。回首这段岁月，小胖总结了中台设计、开发、推广中的“七宗罪”，本着中台还是一个大方向的大前提下，你或许以后也会遇到。
第一宗罪：怎么处理2B业务与2C业务的关系
首先，我们很理解中台之所以建设的意义和目的，就是要精简系统、肃清机构，从而提高效率、降低成本。
不是所有的公司和系统都需要中台，只有经过了几年甚至几十年沉淀的系统才适合做，因为面对尾大不掉的情况，是时候进行一些创新了。
但是，这时候“历史原因”就往往成为制约我们进行再设计的一条拦路虎。我们说中台就是要避免“重复设计”，但是看似同样的功能如某些营销工具，在2B和2C的产品设计中对于规则和细节的要求是不一样的。
理想与现实也往往存在较大差距。因此，在新中台的创建和旧平台的迁移过渡阶段，有时候需要一些灵活的处理，尤其是在资源有限的前提下，首先要保证业务的正常运行，不必一定要拘泥于所谓的条款和规则。
第二宗罪：账号体系也许是整个项目中最大的坑
如果你认为账号只是负责登录、很简单的，那就大错特错了，可能还会受到严重伤害。
目前市面上的“中台”许多都是对已有系统的重构和再组合，因此，多个系统在账号体系上的设计是存在很大差异的，不仅仅是登录、授权、权限区分等，登录的性能也会受到很大的挑战。因为按照目前按照功能模块授权的设置方案，对于高权限的用户来说，在打开页面的时候需要加载很多内容出来，对性能的要求很高。
还有，一定要把所有权限相关的功能一次搞定，不论这个项目到底是分了多少期来做，做的越早越好。
第三宗罪：多系统间技术框架和数据库的使用
天下大势合久必分，分久必合。中台其实也是类似的一种理念，但是多个系统在重新解构、重构的过程中，虽然于前端我们通过设计、UI进行统一，但是对于中台来说更重要的还是后台架构和数据库的搭建。
小胖就遇到几个系统竟然用了不同系统框架和不同数据库的问题，可能开始设计和开发的时候并没有觉得有多么别扭，但是当开始使用的时候才知道有多酸爽。
第四宗罪：用户体验很难统一
对于一些还未形成自己统一UI和设计交互规范的公司来说，多个系统的合并简直就是噩梦。一是系统中的使用用户是分多个的，比如商家端、用户端、供应链端、财务端，等等，每个角色都有自己所需要的一套流程，并且对于一些职能部门，他们早已经习惯了十几年如一日的操作流程，突然你要统一规范，还告诉人家特别好用，他信你就鬼了。
第五宗罪：利益关系的处理
这里的利益关系主要分为两种，一种是原有业务的使用者，尤其是新老业务间的利益冲突，另外一种是作为研发体系部门之间的利益分配问题。
比如，一个功能新业务觉着简单点就好，但是老业务一定要经过几个节点才可以使用，因为两者之间安全性和易用性的要求是不一样的，这里怎么融合两者的利益关系至关重要。
另外，中台作为一个保姆式的产品，许多功能是偏向后台的，因此前台是看不到你的，如果有了成绩那么就是前台的成绩，如果出了问题就是后台的锅。因此，怎样分配好前后台的利益，也是让产品经理和老板们头疼的问题。
第六宗罪：项目推进如无头之蛇
中台的搭建是一个跨部门、跨平台、跨业务的工作，怎样调动各方的积极性，怎样更好的让各方发挥出自己的实力，怎样保证项目可以顺利、保质保量上线，就是摆在我们面前的一个关键点。
乌合之众讲人群是缺少统一意见的，尤其是当不同利益的人聚集到一起的时候。如果一件事让一个人做，他可以3天做完，如果同一件事让3个人做，可能需要30天才能做完。
中台项目推进的痛点在于大家很容易各自为政，加上帮派之别，一件简单的事情很容易搞得很复杂，凡事都要走流程、各种邮件确认，非常影响大家的效率。
第七宗族：项目推广似老汉推车
我们说产品做出来了，赶紧推广吧。
Too Young，Too Naive！
第一代的中台产品注定是不怎么受待见的，因为刚做出来系统的稳定、系统的用户量都还没有起来，反而是各种大大小小的问题接踵而来，让你应接不暇，因此，对应这类产品的推广便也可想而知，不会特别快，需要你要保存尽量大的耐心。
不是为了吐槽而吐槽，希望这些痛点你之前遇到过以后就不要再遇到了；
为了更美的以后，总结一些不美好的过往案例，一定程度上可以让后续很美好。
网友评论