中台这一概念，在近几年在国内大热，不少企业接连开始组织架构的调整，意图建设中台。但建设中台，并非这么容易，可能投了不少钱，最后也没有什么水花，那么中台为什么难做？作者在这篇文章中给出了解答，一起来看看吧。
狭义上来讲：我们知道前台是一个个面向用户的可视化操作界面。
后台是包含代码、中间件、数据库等一系列框架代码集。
后台搭建完，前台就会展现出来，一个闭环就形成了。
那什么是中台？顾名思义中台其实就是在夹在前台和后台之间的一个东西。
那为啥前后台已经能形成闭环了还需要中台？
大家一定听过一个被讲了很多次的故事：阿里在发展业务的过程中发现，随着业务线的快速增加，一开始只有一个1688，后来出现了淘宝、阿里妈妈、支付宝、咸鱼、口碑等等大量的内部项目。
每个项目都需要开发一个所谓的前后台闭环，阿里内部100个业务，就得搞至少100个闭环，1个闭环算他50个人的开发测试团队，大业务线还不止，就得5000个员工，这在以人员成本为最大成本的互联网公司，简直是要命。
当然成本还不是最关键的，最关键的是效率，在互联网快速发展的阶段，效率是生命线，你比别人上线晚、迭代晚，可能就玩不过人家了。
所以只能拼命堆人做，与时间赛跑。
虽然这个思路是对的，但是抵不过几个问题啊：
于是马云大腿一拍，搞中台，中台能全部解决上面的问题，还能大大降低成本。
怎么搞呢？
就是把一些通用性很高的模块，抽出来，作为公共库的一个个“能力”，然后A业务需要这个了，来拿一下直接用，B业务需要那个了，来拿一下直接用。
大家一定会说，很像开放平台啊！对，本质上其实就是个对内的开放平台。
于是每个新业务就不需要那么多研发人员了，通用的模块就不用重新开发了，在既有的中台能力库上做功能，对业务的响应效率也会高出一个层次。
这么一想，中台简直是一个大杀器啊！
于是阿里就大刀阔斧的开始搞中台建设，花了几年时间，终于陆续建成了。
这期间，随着阿里的如日中天，江湖上吹中台的声音到处都是，管他大公司、小公司、做业务、还是做平台，做全品类，还是做垂直，都是在鼓吹应该要做中台。
不少公司投入了好多钱，也没做出个什么水花来。甚至阻力重重，推到一半就推不下去了。
然而后来阿里又亲自“推倒”了自己的中台计划，把中台的服务能力拆分的更小。
一时间唱衰中台的声音又此起彼伏。
归根到底，看似预期很强大的中台建设，存在以下巨大的难点。
搭建中台的产品技术，必须高度了解业务，你想业务A的人只要了解业务A，业务B的人只要了解业务B，中台的人既得了解业务A，也得了解业务B，100条业务线，得了解100条，甚至他要比A更懂A，不然咋抽象对吧
这其中涉及到多个环节：
1）看的准？
你得看的准这个业务是怎么在跑得，他的核心流程是怎么样的，他的功能模块有哪些、具体包含了哪些功能？其中哪些模块适合被抽出来？
随便举个例子，很多东西都会伪装，都会变种，举个最简单的例子，一个盲盒功能，你觉得这个盲盒是什么东西？不会真抽象一个叫盲盒的能力吧？那你就完蛋了
过两天来了一个大转盘需求，你去资源池里找了一圈，发现刚做的盲盒能力根本用不了？？
算了，再做一个大转盘吧。
看到这里，大部分小伙伴已经看出来了，盲盒本质上不就是抽奖么，这两个理应是“一样的东西”，大盘转的需求，“盲盒”的能力理应能被使用啊。
本质上它们都等同于“抽奖”。
2）抽的对？
看准后，就要抽的对，抽的对包含几层意思。
i、边界清晰
边界清晰有多重要？不清，是要命的！直接决定了中台的失败。
你到底抽到什么程度？
还是盲盒的例子，盲盒活动的整个业务链路，涉及到了用户、支付、订单、抽奖。
你难道把这些都抽出来了？还是只抽抽奖那部分？
抽的太多，中台就太厚，你让业务干嘛；抽的太少，中台就太薄，失去了意义。
ii、模块的能力合理拆分
既然我们觉得把抽奖 抽出来，那么抽出来，怎么变成一种可灵活调用的能力？
如果拆的好，那么能满足很多额外的场景需求。
哪天来了个新需求是：直接积分兑换奖品。
用抽奖其实是可以满足的，比如你把抽奖分成3块：【抽奖资金获取抽奖资格】、【抽奖核心算法】、【中奖后用中奖券兑换奖品】
那么积分兑换奖品，是不是就可以使用3）的能力？
积分和中奖券，本质上都属于一种虚拟资产，是不是能力就通用了？
iii、如何权衡
中台也面临需求越来越复杂的情况，比如抽奖的时候直接开奖，也有抽奖后某一时间一起开奖；比如算法策略是大家一起开奖，还是部分用户可以优先开奖；比如是必中，还是可不中等等。
这些多样性，在业务的发展中一定会越来越复杂。
和普通产品迭代一样，中台也得不断强化和迭代能力，不然就满足不了业务需求了。
就好比你做了可以直接开奖的能力，结果另一条业务线抛过来一个一起开奖的需求，完犊子了，又满足不了。
所以和普通的业务迭代一样，中台的需求，也面临大量决策问题。
依然需要有效甄别真需求，还是伪需求，需求优先级怎么样，重要或是紧急，最后判断出来该不该做，怎么做，什么时候做，做了价值大不大等等。
中台的协同成本高，这个很好理解，毕竟原来只要前台和后台配合就能完成的事，硬生生的插了一层，变成了3方配合才能完成，难度直接增加50%。配合开发难度PLUS，相应的迭代和找问题的难度也PLUS了
尤其是中台搭建初期能力还不完善的时候，人家根本不想用你，但又碍于公司战略，不得不用你。就变成了一种非市场机制下被迫的行为。
所以中台早期是很难的，中台人也是比较惨的，因为他必须要服务好每个业务线的前后台团队 ，而不是单一的一个需求方。
这种协同复杂度，是几何级的上升，我给你们举个例子：
还是拿抽奖，比如A需要有一起开奖的需要，B要算法是随机中奖算法，C要必中。
而且大家都很急，要求尽快上线，A要求5天后，B要求7天，C要求8天内给到。
这个时候，不单单是判断需求应该先做什么，怎么做的问题了？
还面临着复杂的项目管理问题，资源怎么安排，来保证ABC三方都能满意，结果开发一评估，发现A能在5日内给到，B、C怎么赶时间都不能在7、8天内给到。
于是吭哧吭哧去找B、C商量，能不能缓一缓，结果BC不同意，于是只能考虑优先排BC的需求，再找A去商量，想把A的需求后置，A当然不同意啊，凭什么我要给BC让路，噼里啪啦一顿沟通……大家都不妥协，于是只能向上反馈，要更多的资源。
这其中，也有因为协调不好，有些业务线撇开中台，自己去做了，因为等着误了业务发展，业务始终是第一考虑。
这只是其中一个很小的场景，解决方式也只是举了一个例子，但是管中窥豹，可以看出中台在服务多业务线的过程中，所面临的巨大协作成本和难度。
中台从广义上来讲：从业务中来，又到业务中去。
做的好的中台对业务一定是有帮助的，但确实因为其难度很大，真正做的好的公司少之又少。
本文由 @ 华叔产品论 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。