互联网公司R&D效能团队不同组织结构的利弊分析
我们可以将R&D效率团队的工作边界定义为(需求管理+任务管理+项目管理)平台+devops+APM+应用运维，负责从用户需求到上线、应用运维的全过程。它的存在是为了打破团队四分五裂各自为战的局面，同时可以集中各个团队的需求，使整个开发活动顺畅高效的运行。R&D效率团队一旦和某个团队在一起，就没有更高的眼光去思考这件事。如果业务方向控制得好，业务可能会误入歧途。R&D效率接近的团队会专注于团队的业务，服务团队的功能会做得很好，对整个R&D流程的关注度会降低，从而影响R&D效率团队的定位和作用。
我见过R&D效率团队和运维团队在一起。当初，Aauto Quicker的运维合作伙伴也是负责流水线的建设。这是可以理解的，因为运维合作方负责公司的基础设施，公司的服务要想上线运维基础设施，必须要有上线的系统。偷换，运维伙伴也做了流水线，他们只做流水线。流水线前的部分不涉及，因为那些和运维关系不大，受人力物力限制，运维伙伴不涉及流水线前的部分。相比机器运维部分，产研场景更高级，涉及产品经理、项目管理、RD、QA学生的部分，精简、标准化、自动化难度要大得多。这种组合的优点和缺点非常明显:
R&D效率团队和QA团队在一起，我见过这个组织结构。后来组织架构调整，R&D效率团队和QA伙伴在一起。如果R&D效率和QA团队合作形成合力，他们做的事情和影响力绝对高，这是我见过的发挥1+1 & gt；2的组织结构。可惜天时地利都占了，效果却不理想，非常可惜。
根据我长期的观察，我认为主要是用人和定位的问题；本文主要谈定位问题。R&D效率和QA的结合，其实是在两个专业领域发力，然后共同产生更大的成果，而不是在QA平台上长出一个R&D效率平台。Aauto更快效率项目在这方面做得很好。R&D效率团队支持所有的平台建设，通过接口和内部QA自动化测试平台，各自的业务可以按照自己的节奏走，同时在“组合”的功能点上可以互相协作、共建、支持。
R&D效率团队和PMO团队在一起。我也经历过这种组织结构。PMO向业务线的R&D效率团队推广平台，带来用户的诉求，R&D效率支持这些用户的诉求，在日常工作中给予他们支持和帮助。该模式的关键点是R&D效率团队应直接与一线人员挂钩。否则，平台最后很容易变成项目管理平台，最大程度满足PMO伙伴的管理诉求，而不是一线产学研团队小伙伴的诉求。一线团队在那个平台上的工作不切实际，不好用，体验差，都是没做过产研团队的人想象出来的需求；R&D效率团队也非常沮丧。你说的要求我都做到了。其实平台提出的诉求都是“PMO”的诉求，“一线实际用户”的痛点并没有得到解决。
项目管理专家的意见和建议需要得到重视和评估，同时也不能忽视一线实际用户的诉求。当然，这里也有合作的正面例子可供参考。
该表是服务器R&D效率相关工作的一部分。从上表可以看出，每个角色关注的R&D效率域不同，即使在同一个R&D效率域，不同角色关注的也不同。有些公司认为R&D效率和运维团队既是“成本中心”，又是支持团队，于是把R&D效率和运维团队放在一起，组成一个庞大的“基础架构”、“基础平台”或“平台架构”团队。事实上，我们应该从用户的角度将R&D效率团队推向其客户。运维团队并不是R&D效率服务的第一个用户。我们的主要用户是产品经理、项目经理、RD、QA合作伙伴，但是运维团队支持R&D效率团队，最近经常打交道。我们只是运维资源的大客户。
因此，我倾向于成立一个独立的R&D效率小组并行使其职能。如果你必须和其他球队在一起，那么和R&D队在一起是第二选择；只是RD合伙人通常是按业务线/产品线闭环到一个独立的团队，而R&D效率团队作为公共资源很难划分到某个业务线/产品线。第四种方案是和QA组成大团队，有利于质保平台的搭建，最终研发效率和运维一起。
然而，Aauto faster中的效率项目走了一条不同的道路。我们将上述所有支撑平台的生产和研发(包括部分运维平台的建设)划分到一个团队来支撑，相当于R&D效率+QA平台支撑+基础设施平台+运维平台(部分)，避免了重复建设，实现了资源利用的最大化。最后的结果和效果也很好。个人认为1，000人以下的规模可以采用这种组织架构。1000多人可以参考我下一篇文章的内容，主要讲的是2000人左右的R&D效率团队的组织架构和团队建设。