这是「互联网公司研发效能团队建设」的第二篇。为啥研发效能要是一个相对独立的团队呢？独立的研发效能团队是最大化行使职能的必要保障。我一直认为组织架构是第二生产力(第一是人)。搭好台子好唱戏。台子左右不平，前高后低，再大的角都可能崴脚跌跟头。

目前累计服务客户成百上千家，积累了丰富的产品开发及服务经验。以网站设计水平和技术实力，树立企业形象，为客户提供网站设计制作、成都网站设计、网站策划、网页设计、网络营销、VI设计、网站改版、漏洞修补等服务。创新互联始终以务实、诚信为根本，不断创新和提高建站品质，通过对领先技术的掌握、对创意设计的研究、对客户形象的视觉传递、对应用系统的结合，为客户提供更好的一站式互联网解决方案，携手广大客户，共同发展进步。

最近在想一个问题：研发效能算公司业务还是算基础平台、技术中台、技术工具？怎样才能做得更好？

我们可以定义研发效能团队的工作边界是(需求管理+任务管理+项目管理)平台+devops+APM+应用运维，负责从用户需求提出到上线、到应用运维的整个过程，它的存在就是为了打破团队之间割裂、各自为战的情况，同时可以把各个团队共性的需求集中统筹，使整个开发活动能够顺畅、高效的运行。研发效能团队一旦和某一个团队在一起，却没有更高的视野去思考这个事情，把控好业务方向，业务可能就会跑偏。研发效能靠近哪个团队，就会侧重哪个团队的业务，对哪个团队服务的职能就做得好，对整个研发过程的关注度就会降低，从而研发效能团队的定位和作用会受到影响。

研发效能+运维团队

研发效能团队和运维团队在一起，这种组织架构我是看到过的。一开始快手的运维小伙伴也同时负责流水线部分的建设。这个是可以理解的，因为运维小伙伴负责公司的基础设施，公司的服务想要上线到运维的基础设施上必然要有一个上线系统。顺手牵羊，运维小伙伴就把流水线也给做了，他们也只做到了流水线。流水线之前的部分就没参与，因为那些和运维关系不大，同时受限于人力物力，运维小伙伴就没涉及流水线前面的部分。和机器运维部分相比，产研场景更靠前，涉及产品经理、项目管理、RD和QA同学部分的流程化、标准化、自动化要难得多。这种组合优劣势非常明显：

优势：

• 部署和监控日志告警、运维系统衔接得很好
• 部署时的各种模板也很贴心，满足了各种「业务」的需要
• 从源码到上线都可以通过流水线完成，功能集中在一个系统中，不像字节各种平台间跳转
• 和资源、硬件、中间件的部分都被隔离了，降低了上层建设的复杂度

劣势：

• 正因为模版过多，导致使用起来也需要一定的成本
• 流水线部分虽然有代码扫描，但是没有把结果更好地反馈到代码管理中，有点脱节
• 对流水线之外的任务管理、项目跟踪、代码评审、线下环境等不涉及
• 对研发过程关注度不够，没有形成产研整个过程的闭环，产研数据不全难以全程有效度量
• 对QA工具和环境建设也待加强

研发效能+QA团队

研发效能团队和QA团队在一起，这种组织架构我是看到过的。后来组织架构调整，研发效能团队就和QA小伙伴在一起了。如果研发效能和QA团队在一起形成合力，做的事情和影响力绝对高高的，这也是我见到的能最好地发挥1+1>2的组织结构。只可惜天时地利都占了，效果却并不理想，非常可惜。

优势：

• 统一了公司内部QA域内的众多工具的建设，把所有QA工具都集成到了一个平台上
• 对质量、测试用例、测试报告、测试数据、压力测试等非常重视

劣势：

• 对需求、任务管理、迭代跟进等重视不够
• 做出的平台质量差，用户吐槽不断对平台失去了信心和耐心

根据我长期的观察，觉得主要是用人+定位的问题；这里主要谈定位的问题，研发效能+QA这个组合，其实是在两个专业领域发力，然后在一起的合力产生更大的效果，而不是在QA平台上长出一个研发效能平台。快手效率工程在这一点上则做的不错，研发效能团队支持所有的平台建设，通过接口和内部的QA自动化测试平台进行打通，各自业务都能按照自己的节奏走，同时还可以在「结合」的功能点上进行合作、共建、互相支撑。

研发效能+PMO团队

研发效能团队和PMO团队在一起。这种组织架构我也经历过。PMO在业务线给研发效能团队推广平台，带来用户诉求，研发效能支撑这些用户诉求并在日常工作中给予支撑和支持。这种模式的关键点是研发效能团队要直接扎到一线人员中。否则平台最后容易成为一个项目管理平台，最大程度满足了PMO小伙伴的管理诉求，而不是一线产研团队的小伙伴的诉求。一线团队在那骂平台做得不切实际，不好用，体验差，都是没做过产研团队的人臆想的需求；研发效能团队也很叫屈，你说的需求我都做了啊。实际上平台做的需求都是「PMO的」需求，并没有解决「一线实际用户」的痛点。

优势：

• PMO可以从项目管理的角度推广、运营平台，帮平台收集用户反馈
• PMO可以带来高层的管理诉求和意见
• 研发效能团队对PMO的支撑也有助于平台项目管理流程的平台化、产品化，项目进展的可视化

劣势：

• PMO收集到的用户需求可能是伪需求，需要认真甄别
• 一线用户的诉求不能直接反馈到平台建设方
• 会不自觉地提高管理诉求的优先级，影响平台需求的正常排期和发展

项目管理专家型的意见和建议，需要认真对待和评估，同时千万不能忽视一线实际用户的诉求。当然这里也有合作正向的例子可以参考。

举个：

第一个例子是五八同城的PMO团队和平台建设团队是在一个大团队下。PMO遇到一线小伙伴的问题，通常会拉着平台建设团队的小伙伴一起解决，所以做平台的小伙伴能直接接触到这些诉求，然后进行独立的评估和出解决方案，而不是加工过的「二手信息」。滴滴EP在这一点上做的更进一步，通常是建立合作专项，PMO的小伙伴不传二手信息，直接帮团队间拉通、跟进需求进度，更有助于问题的解决和方案落地。（后面我们会有单独的文章详细说）

不同组织架构效果不同