美文网首页配置管理DevOps研发效能
千人规模互联网公司研发效能成功之路

千人规模互联网公司研发效能成功之路

作者: 研发效能D_laofo | 来源:发表于2022-07-07 10:23 被阅读0次

    这是「研发效能团队规模、职能划分和优劣势分析」系列的第四篇。上篇文章「中小互联网公司研发效能团队规模、职能划分和优劣势分析」主要分析产研团队在 200 人以下的中小公司现状以及给出一些建议。本篇文章主要分析产研团队在 1000 人规模的二三线中型互联网公司研发效能现状,并结合自己的切身体会,在组织架构、工作职责、优劣势、以及怎么干怎么拿到结果,给出了自己的一些建议。

    公司规模

    • 产研团队 1000 人左右

    • 团队规模:10-30 人左右

    组织架构

    产研团队从 200 人到 1000 人是一个很大的跨越,领域细分、职能细分、管理职能也会上线。细说一下这几点不同:

    • 管理职级:开始出现管理职级。之前公司比较扁平,恨不得 CEO 下面就是员工。但是人到 1000 的时候就会分级了。老板也管不了那么多人,需要分级管理。网上的建议是一般中高层管理者一个人管理 5—8 人,最好是 7;基层管理者一个人管理 10—15 个人,最好是 12。

    • 领域细分:200 人的公司,可能产品研发测试运维都一个人担了,但是 1000 人的公司很少有这种情况发生。首先一个人很难在这么多领域知识都专精;其次都专精的人肯定价格很高,除非公司合伙人否则 200 人的公司很难留下这样的大牛;最后一个人再能干毕竟精力有限。大公司招到这样的人也会把他放在一个很高的位置,站在更高的位置提升团队效能,做好管理,然后让专业的人干专业的事。这也是我强调专业分工、协同合作理念的原因。

    • 再多说一句就是,在外企可能通过技术升上去级别很高但一个人都不带的人很多,但是在国内这种情况非常非常的少。比如在快手有几个技术达到最高级的大佬,也都是挂了一个管理职级的。

    • 专业团队:200 人的团队可能仅有一个设计师,汇报关系可以简单些,但是 1000 人规模时有 10 个设计师,这个时候就需要单独成立一个 UI/UE 团队,甚至是设计中心;之前零散在各个团队中的 PMO 也会收拢到一个团队;之前找个写 SQL 的出出报表就可以了,现在一般会建立单独的大数据团队,数据分析团队,AI 团队等,在 200 人的时候肯定会有人做类似的事情,但很少会作为一个专业团队的形式存在。很多事情,一旦上了规模就会有很大不同,包括产品架构、实现方式、性能指标要求等。

    研发效能团队就是一个在研发基础设施建设领域细分的专业团队。一个可选的组织架构如下图。


    CTO-研发效能部.png

    组织架构:CTO-研发效能部

    • PMO 团队职责:推动战略项目落地,支持研发项目管理和交付,确保有效执行;搭建项目管理体系,完善流程制度;促进跨部门协同;识别潜在风险并推动问题解决

    • 平台产品:产品规划,制定产品发展策略,并推动落地;负责竞品研究,行业研究,了解前沿的技术和产品发展思路,并能够制定有竞争优势的发展路径;了解需求场景,抽象制定平台需求

    • 平台研发:负责平台产品的预研、架构、研发;负责平台架构设计与深度优化;紧跟业界前沿,针对不断增长的业务需求提供技术解决方案。

    • 平台运营:负责平台产品的整体运营管理,针对平台产品自身特点以及市场状况制定产品运营规划、战略、布局并实施;负责产品的定位、媒体宣传、市场推广、渠道建设和客户服务的整体策略和计划的制定和实施;组织产品运营数据分析和市场状况分析,根据分析结果指导运营策略制定和实施;

    这个组织架构图和 15 年五八同城 TEG 情况比较相似,那个时候全公司的产研团队就是 1000 人左右,把支撑企业级跨产品、跨项目的综合能力集中在一个部门,提高人才和专业密度,互相协作把思想、策略、实践注入到平台上产品中,打造了支撑通用研发能力的实践平台 iWork,也就是五八同城的一站式研发管理平台,研发效能团队主要能力已经都集中到了这上面,功能完备,体验一致,全流程打通,一站式解决产研工作中的大部分问题,有效提高了产研效能。在五八待过的产研小伙伴肯定知道这个平台。

    滴滴研发效能团队和此组织架构有很大不同。17 年初滴滴产研团队已经 4000+了,和本文的主要参考产研规模有很大出入。滴滴研发效能起步早、起点高,做得更专业更细分。滴滴研发效能团队在 EP 部门下,EP 下除了研发效能,还有体量更大的企业信息化业务。在实际运行时会把平台产品、平台研发和平台运营纵向切分成一个个特性团队(Feature Team)负责一个个的产品。我觉得这是非常好的一种做法,后面我会专门有一篇文章来介绍 FT 的工作机制。有人问 QA 小伙伴在哪里?其实我一直有一个观点:负责实际业务日常交付的 QA 团队单独成为一个团队,很难贴合业务发展,不符合 FT 的风格。针对业务功能测试的 QA 小伙伴,应该直接划分到业务线,贴近业务保证质量,业务闭环,职能闭环,权责闭环;做工具、平台的 QA 小伙伴应直接并入研发效能,形成一个产研基础设施团队(infra team)统一支持产研工具平台的建设。

    举三个例子:

    我加入五八同城比较晚,「据说」当初也是有个大 QA 部门,后来给拆了。留了一部分在 TEG,其它也都划分到业务线。

    滴滴的质量部一开始也是 500 人+ 的大部门,后来打散,负责业务测试的直接划分到业务线;做 QA 工具、平台很大一部分直接划分到了效能平台部(EP)。

    快手的质量与效能部人数最多的时候有 700 人?比很多业务部门的人数还多。实行没两年,直接打散,负责业务测试的直接划分到业务线;做 QA 工具平台的部分直接划到了基础技术部。

    快手的质量与研发效能部最初有这个组织架构的影子,除了 PMO 是在 CTO 下,其它大部分相同,不过质量与研发效能部最后也被拆了。

    其实我最近一直在思考 PMO 的位置应该在哪里?直接汇报 CTO,手持尚方宝剑,上斩业务大佬下斩小喽啰,成为管理各个业务线的抓手;还是成为业务线老板的业务助手,在项目管理上出谋划策、为业务老板分忧解难,解决产研同学做业务中遇到的实际问题?如果你有好的建议,也请告诉我,谢谢。

    发展策略

    在产研团队 1000 人的公司,研发效能团队的主要职能和产研团队在 200 人的公司有很大的差异。产研团队在 200 人的公司,研发效能团队主要职能在维护一套用开源+商业软件搭建的研发基础设施,保证基础设施可用、稳定,只能解决有无的问题。毕竟人力和资源有限,主营业务更需要多投入。但是到产研团队在 1000 这个数量级,其实我们已经有资源去做更多更好的基础设施建设了,开始做 1 到 N,这段是更有意思也更有价值的部分。为什么呢?

    • 人力成本剧增。每个互联网公司,人力成本都是个大头。每增加一个产研同学,人力成本线性增加,但是研发效能却不会线性增加,还可能因为协作不当增加更多的沟通成本团队产能反而下降。

    • 日积月累的技术债、技术坑:攻城略地带来业务增长的同时,也在身后留下了很多需要还的技术债、需要填的技术坑。之前靠堆人做的事情,现在该考虑下高效的做法了。

    • 修炼内功,降本增效:当行业增速没那么大的时候,做好内部基础设施建设也是提高公司行业竞争力的有效手段。研发效能带来的效果和团队规模有关,而且是一个乘法关系。团队规模越大,做好研发效能对企业带来的效率和质量的提升越高。

    在这个规模,我建议开源+商业软件+部分自建,虽然整体体验有损失,但是可以在最小投入下最大程度满足功能性需求,同时在有限的资源条件下加大自研部分占比,提高整体水平。

    研发基础设施的建设绝非一朝一夕之功,呼噜呼噜招一帮人想做个几个月就能解决基建的问题就太乐观了。否则脉脉上也就不会出现那么多对基础设施的吐槽。

    基建差吐槽.png

    唯二大家都很赞的团队是美团和阿里,证明这两家的基础设施建设大家都还是非常认可的。


    meituanjijian.png

    组织架构优势

    • PMO 始终在研发效能下,平台工具+PMO 一起下业务线推广对 EE 的发展特别有帮助;PMO 从业务线收集到的用户诉求,部分会转化为对效能平台的需求

    • 架构部和研发效能组织上离的比较近,所以有很多框架和技术工具方面的共建会比较好推进,比如工程规范、框架推广等

    • 运维部和研发效能部组织上离的也比较近,我们的很多基础设施依托于运维部的支持,互相合作,比如发布功能,重启、灰度、资源管理等

    • 统一支撑产研协作的基础设施(包含 QA 平台建设),资源利用最大化,边界合理清晰。

    团队劣势

    • 研发效能团队和运维团队的边界需要明确,实际上有时不是那么清晰的,需要双方负责人识大体,顾大局。效率工程部解决这个问题的方法比较简单,涉及用户部分的产品开发工作都放在研发效能团队负责,系统管理部分运维团队可自建。

    • 因为没有「大 QA 部门」,研发效能团队对 QA 团队对业务诉求感知度低,需要通过不断合作和共建来推进工作。

    实操经验总结

    * 找对人

    • 人,是第一生产力。研发效能这个领域比较专精,招聘时需要好好区分。怎么招人可以参考这篇文章「找到能做好研发效能的人」。做不出东西来方向找的不对事小,把业务做烂了影响公司发展事就大了。

    • 这方面的专家一般来自项目管理、配置管理、QA、流程改进,运维,这些人都是有实际平台操作经验的;随着云计算、云原生的发展,应用运维、少部分架构、研发也进入了这个领域。现在可以直接招聘「研发效能」「工程效率」「DevOps」相关的人了。招就要招你能招到的最好的人,这都是宝贵的人才,尤其是一线大厂的人是很难找的。比如阿里云效团队、蚂蚁研发效能团队,腾讯 TEG、PCG,美团研发质量与效率部、百度效率云、滴滴 EP 等,实在找不到人可以去这几个大厂挖,当然他们这些团队也同时都在招人,感兴趣的也可以去联系 :)

    • 只要找对了人,后面就好办了。牛人是自带光环的,相应的团队怎么构建,公司需要迫切在哪方面投入、招聘什么样的人来做什么事情......只要招来对的人这些事情就都能迎难而解。关键是招到对的人,这是破局关键。

    * 搭好班子

    • 组织架构是第二生产力。搭建好适合业务发展的组织架构才能最大限度发挥人才的作用。招来了牛人不能摆着,要给他配团队配资源。巧妇难为无米之炊,巧妇已经让咱给请回来,我们就要给她找洗碗的、配菜的、传菜的,这样才能做出一席好菜。找不到牛人做的东西烂,我们也就认了;如果找到了牛人,不会用,用不好那也是挺可惜的。

    * 走正路

    • 毕竟下面团队了解到的信息有限,很多时候上层可以给出更多的背景信息,这样大家一起找到一条可以实现的正路子。这就要因地制宜,相机而动。时机太重要了,很多时候转瞬即逝,一旦失去,后面千辛万苦未必能成。所以都在说天时地利人和,而不是地利人和天时,或者人和地利天时。

    愿各位能找到不错的公司、不错的领导、不错的团队,此生尽兴、赤诚善良,做自己擅长也喜欢做的事。

    推荐阅读
    研发效能团队的规模、职能划分和优劣势的意义和价值

    中小互联网公司研发效能团队规模、职能划分和优劣势分析

    一二三线互联网公司划分标准和榜单

    相关文章

      网友评论

        本文标题:千人规模互联网公司研发效能成功之路

        本文链接:https://www.haomeiwen.com/subject/uqoubrtx.html