其他分享
首页 > 其他分享> > 互联网公司研发效能/工程效率团队建设和规划

互联网公司研发效能/工程效率团队建设和规划

作者:互联网

 

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

 

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

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

 

研发效能+运维团队

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

优势:

劣势:

 

研发效能+QA团队

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

优势:

劣势:

 

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

研发效能+PMO团队

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

优势:

劣势:

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

举个:

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

不同组织架构效果不同

互联网公司研发效能/工程效率团队建设和规划

 

此表格为服务端研发效能涉及的部分工作。从上面的表格,我们就可以看到每个角色关注不同的研发效能域,即便是同一研发效能域,不同角色的关注度程度也不一样。有的公司觉得研发效能和运维团队都是公司的「成本中心」,都是支撑团队,于是把研发效能和运维团队放到一起,组成一个大的「infra」、「基础平台」或者「平台架构」团队,实际上应该从用户的角度出发,把研发效能团队推向他的客户身边。运维团队并不是研发效能服务的第一用户,我们的主要用户是产品经理、项目经理、RD和QA小伙伴,只是运维团队支撑研发效能团队,离我们最近经常打交道,我们是运维资源的大客户而已。

 

所以我更趋向于成立独立的研发效能团队、行使职能。如果非要和其它团队在一起,那么和研发团队在一起,这是第二选择;只不过因为RD小伙伴通常以业务线/产品线进行闭环到一个独立的团队,而研发效能团队作为公共资源又很难划分到某一业务线/产品线。第四选择是和QA组成一个大团队,这种组合有利于质量保证平台的建设,最后是研发效能和运维在一起。

 

而快手效率工程走了另外一条路,我们把以上所有支撑平台的产研(包含部分运维平台的建设)都划分到一个团队去支撑,相当于研发效能+QA平台支撑+基础架构平台+运维平台(部分),避免了重复建设、同时资源利用最大化。最后取得的结果和效果也很不错,我个人认为在1000人以下的规模可以采取这种组织架构。千人以上可以参考我下篇文章的内容,主要讲了产研团队在2000人左右,研发效能团队的组织架构和团队建设。

 

插播一则小感悟,近日新东方老师董宇辉中英双语穿插历史文化+才艺式带货,让新东方带货平台「东方甄选」短短几日粉丝数量狂增数百万。港股新东方在线也立刻给予了响应,两个交易日累涨95.08%。这就是人才的力量。

 

 

相关文章:

互联网公司研发效能团队为啥必须独立?何时独立? 

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

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

研发效能团队规模、职能划分和优劣势分析概述

   

标签:运维,效能,平台,研发,QA,互联网,团队
来源: https://www.cnblogs.com/laofo/p/eeteamarch.html