每日一书丨什么是研发效能？为什么要关注研发效能

60 阅读 0 评论 40 点赞

我是靠谱客的博主开朗嚓茶，最近开发中收集的这篇文章主要介绍每日一书丨什么是研发效能？为什么要关注研发效能，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

最近这十几年，国内互联网产业的发展速度不亚于硅谷，在商业模式创新方面甚至完成了超越，但是我们在研发效能方面始终比较落后。难以否认的是，在互联网行业繁荣发展的背景下，国内很多公司采用了“拼工时”的做法，却忽略了最应该关注的研发效能。

你是否也曾为下面这些问题感到困扰？

团队角度：

1）加班也不少，但是产品发布还是常常延期，上线后产品问题频发。

2）从需求分析、产品设计、开发、测试到部署一个环节都不少，但最终发布的产品却与用户需求偏差很大。

3）产品发布上线时出现大量提交、合并，导致最后时刻出现很多问题，团队成员集体熬夜加班，却将大把的时间花在了等待环境、等待验证上。

4）开发提测质量不好，大量压力聚集到测试这一步，导致代码返工率很高。引入单元测试、代码审查，效果却不明显。

个人角度：

1）疲于应付业务，没有精力去精进技术。

2）工作过程中有大量的电话、即时聊天消息干扰，工作思路常常被打断。

3）对众多的工具（比如Git、命令行）的使用仅限于表层，工作效率较低，想提高却因为工具太多不知道从何下手。

4）有知识焦虑，但是没有找到好的办法系统地提高个人工作效率。

这其实是研发效能出现了问题。那么，研发效能到底是什么呢？一提到研发效能，很多人的第一反应都是开发的速率，也就是能否快速开发、发布产品。但事实上，速率只是效能的三大支柱之一。

相比快，产品开发更重要的是方向正确，因为不能为用户和公司真正提供价值的产品做了也是白做。另外，高效能还需要有可持续性，否则短期的高产出可能会严重伤害长期的产出。比如，连续熬夜加班虽然短期能增加一定的产出，但其带来的身体问题会导致后续工作效率低下，得不偿失。

因此，研发效能的完整定义应该是持续为用户产生有效价值的效率。它包括有效性（Effectiveness）、效率（ Efficiency）和可持续性（Sustainability ）三个方面。简单来说，就是能否长期、高效地开发出有价值的产品。对于团队研发效能和个人研发效能来说，其核心都是这三个方面，只不过在价值的侧重点上有所不同。团队研发效能更注重对公司、团队、客户产生价值，而个人研发效能更注重个人的产出、技术的成长、个人的提高。

可喜的是，最近几年，国内越来越多的公司开始在研发流程、工具、文化等方面下功夫，很多百名研发人员规模的公司开始组建专门的效能团队，以提高整个公司的研发效能。

这是一个很好的现象和趋势。但很多公司在推进研发效能的时候，常常不知道从何下手，或者花了精力、加大了投入却看不到效果，产出抵不上投入。比如，我在一些公司做内训和顾问工作的时候，经常会遇到类似以下案例的情况。

想通过指标度量的方式来衡量团队的效能，要求每个团队达到一定的测试覆盖率。研发团队在产品完成后进行突击来编写单元测试，最终达到了要求，但产品质量却没有提高。
引入业界先进工程实践，学习Google使用大的代码仓，但因为基础设施不成熟，对大量二进制文件支持很差，结果算法团队有很多的二进制模型文件，每次执行git clone命令都需要半小时，导致怨声载道。
希望建设工程师文化来提高产出和活跃气氛，跟公司管理层以及HR商量了好几条价值观在公司宣传推广，还组织了几次团建活动，但是收效甚微，大家真正工作起来还是老样子。

这些问题的根源都在于，软件开发的灵活性决定了研发效能提升的困难性：需要关注的点太多，可以使用的方法也很多，但如果只是简单照搬业界研发实践的话，效果往往不好，有时甚至会造成负面效果。

在这方面，硅谷的互联网公司做得要好很多。在2000年互联网泡沫之后，美国的互联网产业从疯狂增长进入“精耕细作”的阶段，通过比拼效能在竞争中取得优势，并在此过程中积累了很多经验。

其中，Facebook的研发效能非常高，更是硅谷公司中的一个典范。比如，在2012年Facebook月活达到10亿的时候，其后端服务及前端网站的部署采用的是每周一次全量代码部署、每天一次增量代码部署，以及每天不定次数的热修复部署，但部署人员只有2.5个（0.5个是因为有一人是来自工程师团队的自愿报名的助手），达到平均每个部署人员支撑4亿用户的惊人效率。

又比如，社交网络出现Bug的时候，调测起来非常麻烦，因为要复现Bug场景中错综复杂的社交网络数据困难且耗时。但Facebook采用开发环境与生产环境共享一套数据的方法，使开发人员可以非常方便地在自己的机器上复现Bug，以进行调测。当然，这样的数据共享机制背后有着强大的技术和管理支撑来规避风险。

