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

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

或许工程效率对于大家来说，早已不是一个全新的概念。许多公司也专门成立的工程效率部门，那么我们该如何理解工程效率呢？工程效率能给研发带来什么帮助呢？听听 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 全球技术领导力峰会 」。