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

devops,研发,效能,不是,老板,工程,开发者,服务 · 浏览次数 : 151

小编点评

**研发效能不是老板工程** 研发效能不是老板工程,它不是老板直接负责的,但是在帮助产品研发和交付过程中,对产研运同学的服务。研发效能的目的是为了提高产研运团队的效率,让他们能够更高效地完成工作。 **研发效能的特征** * 长期投入,专业人才不好找 * 做的事情多,投入相对分散 * 见效相对慢,工具平台的建设非一朝一夕 *好在任督二脉一旦打通,事半功倍,效果显著且持久 **研发效能的意义** 研发效能是帮助产研运团队高效完成工作的重要基础设施和服务。当公司可以有效地进行研发效能,就容易把公司的各种中后台能力如同积木般不断组装成一个个的业务能力推给用户。

正文

有人说研发效能是老板工程。不是的,研发效能不是老板工程,它不直接服务于老板(虽然老板可能看一些报表),反而是服务于广大产研运(产品+研发+质量+运维)的同学,所以有的公司也把研发效能叫做基础中台,平台工程,开发者服务团队,或者叫开发者服务平台。做好研发效能,做好开发者中台,就容易把公司的各种中后台能力如同积木般不断组装成一个个的业务能力推给用户。当然如果老板有效能的意识,有决心和动力提高公司的产研效能,为广大的产研小伙伴提供一个比较好的开发者服务基础设施,那当然是就更好了。

 

前期优先发展主营业务

老板们大多数结果为先,国内企业大多数也是注重自己主营业务,业务为先,业绩为先。

当公司营收,依然还在快速上升时期,主营业务持续向好时,通过增加人力资源依然可以推高主营业务营收,只要人力成本依然可以接受的时候,老板一般都会选择快速补人头来继续催化营收,而不是注重研发效能方面的提高。当然也有一些一直高举高打各方面投入都很高的公司,比如某二进制公司,即便这样前期的效能相关职能也是四散在公司各个业务线,乱的很。

考虑的主要因素:

  • 1)立马可行,见效快,短期能补充

  • 2)补充人力,成本短期也可接受

  • 3)见效快。研发效能短期投入虽不高,但见效慢

  • 4)大老板们对研发效能的理解还在提升阶段

 

中期各地建基地抢人头

上面这种堆人催化业务发展这种情况的上限不高。因为在一个城市里能提供的人力毕竟是有限的,当想发展得更快时,只能加钱招人,即便这样很多公司还招不到。这也就造成了互联网公司都是全国各地建分基地抢人。

想做搜索去北京,挨着百度建分公司;想做电商去浙江,就在阿里旁边;做游戏那就去深圳挖腾讯、网易。如果一个分基地还不满足那就建两个。我国IT人才比较多的省份如下:北京、广东、江苏、上海、浙江、四川、湖北。

 

研发效能、修炼内功

如果多个分基地还不能满足业务发展,或者公司内已经人满为患但是依然业务不够快,这个时候就要好好考虑下公司的人效了,尤其是产研运的效率。

这就像一个人学武的前期阶段,虽然每个人选择的方向不同,但是只要在某一方向上下功夫,肯定能快速让自己的武功爬升到一个层级。有的善于拳术、有的精于腿法、有的强于兵器、有的则善用暗器。如果还要武功精进,则要修炼内功心法。修炼内功对自己的武功之前修炼的招式有莫大的增益,同时还能有助于修炼其他武功,触类旁通。

研发效能如同九阳神功,实打实的内功心法,需要长期修炼,才能形成无上内功。虽然研发效能一般不能短期对主营业务产生直接影响,但是一旦成型增益你出招的速度,力量和准确度,也很容易地把之前拳术能力运用到腿法、兵器、暗器上。

 

研发效能工作的特点

  • 1)长期投入,专业人才不好找

  • 2)做的事情多,投入相对分散,比如各种基建需要做

  • 3)见效相对慢,工具平台的建设非一朝一夕

  • 4)好在任督二脉一旦打通,事半功倍,效果显著且持久 

但研发效能也有危险,修炼不好,容易走火入魔,比如很多公司都魔怔式的统计工时,不知道是向甲方收钱,还是觉得员工辛苦想奖励员工,还有一些拿些虚假繁荣的指标忽悠别人忽悠领导。汝之蜜糖,彼之砒霜。

 

开发者服务

开发者服务是指为开发者提供的各种工具和服务,以便他们更加高效地进行软件开发。 

  • 版本控制系统

  • 基础设施服务

  • 编程语言、组件和框架

  • 调试和测试工具

  • CI/CD工具

  • 文档和知识库

  • 社区和论坛 

以上是一些常见的开发者服务,它们可以帮助开发者更加高效地进行软件开发。

 

本文总结

本文主要陈述了研发效能不是一个老板工程,面子工程,而是实实在在的为产研运小伙伴服务的职能。让大家利用公司的基础设施和平台服务,顺顺畅畅的工作,高效的产出这才是我们做研发效能的目的。

 

推荐阅读

 研发效能负责人/研发效能1号位|DevOps负责人产品经理,项目经理,FTO
研发效能DevOps推荐书单
研发效能|DevOps 已死平台工程永存带来的焦虑
企业内源(内部开源)问与答
高效能敏捷交付团队反思:特性团队(FeatureTeam)+Scrum

与 DevOps|研发效能不是老板工程,是开发者服务相似的内容:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

devops|中小公司不要做研发效能度量

我特别反感那些不顾公司现状一上来就想要做研发效能度量的人,尤其是想把研发效能度量当成锤子四处去敲打螺丝钉的人。 没几个人的小公司上来就做研发效能度量,就如同普通人一上来直接问媒婆怎么能娶到迪丽热巴。解决办法无非把大象装冰箱里的那三步。套用一下,公司想要做好研发效能度量也有标准的三步:长时间对研发效能

AI DevOps | ChatGPT 与研发效能、效率提升(中)

为啥 ChatGPT 突然火了? 简单概括就是:产品太过惊艳,体验超预期 之前人工智能发展多年,报道最多的也许就是曾经的李世石大战AlphaGo,现实中的特斯拉自动驾驶,还有波士顿动能放出的机器狗。对于圈外人士来说一般也接触不到这些,仅仅看看而已。但是 ChatGPT 不一样,一声巨响,石头中蹦出一

devops|中小公司效率为王,没必要度量

之前写过一篇文章《devops|中小公司不要做研发效能度量》,主要是从基础设施方向考虑,因为很多条件都不具备,贸然高投入去做研发效能度量可能达不到我们的预期效果,给出的建议是先做好当下打好基础。今天想到一个好例子,可以类比下。 两个人小家庭 1)人少 2)收入清晰 3)支出清晰,买了什么东西,花了多