• DevOps|从腾讯TEG CDC解散聊技术中台价值和建设


    近日一则腾讯TEG CDC整个部门解散的消息在很多群里炸了锅,有的唱衰互联网行业,有的唉声叹气,还有的甩锅到 AGI 的发展。总体上来说,这个事情的确已经发生了,我想从组织架构和整体效能这两方面来分析下这次组织变化。

    腾讯TEG CDC解散

    6月28日,网传腾讯TEG CDC整体解散,人员涉及设计师、开发人员等,数百人规模。CDC是腾讯技术工程事业群TEG下属的一个中台化的设计支持部门,全称“腾讯用户研究与体验设计部”,2003年开始组建,CDC的初创成员唐沐、陈妍。CDC 负责了腾讯成立以来许多重要产品的体验设计:如QQ、QQ空间、QQ游戏、RTX、QQ电脑管家、QQ浏览器、QQ音乐、腾讯视频、腾讯地图、QQ拼音、SOSO、拍拍等等。多年来,CDC培养了上千名用户体验相关从业人员,现在,他们在多个行业、企业及岗位上担起重任。

    聊聊中台部门的意义和价值

    中台是一种体系/生态/方法论,解决顶层领域下各业务子域的高效协同和资源复用问题。中台源于何处未知,确实最早在阿里大中台小前台的策略下流行起来的,但是后来阿里又主动打破了中台,把技术下沉到了业务,这是后话。目前主流的中台定义和分类有如下四种:

    • 数据中台:通过数据技术,对海量数据进行采集、计算、存储、加工,同时统一标准和口径。
    • 技术中台:提供技术重用组件能力,技术支撑能力,帮助解决基础设施,解决基础技术平台的复用。如微服务框架、DevOps平台、容器、DB等。
    • 智能中台:提供共享算法能力,帮助提供更加个性化的服务
    • 业务中台:或称为应用中台,提供重用服务,例如用户中心、订单中心、营销之类的开箱即用、可重用的能力。

     

    中台建立初衷在于提效

    其实,中台的想法在公司效率为王的时期是很好的。比如一款产品涉及A和B两个团队,A团队发展迅速但资源有限只有5名设计师,B团队需求稳定工作量小但有10名设计师。

    存在的问题:

    • 公司发展初期招聘不到足够多的特别有能力的资深员工
    • 不同业务发展速度有别,资源不均衡
    • 业务发展快,都急需支持
    • 设计规范性差,两个部门两种风格,难以协同

    解决方法:

    • 把15名设计师独立成一个团队,由资深成员带领和指导
    • 资深设计师制定产品规范和设计师支持计划
    • 其它初级设计师按照规范工作,对多个产品进行支持,资深设计师进行把关
    • 资源不足时,按照产品重要程度和时间节点等排优先级分配资源

     

    这样做很大程度上解决了设计团队能力的问题,工作质量问题,也满足了业务发展的要求,公司整体效能得到了很大的提高。但是这种中台实际上是一种资源型中台,作为一个资源池,主要提供人力输出到业务线,和上面的各种中台还是有很大不同。

    大而僵化的中台整体效能低

    随着资源型中台部门变大,逐渐的固化和僵化,对业务的价值贡献度也在降低。

    • 首先不深入跟进业务部门需求的初级设计师,会被业务认为不理解业务,阳春白雪,落不了地
    • 其次资源池结构的设计部门,谁都去申请资源,申请更多的资源,甚至超出自己需要的资源。没有内部成本结算,设计师和业务双方也几乎都不考虑成本,整体效能低。
    • 最后设计排期成为矛盾点。业务希望大干快上,踩着点一步步往前走,但是设计排期有自己的排期,双方节奏不一致,引起矛盾。
    • 渐渐地业务方更愿意使用少量的 HC 去招聘一些有经验的资深设计师,按照公司 CDC 的规范专门支持自己的业务。既满足了自己的需求,也解决了排期的问题,但长此以往 CDC的存在价值就更低。

    资源型中台

    整体上资源型中台的发展都会经历上面的过程,始于提效,终于效能差。除了设计师部门,下面的一些资源型中台也有这个问题:

    • 专职和某业务对接的SRE
    • 专职和某业务对接的QA
    • 服务某个业务的运营
    • 服务某个业务的客服
    • 服务于一线的PMO

    资源型中台建立的越多,沟通成本就越高,对业务的迟滞阻力就越大。每个团队都有自己的人力规划、资源排期和业务目标。当各个团队的业务目标和自己的业务方不一致的时候矛盾就会展现。业务FTO/业务负责人就常会在这方面收到牵绊。

    赋能型中台

    上面说到的数据中台、技术中台、智能中台(算法中台)、业务中台,属于平台型、业务型,整体上来说通过屏蔽底层细节,建设平台和服务能力,支撑上游业务发展。虽然这些业务中台建立之初有大量的成本投入,整体上还是提效的,免去了很多人从前端到后端,从上层到下层所有东西自己都要动手写一遍,赋能属性是在的。至于能给业务点上几点天赋,这就要看建设方的功力和业务的诉求了。

    本篇总结

    整体上,我比较倾向于资源型中台打散下放业务线,赋能型中台保持短小精干长期聚焦。不要把资源型中台做大的同时,也不要把赋能型中台做没。这样做,对于公司来说整体效能是最高的,成本也是最节约的。

     

    DevOps|中式土味OKR与绩效考核落地与实践
    DevOps|研发效能+项目经理PMO
    AI DevOps | ChatGPT 与研发效能、效率提升(中)
    DevOps|AGI : 智能时代研发效能平台新引擎(上)
    devops|中小公司效率为王,没必要度量

  • 相关阅读:
    C++模拟题[第一周-T1] 扑克
    CREO:CREO软件之工程图界面的简介(图文教程)之详细攻略
    解决Requests中使用httpbin服务器问题:自定义URL的实现与验证
    中央单位高级职称评审委员会备案目录
    OpenCV实战(30)——OpenCV与机器学习的碰撞
    包含BN层的神经网络的学习率优化
    开发一个ebpf程序
    关于mysql本地计算机上的MySQL服务启动后停止。某些服务在未由其他服务或程序使用时将自动停止问题
    记一次线上偶发慢查排查过程_es资源初始化耗时
    踩坑日记 uniapp 底部 tabber遮挡住购物车结算
  • 原文地址:https://www.cnblogs.com/laofo/p/17523344.html