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