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

 

上期发表了一篇文章「 中小互联网公司研发效能团队规模、职能划分和优劣势分析」, 左一小伙伴就提出来一个问题,研发效能团队必须独立么?这个问题很好,终于从给 svn 打 tag 这类技术问题开始转到团队建设和组织架构问题了。

其实这个问题可以类比一下:

  • RD 团队必须独立么?

  • 产品团队必须独立么?

  • QA 团队必须独立么?

  • 运维团队必须独立么?

  • 设计师团队必须独立么?

这样就容易得到答案了。按照职能来划分,越早独立会越好,1 人也可以是个独立团队,直接汇报高级别领导,独立开展业务;按照人数来思考就是 1-4 个人的时候不是必须成为一个独立的团队,合作、共建、兼职、虚拟团队也许是个不错的选择,但是当团队大了后(4 人或者 4 人以上)成为一个独立的团队就会势在必行。具体什么时候独立,几个人独立,这个和公司定位、已有组织架构、领导认知都有很大关系。

 

「DevOps 研发效能群」:

左一的问题:为啥研发效能团队必须独立?

清川:不独立咋体现价值

韩老师:大小总要有个团队吗?不能兼职是不是?虚拟也是个团队

研发效能团队必须独立么?不是必须,有的团队都没有专职的研发效能工程师,都是其他人员兼职在做,谈不上独立。

有专职的研发效能工程师就必须独立么?也不是必须。较少的研发效能工程师无法覆盖所有的工作职责,更容易孤立,无法提供有效支持。

场景设定:效能团队 1~4 人

讲问题要有背景和场景,唐洪山唐老板指出了这一点,我觉得很好。比如在这篇文章中我们有这样的场景限制

  • 产研人员小于 200 人

  • 效能团队 1~4 人

我们假设就是 100 人的产研团队,分成两个大部门,2 个研发效能支持人员,每人支持一个。其实在这种情况下,2 个人去支持 50 个人还是挺吃力的。这个时候部分职能由其它相应的人员承担才能维护整个研发体系正常运转,比如

  • 每个研发效能小伙伴支持一个业务团队,分别隶属于自己的业务团队

  • PMO 同学监管 Jira 的使用培训和权限分配

  • 运维小伙伴兼职部分研发效能系统维护工作,背 SLA 指标,同时负责数据备份

从上面可以看到,实际上我们虽然只有两个专职的小伙伴,但是通过兼职、共建的合作方式,我们已经是一个四人的虚拟小团队了。区别就在于专职的研发小伙伴支持实际业务,其它共建的任务由其它 PMO、运维甚至 QA 兼职完成。团队小其实对于个人成长有个很大的问题,不容易找到特别资深的人,招到了如果公司发展得慢也不容易留下;招资历比较浅的,又不利于成长,也待不久。

举个例子:

我们部门自打有设计师的时候就是独立的团队,直接汇报给大老板。同时负责部门内的所有产品,最大程度保证所有产品 UI 都在比较高的水平。设计资源最大化利用对于公司也是合理的。

当产研团队成长到 4 个部门,200 人的时候,研发效能的小伙伴也增加到 4 位专职人员。这个时候工作内容和权责就需要梳理下

  • 4 个业务部门,每个业务部门 50 人。每个业务部门都是需要 1 个研发效能的小伙伴支持的「业务支持工作」

  • 4 个业务部门需要支撑的工作量不同,APP 端和服务端两个部门支持工作量巨大,2 个创新部门相对少。「支持工作量差异较大」

  • 公司开始注重规范流程建设,需要统一 4 个业务部门的流程「横向拉通工作」

  • 因为已经有 4 位专职小伙伴,PMO、运维和 QA 的小伙伴期望研发效能团队承担更多的工作「基础设施」

  • 4 位专职的小伙伴资历、能力差异较大。一个刚毕业的小伙伴,一个资深的;一个脚本小子,一个社交达人

 

团队组织架构方案

这个时候我们面临的选择有两个。

方案一、保持虚拟团队

第一个方案是依然保持之前的虚拟团队,每个专职小伙伴负责对应的业务团队支持工作,共建的部分依然由其它团队支撑。存在的问题是:

1)刚毕业的小伙伴态度好但无法独立支撑一个业务线,需要有人带

2)资深员工支撑目前业务线绰绰有余,感到没有新鲜感,想主动承担更多职能向上发展

3)脚本小子做一些脚本没问题但是沟通能力不强

4)社交达人流程梳理、改进、实施这方面给力,脚本能力不行系统管理经验欠缺

 

方案二、独立团队

第二个选择,相关职能合并到一个研发效能团队。资深员工做团队 Lead,带领其他小伙伴一起完成工作。具体做法如下

1)满足了资深员工对管理的诉求,积极性立刻打满

2)校招生得到资深员工的指导,承担更多业务支撑工作,个人成长迅速

3)脚本小子承担小部分支撑工作,同时把大部分精力放到系统稳定,平台建设上

4)社交达人负责整体横向工作,流程改进优化进展神速,工作得到公司领导好评

 

带来的变化 1)资深员工需要培养、提高管理职能 2)每个人各自承担部分业务支撑工作互为备份, 同时也各自承担公共职能。

 

对比结论

通过上面两个方案的对比,人数少的时候直接进入团队,业务闭环,有利于开展业务,更接地气;人数多的时候组成团队更具有韧性,既满足了业务对于研发效能团队的诉求,同时也有利于研发效能团队的稳定,可以人尽其才针对每个人不同的经验和能力分配不同的工作,也满足了员工各自的诉求。

 

按照职能来划分,越早独立会越好,1 人也可以是个独立团队,直接汇报高级别领导,独立开展业务;

 

按照人数来思考,1-4 个人的时候不是必须成为一个独立的团队,合作、共建、兼职、虚拟团队也可以,但是当团队大了后(4 人或者 4 人以上)成为一个独立的团队就会势在必行。

 

具体什么时候独立,几个人独立,这个和公司定位、已有组织架构、领导认知都有很大关系。

 

参考资料:

 

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

 

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

 

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

posted @ 2022-06-10 08:49  laofo(公众号scmroad)  阅读(1000)  评论(1编辑  收藏  举报