研发效能负责人/研发效能1号位 |DevOps负责人

研发,效能,负责人,devops · 浏览次数 : 399

小编点评

**团队1号位的职责** * 与其他部门协调、资源和预算管理、绩效考核。 * 作为领域专家,胜任以下专业能力: * 大局观 * 分清轻重缓急,解决怎么做的问题 * 有打法:规划出能达到目的地的可行的路径 * 解决怎么做的问题能打仗打胜仗:按照规划目标达到目的地的能力 **不同背景的优劣势** | 背景 | 优点 | 劣点 | |---|---|---| |领域专家 | 丰富经验,对业务发展有深理解 | 缺乏软技能,缺乏团队合作能力 | |QA | 关注质量,对支持产研工作本身的平台建设和实践可能关注少做后台开发的人会好些 | 缺乏业务经验,对业务素质评估不全面 | |QA | 关注质量,对支持产研工作本身的平台建设和实践可能关注少做后台开发的人会好些 | 缺乏软技能,缺乏团队合作能力 | |研发人员 | 技术能力强,可以自行解决问题 | 缺乏业务经验,对业务素质评估不全面 | |研发人员 | 技术能力强,可以自行解决问题 | 缺乏软技能,缺乏团队合作能力 | |产品经理 | 业务分析能力强,可以帮助团队更全面地了解业务需求 | 缺乏研发技能,无法参与到研发流程中 | **如何找到团队1号位** * 从内部招聘网站上寻找 * 参加招聘会 * 通过社交媒体招聘 * 通过招聘网站招聘 **其他建议** * 找一个能够帮助团队建立和提升软技能的人来担任团队1号位。 * 鼓励团队成员互相分享经验和知识。 * 定期评估团队1号位的绩效,并提供反馈。

正文

想要做好业务,老板们除了要梳理好公司级别的业务目标,公司的组织架构,还要搭个有产出的班子,也就是找负责人、建团队,让组织架构充实起来。搭班子最重要的就是把负责人找到,就是团队1号位的人。本文主要讲团队负责人的主要作用,怎么才能找到,不同背景的优劣势,以及各方面的要求。

研发效能团队1号位

「火车跑得快,全靠车头带」。团队1号位的能力,基本上决定了这个团队的上限。所以我们在邀请1号位的时候要格外严格筛选。他除了要负责与其他部门协调、资源和预算管理、绩效考核等管理职责,作为领域专家还要胜任以下专业能力:

  • 有大局观,有能力:能站在公司和团队的角度,根据公司战略和业务诉求,制定业务发展的长期规划和短期目标。分清轻重缓急,解决做什么的问题。

  • 有打法:有能力规划出能达到目的地的可行的路径。解决怎么做的问题

  • 能打仗打胜仗:业务素质过硬,能打仗且打胜仗,即按照规划目标达到目的地的能力。我自己能做。

  • 带团队带队员:带领团队、激发团队推动业务发展,培养团队成员。我也可以带团队做。

     

好像没有对比就体现不出业务能力的差距,当然也看不到伤害,那就举几个1号位曾经提的问题:

- 为啥要有制品库?去掉制品库,都放到 svn 统一存多好。- nexus干嘛的?让研发自己去下载 jar包,我们就不用维护 nexus了,也就又少一事- 项目版本为啥是三位数?构建的包为啥四位版本号?能否统一用时间戳? - 一站式研发管理平台为啥要管源代码?项目管理和源码要拆分到两个系统- 不要搞 jar包的稳定版本,线上都发快照- 你给我一些输入,我计划下团队这个季度的OKR- 为啥公司里既有 svn 还有 gitlab?为啥xx公司都用 svn 就没事?- 公司半年总结,你总结下团队半年都做了啥,我开会时用

缺少领域把控能力,团队1号位容易变成「上下两级」的传话筒。 

案例分享:曾经听说过一位研发效能团队负责人,他之前从未做过研发效能工作,上级领导每次要求什么就都记下来,接着和团队下面每个人去聊。每个人聊过之后,开会讨论,然后会上让大家发言,发言时开始质疑每个人的看法。拿到结果和上级去汇报。

- 为啥是每个人?因为自己不懂,对团队下面的人又都不放心,每个人都问一遍,答案可以互相印证下。

- 为啥是开会质疑?告诉你们我懂的,别忽悠我。

- 为啥质疑团队成员后经常被怼?因为团队成员告诉他的答案是有上下文的,有侧重点考虑的。他质疑的时候往往抛弃了这些。

