写点什么

PingCode 徐子岩:研发效能的核心关键点丨 QCon

  • 2021-06-17
  • 本文字数:5213 字

    阅读完需:约 17 分钟

PingCode徐子岩:研发效能的核心关键点丨QCon

AI 大模型超全落地场景&金融应用实践,8 月 16 - 19 日 FCon x AICon 大会联诀来袭、干货翻倍!

目前,互联网行业内的类 996 情况是极为普遍的,为了提高业务产能,加人加班的方式真的可以有效解决公司的研发效能问题吗?


研发效能,并不是指一个单位组织的整体产出量,而是指单位时间的产出量。由此可见,简单的加人加班可能并不能解决产能问题,增加更多的沟通成本和管理成本,还可能会适得其反。如何正确的理解研发效能,如何制定符合自己公司的研发效能提升方案,这是每家公司必须要思考和实践的。


InfoQ 记者有幸在QCon 2021 全球软件开发大会上,采访到了 PingCode 基础平台部负责人徐子岩老师,由他亲自为我们讲解提升研发效能的核心关键点,以及如何合理制定方案。


以下是视频采访内容,为方便读者查看,视频下方也附上了文字内容。


00:00 / 00:00
    1.0x
    • 3.0x
    • 2.5x
    • 2.0x
    • 1.5x
    • 1.25x
    • 1.0x
    • 0.75x
    • 0.5x
    网页全屏
    全屏
    00:00


    InfoQ:徐老师您好,欢迎您参加这次 QCon 大会进行分享。您先做个自我介绍吧,让大家先熟悉一下您。


    徐子岩:好的,各位观众、听众,我叫徐子岩,是 PingCode 基础平台部总监,也是目前活跃在开发一线,每天都写代码的程序员。


    InfoQ:我们发现现在很多公司,他们为了能够直接提高业务产出,通常方式是比较简单粗暴一些的,比如说增加人手,或者是加班这种情况,但是这其实并不能够直接的解决一些问题,在这个情况下,研发效能这个词就出现了,大家开始比较重视这个东西,从您的角度来看,怎么来理解研发效能这个东西呢?它有哪些关键点。


    徐子岩:实际上你刚才提的这个东西,很多公司都是采用增加人手或者是增加时间这种方式,我觉得它能提高的是我们的总产出量,但实际上提高不了单位时间的产出量。研发效能是指单位时间产出量,有的时候我们提高了人手以后,相对来讲,我们的单位时间的产出量反而降低了,为什么呢?因为你有沟通成本、学习成本,最主要的是这块。


    那对于研发效能来讲,实际上我感觉它是有一些相关指标的,比如说我的产品的上线前置时间,类似于我的缺陷生存周期,包括我的部署成功率,包括我流水线执行次数,这些都是业内通常用到的研发效能指标。但是我一直理解的就是说,各个团队他的研发效能指标,应该是不一样的,你不应该用统一的指标去衡量每一家公司,公司应该找到你自己合适的指标,刚才那些指标,应该都是一个参考的量。


    InfoQ:很多可能看到比较优秀的研发效能提升的方案,直接应用到本公司之后,发现其实没有很好的提高他们的研发效能,反而会出现一些水土不服的现象,让整个研发效能反而降低了,或者员工的积极度也降低了,那对于这种情况,您觉得问题出现在哪里呢?有没有比较好的建议和方法。


    徐子岩:我觉得最大的问题,就是在于刚才提到的,公司是不一样的,甚至于每家公司的每一个团队都是不一样的。那我们现在无论是在做研发效能的改进,还是研发管理的改进,如果说我去看到某一个管理方式,或者一个效能度量方式不错,我就不加思索的认为应该用它,那多半会出现问题的。


    第一,没有考虑到你自己的公司,在研发效能当中到底出了什么问题?第二点,是必须要基于出现的问题,要考虑怎么样能把它解决掉。在这个基础上,再去了解业内其他的公司,或者是说大家普遍在用的一些方法,有没有可能去解决我的问题。然后在解决适用之后,要逐步的去用,逐步地听研发团队反馈,而不是说这个东西到我这来用,我就一条道要用到黑,他要求怎么样做,我就必须这么样做。


    研发团队对这个东西有意见,发现有问题,我也不要求改进,因为我认为那个就是真理。我觉得如果是这种情况下,那肯定会造成这种研发效能反而降低,甚至于出现更坏的情况,就是团队出现抵制情绪,如果你的团队出现抵制情绪,那你再去推别的效能提升方案,就会非常非常困难。


    所以说我的理解,如果一家企业想要去做管理跟效能的提升,第一点,一定要明确你自己出了什么问题,第二点怎么样去解决它。然后逐步的去应用到你的团队当中去,而且不断的需要收集团队的反馈。基于你的反馈改变你的方案,不是别人讲的都是对的,改变以后真正适合你自己公司的,才是最对的。


    InfoQ:就像您刚刚说的,每个部门之间,他们可能评价自己研发效能指标是不一样的,在我看来,会出现一种类似于“竖井”的情况。我自己理解,“竖井”似乎不是一个完全负面的东西,只是需要从全局和局部的角度去平衡与度量它的效率和利益,是不是这样的呢?你是如何看待这个现象的呢?


    徐子岩:这种情况下,在有一些公司我遇到过,实际上就是说某一些部门,或者某一些团队,他自己的工作效率很高,工作效果很好。但是呢,它非常排斥其他团队对他的这种东西,希望自己保护起来,不要去碰我。


    我觉得这个是几个方面的问题,首先第一个方面,就是研发效能这件事情,究竟是从哪推起来的。在我的理解,一定要有公司的高层支持,公司高层的支持一定要支持到所有团队。就是说,我作为公司的高层,要求的是全公司,或者整个研发线的效能提升,而不是逐个效能提升。


    “竖井”的情况就是你们的部门效能是提升了,但是在我全局角度上看,你对其他团队是有影响的,从我的角度,你就是没有提升我整个公司的研发效能,那我就是要想办法解决这个问题,这是第一点。


    另外一块,就是跟研发效能相关的,我们怎么去评价一个团队,对公司的价值和贡献度。我们有时候,有一些公司,或者说有一些组织,更倾向于评价你的产出量,你的代码量,甚至于你对公司的业务或者说你挣了多少钱,但是都会或多或少的会忽略一点,就是你在研发团队当中的沟通跟协作,和团队配合,这样的能力,究竟有多强。


    如果你单纯的以那种类 KPI 的方式去管理研发团队,大部分团队都会遇到这种问题,就是我只为我的目标负责,我搞的好就行,我不要去管别人。但是我觉得,至少对于我们 PingCode 的研发团队来讲,我们在自身团队的目标的同时,也关注你对其他团队做了什么


    如果其他团队对你的评价不高,那么你最终的评价也不会很高,那么我们考虑就可能会用这种方式,来去解决你所说的所谓的“竖井”问题,就是说我好,但不是全部都好,我要帮助所有的人,大家一起成长,才有可能去达到我的目标的达成度,我觉得这个可能一部分解决这个问题。


    所以我觉得,您说“竖井”也不完全是一个坏现象,在最开始的初期,我觉得可能是会有某些团队会做的好,但是作为企业来讲,应该时刻的关注警惕这种情况出现,尽量不要让它出现。


    InfoQ:我们如何去判断企业,它是否有一个良好的研发效能呢,从哪些角度可以判断一下?


    徐子岩:这个问题说起来是非常难回答的,因为刚才在分享中也有人有提到,我的团队怎么算好,怎么算不好,如果这个问题从根本上回答,是没有这样的标准的。


    因为我刚才提到的,你每一个公司都不一样,每个公司各个团队都不一样,对于不一样的团队,你是不可能用统一的标准去衡量这件事情的,所以只能是从自己的公司出发,去衡量你的研发效能,究竟是怎么样的?跨国公司、分布式公司和本地公司是不一样的,那你做产品的公司和做项目的公司又是不一样的,但是通用起来来讲,可能研发度量有这样几个方面,它不是度量的具体的一个内容,可能是一个方向。


    比如说我们可以考虑一下研发团队,在开发当中的流畅度,所谓的流畅度,是从你的需求到编码,从部署到发布,中间有没有特别明显的阻碍感,哪一个环节被阻住了,或者哪一个环节很难推动的起来。那么这个是研发效能就是需要关注的其中一个点。


    另外一个点,就是质量。这一点相信所有公司都关注,但是我在这提出来的是恰到好处的质量,不是质量越高越好,是符合你公司要求的质量就是好的。有的公司可能钻这个牛角尖,尤其是技术公司,它会钻这个牛角尖,我一定要把质量搞的多好,有些实际上你搞到一定程度上是没有意义的。


    第三,你一定要持续地做这件事情,我在我的分享环节里不断跟大家重复一段话,一旦你想做某件事情,你一定要持续的去做,而不是说最开始大张旗鼓,然后大家疲态了,最后就放弃了,如果是这样,我宁可不做,因为所有的工作都耗费了。


    所以说,你的研发效能度量,或者是研发效能提升这件事情,一定要持续足够长的时间,公司的高层和管理者,一定要给予切实的支持去做这件事情。然后呢,研发效能度量一定要关注客户的价值。


    研发人员有的时候会太偏研发了,我觉得这个东西很好,很棒,我就是要用,我不用心里就难受。但是研发人员没有错,如果出现这种情况,错的应该是研发的管理者,就是他始终要把控研发团队。你做的所有东西,都是应该给最终用户有客户价值的,没有客户价值的提升,是毫无疑义的,也是浪费的。


    最后一点,就是闭环,你有想法、计划、实施,你一定也要有反思和改进。国内做很多研发、管理包括研发效能提升的,做的不好,我觉得最大的一个可能性,就是在于他的闭环做的不好。没有反思,没有改进,这一点跟上面几点比起来,我觉得闭环可能是最重要的一点


    InfoQ:在目前的行业里面,有没有您知道,在研发效能做的很成功的一些案例,你可能找具体的给我们介绍一下。


    徐子岩:这个案例,因为我了解的企业,可能各不一样,所以说我刚才也提到了,这些案例可能不适合每一家公司。我不敢说做的比较好,但是我比较了解的是我们 PingCode 自己的团队,我们是怎么做研发效能管理的。


    从刚开始的简单粗放的管理,到后来我们引入了敏捷开发,然后敏捷开发解决流程化的东西,然后再引入规模化敏捷就是 OKR,解决了我们从研发目标开始,到具体的每一个员工,他每天的工作怎么样对齐。


    在此之上,主要都是解决了研发效能里面流程化,就让大家目标一致,开发有节奏,同一时间实现了很多极限编程,包括 DevOps 流水线的一些东西,这些解决了我们的研发效能里面的质量和研发速度。


    最后也是近年来做的,研发自动化的产品,就是研发效能一方面是说我们的团队成员能多做某些事情,大家可能现在关注点都是希望大家多做些事情,让效能提升,还有一块目前大家都在忽略的一件事情,就是有哪些事情可以让大家不做。


    研发自动化这一块,更多的是让大家关注在另一侧,让大家不要再去做那些没必要每天去做的事情,这些事情让机器去做。也就是说,这个可能是我们目前团队几步走下来,研发效能领域,不能说做的好,是我们的一些实践,也没准能给大家一些帮助吧。


    InfoQ:好的,老师,PingCode 是有专门去负责提升研发效能部门的人员吗?


    徐子岩:我们现在并没有这样的专门人员,因为我们 PingCode 这边,有一个专门的技术委员会,技术委员会是横跨几个技术部门的一些技术主管、架构师,他们在一起,我也是技术委员会的成员,提升研发效能是我们技术委员会当中的一项工作内容,是我们需要考虑的一件事情。


    所以说,近期我们 PingCode,应该不会有专门的研发效能团队去做这件事情。


    InfoQ:那您觉得对于一些公司来说,有没有必要,或者以后是不是一个趋势,就是公司需要有这样一个具体的工作人员,或者一个部门,来提升公司的研发效能这件事情,需不需要这样的岗位扩充呢?


    徐子岩:我觉得这个要看公司,假如说一个极端情况下,研发团队一共有 5 个人,我就不可能有这样的团队,专门提高研发效能。因为 5 个人,3 个人的研发团队,在我的理解来讲,他的效能是最高的,不可能有研发团队比这样的团队效能再高了。


    但是,当我们的公司变成我们现在,将近 100 人,可能就需要有一个兼职的效能提升部门,需要去考虑这件事情,他有可能不是全职的,因为你的公司没有大到这种程度以后,你可能一方面资金允许不允许,另外一方面可能你也用不到这样的事情,专门有人每天 8 小时做这件事情。


    但是如果再往后,我们的研发团队到百人,千人,或者是像跨国的微软、谷歌、Facebook 这样的公司,那么他的研发团队可能是几万人的团队,那他肯定会有一个专门的部门,甚至是一条研发线,去专门做这件事情。


    那我的理解就是,有没有必要,公司大了肯定有必要,但是一定要量力而为,不是所有公司,我一听提升研发效能,第一件事先成立一个部门,先找一个部门负责人,又回到我刚才说的,你要了解你公司的现状,用你公司的方式去解决你的问题。


    InfoQ:我们最后一个问题,也是比较大的问题。您觉得在未来,研发效能的提升,还能在哪些方面做一些事情,或者说有一些体现呢?


    徐子岩:首先来讲,我觉得这两块可以分成相对短期和长期。短期来讲,在近一两年左右,三年以内,刚才提到的,之前做研发效能更多的是希望大家多做事。那么现在实际上在近两年,很多的项目管理公司,他们大部分公司都已经开始意识到这一点,通过自动化的产品去让团队尽量少做某些事情。这个我觉得可能是在近两年之内,会比较重点的一个领域。就是说,通过自动化的方式,让研发团队的人去专注于实现客户要的东西,而不是做那些事务性的工作,这是短期的我的概念。


    中长期的概念,我觉得研发效能的提升,依靠流程、工具,这种层面可能已经达不到了,未来可能需要借助数据、智能和 AI 的方式,让研发效能的提升不是我们想办法,告诉我们的工具和产品,你怎么提升,是产品反过来,告诉研发团队,你有哪些点能被提升。或者说,你现在的研发效能究竟出了哪些问题,是反向的提示我们,这个可能需要我们所有的研发赛道的企业共同的去探索,在未来有没有可能用这种方式,再为我们研发效能的提升去拉高另一个台阶,我的理解是,它不在一个层次上做这件事情。

    2021-06-17 19:336396

    评论

    发布
    暂无评论
    发现更多内容

    级联层与层叠上下文了解下?

    转转技术团队

    CSS JavaScript 前端

    一文带你认识CSS

    未见花闻

    6月月更

    力扣每日一练之二维数组下篇Day5

    京与旧铺

    6月月更

    鲲鹏云开发者分论坛:发挥鲲鹏的潜力,加速云上创新

    科技热闻

    dp练习

    工程师日月

    6月月更

    2022-06微软漏洞通告

    火绒安全

    微软 漏洞 安全漏洞

    考试试卷存储方案

    极客土豆

    JMeter集成底座项目压测心得

    agileai

    压力测试 集成底座 企业服务总线 统一身份管理平台 主数据管理平台

    Open the World:第七届中国开源年会(COSCon'22)正式启动~

    开源社

    第七届中国开源年会 COSCon'22

    python逆序输出和进制转化(小白也能看懂)

    写代码两年半

    Python 6月月更

    挑战最全 Apache Doris 学习资料,你想要的都在这里了!

    SelectDB

    数据库 Doris apache doris 技术干货

    图搜的应用场景

    Geek_e369a5

    图像检测 图像搜索 图搜的应用场景

    2022年中国Robotaxi行业发展洞察

    易观分析

    智能汽车

    AntDB数据库与强网科技完成产品互认证,积极探索办公自动化领域

    亚信AntDB数据库

    智慧园区效果不满意?请收下ThingJS这份秘籍

    ThingJS数字孪生引擎

    智慧园区 数字孪生

    如何通过事件可视化分析?

    清林情报分析师

    数据分析 事件分析 可视化分析 时间分析

    InfoQ 极客传媒 15 周年庆征文| 聊聊 Go 语言与云原生技术

    宇宙之一粟

    云原生 6月月更 InfoQ极客传媒15周年庆

    GetxController 生命周期详解

    岛上码农

    flutter ios 前端 安卓 6月月更

    数据库每日一题---第15天:未消费的顾客

    知心宝贝

    数据库 程序员 前端 后端 6月月更

    Vue3 响应性原理

    转转技术团队

    JavaScript Vue 前端

    HTTP接口性能测试中池化实践

    FunTester

    vue生命周期

    小恺

    6月月更

    从市场需求目标看数据分析演进方向

    华为云开发者联盟

    人工智能 华为云

    一起认识下浏览器的5种观察器

    转转技术团队

    JavaScript 前端 浏览器

    GCC 为龙芯 CPU的预定义宏

    gameneedless

    c++ RocksDB GCC 龙芯

    在 Pisa-Proxy 中,如何利用 Rust 实现 MySQL 代理

    SphereEx

    MySQL 数据库 rust

    python程序设计思想

    左手の明天

    Python 面向对象

    自己实现一个大文件切片上传+断点续传

    转转技术团队

    JavaScript 前端 文件上传

    低代码如何“拯救”企业?

    优秀

    低代码 企业管理

    如何编写一份简单易用的在线产品手册

    小炮

    产品宣传手册 产品说明手册

    音视频处理三剑客之 ANS:噪声产生原因及噪声抑制原理解析

    ZEGO即构

    音视频课程 噪声抑制 ANS

    PingCode徐子岩:研发效能的核心关键点丨QCon_技术管理_龚仕伟_InfoQ精选文章