2010到2013年，我在Facebook基础平台团队的内部工具组工作。作为核心成员，我研发并开源了研发工具套件Phabricator。2013到2015年，我又作为效能工具的使用者参与了Facebook对外产品的研发。这几年的工作，让我对Facebook如何提高研发效能有了越来越清晰的理解，认识到研发效能的提高需要整个公司在研发流程、工程方法、个人效能和文化管理等方面进行精心设计。

离开Facebook之后，我在硅谷的Stand Technologies 公司（后文简称Stand）、国内的两家创业公司以及华为等担任过技术总负责人、CTO、技术专家和团队主管等，带领百人技术团队进行研发。

比如，2017到2018年，我在华为开发工具部主导开发下一代集成开发环境，旨在为软件开发工程师提供全栈的端云一体工具平台，为2万多名开发人员服务，从而提高公司整体的研发效能。同时，我也尝试将研发效能的工程实践引入华为。比如，我在团队组织了几次黑客马拉松（Hackathon）活动，平均10个开发人员就产出一个项目，每10个项目中就有 1.5个成功落地。

工作17年来，我在研发效能团队工作过，也在产品团队中推行过研发效能，涉及国内外不同类型、不同规模的公司，所以对怎样在一个公司或者团队中引入效能实践有比较丰富的经验。

在这里，我想将自己之前的经验和教训进行一次系统的梳理，希望能够帮助对效能有期待又有困惑的同行者，当然对自己也是一次温故知新的机会。

本书结构

在本书中，分五个部分系统讲述如何做到研发的高效能。

研发效能综述（第1～3章）。这一部分讲解研发效能的定义、模型，并着重介绍研发效能度量的正确使用方法，希望帮助读者梳理研发效能的主脉络，构建清晰的知识图谱。
个人高效研发实践（第4～15章）。这一部分讲解如何提高个人效能，具体涉及深度工作、Git、命令行、Vim、工具集成等内容，旨在帮助读者提高技术的专精程度，实现持续成长。每个开发人员都应该提高自己的效能，只有这样才能持续学习、持续提高，避免被业务拖着跑。
研发流程优化（第16～21章）。这一部分讲解研发流程优化的基本目标和原则、代码优化、分支管理、DevOps、团队协同等话题，希望帮助读者深入理解研发过程中的关键流程以及流程优化的基本原则，使读者能够针对自己的实际情况，找到最合适的工程实践，让软件开发的整个流程更加顺畅、高效。
团队高效研发实践（第22～30章）。这一部分讲解团队高效研发实践过程中各关键步骤的高效工程方法，内容涉及研发环境搭建、代码审查、合理处理技术债、开源利弊分析、测试等，同时对研发流程及工程方法的趋势进行解读和展望，希望帮助读者加深对这些具体工程方法的理解，并学会正确地使用这些方法。
管理和文化（第31～36章）。这一部分系统分析硅谷管理和文化，尤其是Facebook的工程师文化，并根据我在国内外公司的具体落地经验，给出推荐的文化引入和建设方法。

这里要着重强调一下个人高效研发实践部分。团队由个人组成，所以团队研发效能和个人研发效能密不可分。然而，个人研发效能是很多公司和团队在进行提效工作时容易忽略的一个点。所以在本书中我会在个人效能方面多花一些笔墨，介绍如何从指导思想、工具、沟通等方面提高个人效能，往10x 程序员的方向努力。

研发效能和软件开发一样，都具有很大的灵活性，提高研发效能不是生搬硬套就能做好的。所以我会着重讲解目标，带你深入了解效能实践背后的原理，然后才是具体的实践。因为只有深刻理解原理，才能灵活运用。

同时，我会分享大量成功的案例，带读者一起了解国内外公司的优秀做法，分析它们成功的经验。当然，我也会分享失败的案例，分析其背后的原因。不过更重要的是，我希望读者能够跟着我一起分析，通过对比思考，找到真正适合团队和自身的实践。这正是我写作本书的真正初衷。

关于作者

葛俊
资深研发效能专家，17年技术研发和管理经验。曾任职于微软、Facebook、华为，以及硅谷和国内的两家创业公司，担任研发效能团队负责人及CTO等角色。
在Facebook（Meta）任职期间，担任内部工具团队Tech Lead，负责知名开源开发工具集Phabricator。在华为任职期间，担任华为内部工具团队的首席架构师，高级产品总监兼执行总监。在研发团队有丰富的工作经验和带团队的经验，有主导推进研发效能的丰富经历。

曾多次被“全球架构师峰会”等大型会议邀请，做互联网技术研发效能方面的专题报告。

声明：本文转自“华章计算机”公众号。

《新程序员003》正式上市，50余位技术专家共同创作，云原生和数字化的开发者们的一本技术精选图书。内容既有发展趋势及方法论结构，华为、阿字节跳动、网易、快手、微软、亚马逊、英特尔、西门子、施耐德等30多家知名公司云原生和数字化一手实战经验！