传统以职能部门分治的树状组织架构，若一个底层员工有个好点子，就不得不自下而上说服管理层，管理层还需发动行政力量推动层层下属，任何一环出了问题就难以进行，其难度可想而知。而各业务线各自有KPI，互相协作非常困难。
(传统的组织架构)
即使说服老大，克服重重困难，从各部门抽调和招兵买马，成立了新的业务部门。然而市场变化非常快，一旦业务受阻，方向转换，花费巨大精力组成的业务线何去何从？此时部门的发展极大地依赖于老大的决策，底层活力不足。
大型组织想出各种方式解决这样的问题，例如阿里在2016年提出了“大中台小前台”的战略，将业务共同的工具和技术予以沉淀，成立专门的中台部门。这样新的项目可以重用中台服务而不用重新设计，避免重复功能建设和维护带来的浪费和山头林立。这样做的不只是企业，美军更是设计了新的战斗方式，每3人一个小组，战斗需要时可随时调集后方火力，信息和后勤支援，灵活而成本低廉。
程序员对这些概念更是熟悉，中台类比到编程领域，就是形成可复用的函数库，抽象共性，减少重复开发，提升迭代效率。中台将人力，技术和服务重新组织，例如，数据中台维护底层数据能力，内容中台将各类资讯汇总整理，供给各业务线丰富的资讯资源；推荐营销中台抽象推荐系统的共性，为各种业务提供营销的快速接入能力。这样也方便统一协调，如数据中台可根据业务优先级管理流量和负载分配，这在各部门独立运营时是不可想象的。当然，中台还有一大好处：分担风险，方便分黑锅，你懂的。
当然，不是所有公司都能实现中台战略，中台要求扁平化的管理模式，没有太多的条条框框。灵活的考勤，没有隔板的工位，统一的基础设施（如数据库和代码库），否则中台就是空中楼阁，实施起来甚为困难。
中台模式的困扰
如果中台模式全部都是好处，这篇文章就应该结束了。中台相比于传统模式虽有优势，但实践和理论的隔阂必然存在。中台该做不该做什么，如何与业务方良好协同，如何评估KPI都成了难题。
我们可以根据中台对业务方的参与度，绘制成下面的一张图。
轴的最左边：仅提供工具库和少量答疑维护，不对业务效果负责。绝大多数开源项目，各种数据库，都可以归于这种极端。
轴的最右边：all-in参与业务方的大部分流程，从运营业务，到数据模型，事无巨细。我们戏称其为“高级外包”。
我们形象地称其为左倾和右倾问题。
越往左走，工具抽象和通用能力强，赋能业务多，雨露均沾，研发人员能专注于技术本身。但越往左越好么？不一定。越左就无法深入业务场景，无法接受业务滋养，很可能故步自封，甚至为了技术而技术，变得学究派，而过于独立的中台变成了纯后台，更重要的是，如何评估业务产出？
在最右面则是另一种极端，其优点非常明显：此时中台完全融入业务，有完整的业务sense，非常理解并能快速应对需求，与业务方打成一片，戏称为“高级外包”。但是，该模式的人力一般只能覆盖单一业务，很难对外辐射。由于精力所限，技术人员过分关注业务，中台的技术深度就会相对较差。
我们要同时警惕这两种极端，但从整体来看，最容易被忽视的反而是右倾。右倾构建了看似美好的中台合作模式，亲密无间的服务，但是人们很容易忽略其问题：由于过分具象和强耦合，中台能力难以沉淀在通用的工具和理论上，当出现其他相关业务时，原有产品并不能支持，应对变化的能力小，一旦业务方向变化就可能前功尽弃。
此时由于中台容量有限，过重的服务模式导致只能覆盖有限的业务。中台不得不评估前台项目的重要程度，甚至拒绝为低优先级的前台提供支持，挑肥拣瘦。那么前台可能会为自己的业绩考虑去自行组团队完成项目，进而导致中台与前台隔阂。相反的，若事无巨细地参与到业务方，侵入性就会很强，人的问题会成为最大的问题：它可能会架空业务方人员，引起猜疑，甚至可能被并入业务方，导致中台骨干流失。
那什么才是合理的中台模式呢？
合理的中台
最好的服务应该像空气一样，不留意就感受不到存在，但不可或缺。
首先，中台必须有对应领域过硬的能力积累，例如算法中台需要有扎实的理论基础，搜索中台在搜索能力的积累更是要达到业务方远达不到的程度。打铁还需自身硬，否则被革命掉只是时间问题。
中台一方面提供服务，另一方面则促进人和人的交流，推动换位思考。原本不同方向的人为了共同的任务在一起工作，能够迅速地学习对方的能力。当任务告一段落后，我们需要关注：业务方是否能维护，改进甚至优化中台的工作和技术；中台是否能产生对业务的通盘理解和技术沉淀。因此，在合作刚开始时，可适当右倾，中台快速熟悉业务，建立共识；随着业务深入，业务方吸收消化，中台逐渐后撤，直到业务方可自行处理大部分问题。
一般来说，在提供相同服务质量的前提下，对业务问题的抽象能力越好，参与度就能越往左。 例如SQL确实是非常伟大的发明，它将数据处理的需求抽象地如此淋漓尽致，技术人员能够专精于性能优化，业务方能灵活操作数据库，完成业务任务。
因此，中台有个重要命题应当考虑：自己的服务和技术应该如何合理抽象，将业务和底层尽可能隔离开来？这套领域特定语言(DSL)应该如何设计，才能让业务方也能看得懂，用得好？ Tensorflow和Keras这类深度学习框架成功的一大部分原因，就是设计了非常良好的深度学习原语。越好的抽象和领域原语，就越能发挥前台人员的业务优势和主观能动性，极大地提升了沟通效率。
同样，业务方也必须能把自己面临的问题予以清晰地描述，参数，环境和目标至少能明白地写在一张纸上。提出模糊的，太过抽象的(比如不管用什么方式，只要能提升KPI)，甚至不切实际的目标，就是业务方的懒政和甩锅，中台不是高级外包。在任务层面上，两边应有清晰的分界和明确的问题，大家都精力有限，应做好分内之事。
在沟通上，不仅需要主管之间的密切配合，建立紧密沟通机制，如定期参与前端的业务周会；同时还应有清晰的接口人机制。笔者见过不少例子：多个接口人导致信息冗杂，传播不畅，有时不得不十几个人开大会，导致反复沟通，效率很低。接口人需要明确业务问题，熟悉数据链路，沟通能力强，方能事半功倍。
结语
一切事业都需要由人来推动，大部分问题都是人的问题。组织形式的不同，会导致信息传递效率的极大不同，进而影响事业的成败。“组织架构排名第二的公司，最后在市场上也只能居于老二的位置。”
本文只是笔者作为某大型公司的基层中台工程师，面对业务合作中遇到问题的一些思考，由于视角限制，肯定有以偏概全甚至偏激之处，还请各位读者老爷海涵。为什么要写这篇文章？因为研究如何利用零和博弈，组织一帮聪明人，高效地为了同一个目标奋斗是非常有意思的，组织架构的设计很值得思考。当然由于篇幅所限，还有很多问题没有讨论，比如如何考核中台绩效？
拿着 5000 块的工资，操着 5000 亿富豪的心呐。
