这是「研发效能团队规模、职能划分和优劣势分析」系列的第四篇。上篇文章「中小互联网公司研发效能团队规模、职能划分和优劣势分析」主要分析产研团队在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-研发效能部

• 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，这段是更有意思也更有价值的部分。为什么呢？

• 人力成本剧增。每个互联网公司，人力成本都是个大头。每增加一个产研同学，人力成本线性增加，但是研发效能却不会线性增加，还可能因为协作不当增加更多的沟通成本团队产能反而下降。
• 日积月累的技术债、技术坑：攻城略地带来业务增长的同时，也在身后留下了很多需要还的技术债、需要填的技术坑。之前靠堆人做的事情，现在该考虑下高效的做法了。
• 修炼内功，降本增效：当行业增速没那么大的时候，做好内部基础设施建设也是提高公司行业竞争力的有效手段。研发效能带来的效果和团队规模有关，而且是一个乘法关系。团队规模越大，做好研发效能对企业带来的效率和质量的提升越高。

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

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

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

组织架构优势

• PMO始终在研发效能下，平台工具+PMO一起下业务线推广对EE的发展特别有帮助；PMO从业务线收集到的用户诉求，部分会转化为对效能平台的需求
• 架构部和研发效能组织上离的比较近，所以有很多框架和技术工具方面的共建会比较好推进，比如工程规范、框架推广等
• 运维部和研发效能部组织上离的也比较近，我们的很多基础设施依托于运维部的支持，互相合作，比如发布功能，重启、灰度、资源管理等
• 统一支撑产研协作的基础设施（包含QA平台建设），资源利用最大化，边界合理清晰。

团队劣势

• 研发效能团队和运维团队的边界需要明确，实际上有时不是那么清晰的，需要双方负责人识大体，顾大局。效率工程部解决这个问题的方法比较简单，涉及用户部分的产品开发工作都放在研发效能团队负责，系统管理部分运维团队可自建。
• 因为没有「大QA部门」，研发效能团队对QA团队对业务诉求感知度低，需要通过不断合作和共建来推进工作。

实操经验总结

• 找对人
• 人，是第一生产力。研发效能这个领域比较专精，招聘时需要好好区分。怎么招人可以参考这篇文章「找到能做好研发效能的人」。做不出东西来方向找的不对事小，把业务做烂了影响公司发展事就大了。
• 这方面的专家一般来自项目管理、配置管理、QA、流程改进，运维，这些人都是有实际平台操作经验的；随着云计算、云原生的发展，应用运维、少部分架构、研发也进入了这个领域。现在可以直接招聘「研发效能」「工程效率」「DevOps」相关的人了。招就要招你能招到的最好的人，这都是宝贵的人才，尤其是一线大厂的人是很难找的。比如阿里云效团队、蚂蚁研发效能团队，腾讯TEG、PCG，美团研发质量与效率部、百度效率云、滴滴EP等，实在找不到人可以去这几个大厂挖，当然他们这些团队也同时都在招人，感兴趣的也可以去联系 :)
• 只要找对了人，后面就好办了。牛人是自带光环的，相应的团队怎么构建，公司需要迫切在哪方面投入、招聘什么样的人来做什么事情……只要招来对的人这些事情就都能迎难而解。关键是招到对的人，这是破局关键。
• 搭好班子
• 组织架构是第二生产力。搭建好适合业务发展的组织架构才能最大限度发挥人才的作用。招来了牛人不能摆着，要给他配团队配资源。巧妇难为无米之炊，巧妇已经让咱给请回来，我们就要给她找洗碗的、配菜的、传菜的，这样才能做出一席好菜。找不到牛人做的东西烂，我们也就认了；如果找到了牛人，不会用，用不好那也是挺可惜的。
• 走正路
• 毕竟下面团队了解到的信息有限，很多时候上层可以给出更多的背景信息，这样大家一起找到一条可以实现的正路子。这就要因地制宜，相机而动。时机太重要了，很多时候转瞬即逝，一旦失去，后面千辛万苦未必能成。所以都在说天时地利人和，而不是地利人和天时，或者人和地利天时。
  愿各位能找到不错的公司、不错的领导、不错的团队，此生尽兴、赤诚善良，做自己擅长也喜欢做的事。

推荐阅读

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

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

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

转 https://www.cnblogs.com/laofo/p/10kee.html