- 开完会,拿着团队的方案和上级领导去交差,问到细节又不懂,开会回来怼团队。

- 为啥不带着团队下面的人去开会?带着你们开会显得我多没本事。另外那是我们领导级别的会咋可能让你们去。

- 每次要把团队内的文档给领导看时,都会复制出来一个只有自己修改记录的新文档

 

经过几轮这样的沟通之后,下面人的脑袋都开裂了。

通常来说,作为业务1号位,要有随时可以做-2 层人员工作的能力。如果研发效能团队1号位对这个领域没有足够的认知,团队规模越大,1号位对业务的发展、对团队的发展带来的阻碍甚至是伤害也就越大。所以说业务能力是最重要的。业务1号位必须是这个领域的专家。

团队1号位的背景

领域专家非常少,找到真能独当一面的领域专家比较难,尤其是有过一线实际「操盘」经验的1号位。这个时候我们就要考虑招什么样的人来带领这个团队了,甚至来搭建这个团队。虽然都是领域专家,但是领域专家的背景也可能不同。不同背景的人可能有不同的侧重

  • 做上层业务的可能对基础设施建设不感兴趣,毕竟这块业务投入高时间长效果慢。我看到很多之前做业务的人来做基础设施建设这块,没多久就又做业务去了。

  • 传统运维背景的人对底层基础设施建设会比较注重,但是对业务体感低。这种情况我也见到过,对效能这块没想法,也不感兴趣; 

  • QA背景的人,可能更关注质量,但对支持产研工作本身的平台建设和实践可能关注少

  • 做后台开发的人会好些,但是有可能对效能不感兴趣转去做公司主营业务,另外就是把研发效能当作只是开发一个工具来看待,会做出一堆东西,但是工具不好用,用户不想用,对公司帮助有限,平台还不想改。我亲生的,怎么有可能错。

  • 长期做管理的人可能远离一线,实操不行。

 

总之,我们要好好衡量,我们现在最需要补充的是哪方面的能力,而候选人的强项是哪些。如果员工和公司能同时成长,互相成就那就再好不过,如果不能,那么互相暂时拥有也挺好。员工对公司再好,公司也会开人;公司对员工再好,员工也要跳槽。单相思,始终是一种病态,最好还是互相奔赴,即便离开也互不赊欠。

团队1号位更要注重软素质

不同阶段的公司1号位的要求也许不同,但该具备的软素质始终都是要有的,比如正直、诚实、勤奋、上进、基本职场共识、自驱、靠谱

曾经遇到这样一个案例,我们有一个需求,团队评估了下大概2周左右能完成,交给一个小伙伴来做。结果这个小伙伴前前后后做了3个月没有完成。

团队初创时期,业务还不确定,风险很高,对人的要求也是最高的,但最重要的是包括人品在内的基本素质。前期招进来的每一个人都是公司春天种下去的希望的种子。每个人都是独当一面的,如果基本素质不过关,给公司带来的风险和危害也是最大。大家都尽量没有短板,能独当一面又能互相补位。

自驱也很重要。团队1号位刚进来,一片空白,百废待兴,很多时候都要自己去规划要做什么,做到什么程度,怎么做,谁来做,什么时候要有什么产出。如果团队1号位没点自驱力,那这个团队难以很快建立起来,业务也很难开展。

软素质对于每个团队成员都很重要,尤其是团队1号位就更重要了。

 

哪里找到这样的1 号位

打入这个圈子,找到这个圈子最好的人聊一下。没错,我们就有一个这样的「研发效能DevOps」的圈子,关注文末,猛戳我们的公众号。

 

本文总结

团队1号位要找到你能找到最好的那个人,基本素质要硬,人品素质硬,业务素质更要硬。既要也要又要到典型,没办法,团队1号位真的很重要。没有人品,待得越久危害越大;没有业务素质,一开始都待不下去或者只能「圆滑地」混下去,慢慢地容易把团队和业务带着向下走,甚至带没了,这样的案例太多了。

推荐阅读

产品经理,项目经理,FTO

高效能敏捷交付团队反思:特性团队(FeatureTeam)+Scrum

什么是研发效能?研发效能定义及核心价值

研发效能生态完整图谱&DevOps工具选型必看

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

找到能做好研发效能的人

 

感谢点赞、转载
关注我,了解研发效能发展动向
欢迎进入「DevOps研发效能群」一起探讨

与研发效能负责人/研发效能1号位 |DevOps负责人相似的内容:

