李倩:拖累开发团队效率的困局与破解之道

互联网时代,业务发展越来越快,而技术的迭代速度,技术团队之间快速的协作交付,越来越成为团队业务制胜的一个很关键的因素,工程效率应运而生。

或许工程效率对于大家来说,早已不是一个全新的概念。许多公司也专门成立的工程效率部门,那么我们该如何理解工程效率呢?工程效率能给研发带来什么帮助呢?听听 KodeRover 创始人 & TGO 鲲鹏会会员李倩的分享,她将从多角度为大家带来工程效率方面的经验及建议,希望能帮助企业更好地利用工程效率,提升研发效能。

研发交付都是它的事儿

对于大部分工程师而言,没办法把大量时间投入到写代码上。除了写代码,他们还要负责找 bug、上线等工作,尤其是事务性工作(比如调试环境,和各部门沟通等杂项)。其实这是一个普遍现象,尤其是在一些达到一定体量的公司里,在这种情况下很容易出现效率问题。

详解工程效率

工程效率,主要关注业务交付链条中研发交付环节的品控和效率,最核心的是缩短优质代码到客户 (用户) 交付间的距离。用一句话说就是:整个研发交付的事都要管。

工程效率到底要做什么?

首先,要关注一些重要不紧急的事情;其次,就是量化工程开发团队对业务的交付能力,并且识别薄弱环节。最后,向工程建设卓越的企业学习,比如 Google、Facebook 以及 Netflix。

我的理念是,工程效率不只是改善一个人力的投入,更重要的是为企业建立软件工程信息高速公路,让更多工程师可以专注于研发。

工程效率面临怎么样的形势?

举个例子,To C 的企业像 B 站这样成长非常快的公司,人员增长逐年成倍,加人以后业务复杂度提升了,产能并不一定可以成倍提升。要更稳定的业务增长务必要把工程这一层做厚,比如多套测试环境,提升自动化程度,CI / CD 建设等。

另外一个比较大趋势就是业务驱动的 IT。而对于软件工程而言,如何以业务维度来量化各个职能的产出,也就是做企业内部的数字化转型?举个例子,QA 的产能怎么样评价?两条业务线到底哪个产能更高?对于工程师而言,他们的技术实力代表的是他们的真实实力,而不是企业卖了多少钱代表他的实力。所以,工程师这块需要告诉他们更多的反馈,比如覆盖率指标,返工率情况等等,数据驱动我们不断的提升和成长。

再者就是协作难度大,假设公司有 500+ 研发人员同时写代码,分支众多,合并频度以及状态的跟踪等等都是挑战。那么我们怎么样快速迭代?怎么做才能又能保证质量保证效率?包括自动化 case 或者多场景的测试,都是要面对的一些实际场景。

面对挑战,我们该如何做?

面对这些挑战,李倩主要提出两点,一个是组织发展,一个是文化建设。

组织发展

组织发展这块中,三大块组成了我们整个工程效率的体系,这三大块对应我们的三个子 team。

质量管理是主要是可以在测试开发团队分很多线,效能运营是效能运营中心,是一个虚拟组织,但是包含多种服务。工程赋能是平台工具组,来做整个的研发支撑。质量管理这块我们 QA 的同学基本上是测试开发,还有技术专家这样一些职能。大部分情况下,他们做全流程质量的把控,核心工作在熟悉业务,写自动化,构建不同的场景。

质量运营主要是关注 PMO 以及流程的产品化,还有我们整个内部系统的运维支持,还会做竞品分析等。以前做直播 SDK 我们会把竞品的几家 SDK 的自动化实现了以后去观察他们的一些性能指标。比如 ,CPU、Memory 以及丢帧或者一些实际的推流、播放的效果,会去做一些监控,这样就可以给内部提供更多的技术改进方向,或者是看得到其他人的技术成长。

然后现在他们的 scope 扩大了,就会去做一些质量分析。比如某团队,我们通过质效数据看到它是否有一些特性;比如通过事故统一分析下来,发现某个组件的性能非常容易出问题,技术专家会参与出专项改进方案,最终落地以及提供环境支撑等。

另外就是研发最佳实践的传播,比如单测或者是集成测试等做得比较好的,还有 codereview 做得比较好,都有这个组织来进行发起。

然后是工程师,大概都包含哪些工程师?质量管理制度会分几条线,有技术线和管理线。比如,业务质量负责人类似于质量 owner,测试开发有两个方向,一个是技术专家方面,一个业务专家方向。质效运营中心包含三部分,一个是针对测试服务的 service,一个是 PMO 负责流程设计和产品化,另外是 sre 内部平台的运维支持。

文化建设

第一、工匠精神

工程师对于质量应该有极致地追求,eat your own dog food。我们的理念是:代码是工程师写出来的,bug 也是他写出来的。举个例子,如果一段代码写的不好,给他多少个 QA 都解决不了问题,所以根上仍然是工程本身的质量怎么样。所以我们不会把质量往下游放,而是不断地向上游去思考,以及不会对 QA 追责,而是关注这个问题到底谁去解决成本更低。比如,一个问题如果是在 codereview 阶段就应该发现,那么就不应该到 QA 阶段。

第二、质量意识

我们这块会做大量的质量服务化工作,比如单测或者静态扫描等,我们会做成服务化。很多时候开发同学不是不愿意把代码写得好,而是自己不知道写出来到底能不能 work,我们就需要给他提供更多地支撑。比如,他不 work 的时候反馈给他原因。比如,一旦单测不过,或者说单测覆盖达不到要求,我们会让他看到,他会针对这个去做修改,而且是基于 Pr 级别的,秉承着“持续集成,小步快跑,快速反馈”的理念。

第三、工程文化

凡是超过两次都要考虑自动化或者服务化实现,Everything is Code。我们 CEO 许式伟先生曾经在群里说了一句话叫“系统性地解决一下”,这句话挺有意思,也是我们日常的工程文化体现。

TGO 鲲鹏会 ,是极客邦科技旗下高端技术人聚集和交流的组织,旨在组建全球最具影响力的科技领导者社交网络,线上线下相结合,为会员提供专享服务。目前,TGO 鲲鹏会已在北京、上海、杭州、广州、深圳、成都、硅谷、台湾、南京、厦门、武汉、苏州十二个城市设立分会。现在全球拥有在册会员 800+ 名,60% 为 CTO、技术 VP、技术合伙人。

会员覆盖了 BATJ 等互联网巨头公司技术领导者,同时,阿里巴巴王坚博士、同程艺龙技术委员会主任张海龙、苏宁易购 IT 总部执行副总裁乔新亮已经受邀,成为 TGO 鲲鹏会荣誉导师。

如果你想和这些优秀的科技领导者们一起前行,欢迎参加 「GTLC 全球技术领导力峰会 」

我来评几句
登录后评论

已发表评论数()

相关站点

+订阅
热门文章