研发效能负责人/研发效能1号位 |DevOps负责人

想要做好业务,老板们除了要梳理好公司级别的业务目标,公司的组织架构,还要搭个有产出的班子,也就是找负责人、建团队,让组织架构充实起来。搭班子最重要的就是把负责人找到,就是团队1号位的人。本文主要讲团队负责人的主要作用,怎么才能找到,不同背景的优劣势,以及各方面的要求。 研发效能团队1号位 「火车跑得

DevOps|研发效能团队组织架构和能力建设

研发效能团队相对于各个公司主营业务规模来说并不是很大,但是在经历的几家公司里主要是有两种组织架构,职能独立型组织架构和业务闭环型组织架构。本文主要讲解这两种组织架构的特点、优劣、劣势。 业务闭环组织架构 这里引入了一个概念-特性团队,以及特性团队的负责人(FTO),更多的内容在我之前的文章《研发效能

质效提升 | QA不做业务需求测试,你怎么看?

​因为有的小伙伴看到公司的QA不测试业务需求,只搞流程、卡点、规范、技术创新、QA平台,行业洞察,让研发自测、研发担责上线bug和风险,所以问我,你怎么看QA不做业务需求测试这件事。其实我怎么看不重要,这事还是要看公司管理层和QA负责人,我个人倒是可以作为一个业务方来聊一下这件事。 企业架构 公司组

Seal AppManager如何基于Terraform简化基础设施管理

> **作者简介** > > 陈灿,数澈软件Seal 后端研发工程师,曾在腾讯负责敏捷研发体系建设以及 DevOps 解决方案的敏捷实践。在敏捷研发和产品效能提升有着丰富的经验,致力于构建一站式研发友好的平台工程解决方案。现在是 Seal 平台工程团队核心研发人员。 平台工程(Platform En

研发效能|DevOps 已死平台工程永存带来的焦虑

最近某位大神在推特上发了一个帖子,结果引来了国内众多卖课机构、培训机构的狂欢,开始贩卖焦虑,其实「平台工程」也不是什么特别高深莫测的东西。闲得无聊,把这位大神的几个帖子薅了下来,你看过之后就会觉得没啥,都是熟悉的东西。 Sid Palas & 平台工程 这位大神的名字叫 Sid Palas,一位专门

研发效能DevOps推荐书单

专注 300 页之内的经典书籍推荐 研发效能涉及的知识很多,从大的方向去划分包括制度、组织、平台、运营等;单从软件研发的角度去看也包括很多,包括最底层的软工认知、实践,到团队管理和组织、敏捷研发,项目管理、源码管理、发布管理、可观测性,到产品的运营和反馈。 现在很多公司已经组建了或者正在组建研发效能

研发效能|DevOps 是运维还是开发?

DevOps 到底是 Dev还是Ops?答:属于研发工程师序列,偏向研发域,而不是运维域。 DevOps是研发工程师 DevOps 主要服务的对象就是所有产研团队的人员,与产研团队打交道比较多,相互配合更多,所以 DevOps 划分到 Dev 一侧比较好。 Ops 更专注底层基础设施,IaaS,Pa

DevOps|研发效能解决的是企业效率问题

研发效能并不能解决企业效益问题 它不是利润中心,不能给你带来直接收入(研发效能相关工具厂商做咨询、出方案、卖工具除外)。想要解决企业效益问题,依赖于企业战略、业务/产品、组织、运营、创新等其他方面。 研发效能解决的是企业效率问题 研发效能解决的是企业内部「产研运协作效率」的问题。 企业最需要两种涉及

DevOps|研发效能不是老板工程,是开发者服务

有人说研发效能是老板工程。不是的,研发效能不是老板工程,它不直接服务于老板(虽然老板可能看一些报表),反而是服务于广大产研运(产品+研发+质量+运维)的同学,所以有的公司也把研发效能叫做基础中台,平台工程,开发者服务团队,或者叫开发者服务平台。做好研发效能,做好开发者中台,就容易把公司的各种中后台能

DevOps|研发效能价值如何衡量

现在很多公司都在做或者计划做研发效能,也知道研发效能工作很重要,能提高产研运同学的协同效率,提高员工的工作效率和质量,提高业务交付效率和交付质量,但是价值有多大?效率又有多高呢?因为不容易说清楚,所以经常碰到一些质疑和灵魂拷问。 如何衡量研发效能的效果? 如何衡量研发效能的作用? 如何说清楚研发效能