最近这十年，国内互联网产业的发展速度不亚于硅谷，在商业模式创新方面甚至已经完成超越，但是我们在研发效能方面始终比较落后。19年年初爆发的 996 大讨论，让国内的加班问题，吸引了国内外开发者的关注。我们很难予以否认，在互联网行业繁荣发展的背景下，国内很多公司采用了“拼工时”的做法，却忽略了最最应该关注的研发效能。
现在回忆下，你是否也曾为下面这些问题感到困扰呢？
- 研发团队看起来人也不少，大家也很辛苦，加班也不少了，但是产品发布还是常常延期，上线后产品问题频发。
- 用户需求从需求分析、产品设计、开发、测试最终流到部署，但最终发布的产品与用户需求偏差却很大。
- 产品发布上线时出现大量提交、合并，导致最后时刻出现很多问题，团队成员集体熬夜加班，却将大把的时间花在了等待环境、等待验证上。
- 开发提测质量不好，大量压力聚集到测试这一步，导致代码返工率很高。引入单元测试、代码审查，效果却都不明显。
- 开发人员疲于应付业务，没有精力或者兴趣去精进技术，对 Git、命令行等强大工具的使用仅限于皮毛，士气低迷、工作效率低下。
这其实就是团队的研发效率，也就是研发效能出现了问题。
何为研发效能
一提到研发效能，很多人的第一反应可能都是开发的速率，也就是研发团队能否快速发布产品。但，速率只是效能的三大支柱之一。
除了快，产品开发更重要的是方向正确，因为不能给用户和公司真正提供价值的产品，做了也是白做。另外，高效能还需要有可持续性，否则短期的高产出可能会严重伤害长期的产出。比如，连续熬夜加班带来的身体问题，会导致后续工作效率低下，得不偿失。
研发效能的完整定义应该是：团队能够持续地为用户产生有效价值的效率，包括有效性（Effectiveness）、效率（Efficiency）和可持续性（Sustainability）三个方面。简单来说，就是能否长期、高效地开发出有价值的产品。
可喜的是，国内越来越多的公司开始在研发流程、工具、文化等方面下功夫，很多百人研发人员规模的公司开始组建了专门的效能团队，来提高整个公司的研发效能。
这是一个很好的现象和趋势。但，很多公司在推进研发效能的时候，常常不知道从何下手，或者是花了精力、加大了投入却看不到效果，产出抵不上投入。比如下面这样的案例：
- 想通过指标度量的方式来衡量团队的效能，要求每个团队达到一定的测试覆盖率。研发团队在产品完成后进行突击，来编写单元测试，最终达到了要求，但产品质量却没有提高。
- 引入业界先进工程实践，学习 Google 使用大仓，但因为基础设施不成熟，对大量二进制文件支持很差，结果是算法团队因为有很多的二进制模型文件，每次 Git Clone 都需要半小时，怨声载道。
- 希望建设工程师文化来提高产出和活跃气氛，跟公司老大以及 HR 商量好几条价值观在公司宣传推广，还组织了几次团建活动，但是收效甚微。大家真正工作起来还是老样子。
这些问题的根源都在于，软件开发的灵活性决定了研发效能提升的困难性：可以关注的点太多，可以使用的方法也很多，但如果只是简单照搬业界研发实践的话，效果往往不好，有时甚至会造成负面效果
而与国内公司形成鲜明对比的是，硅谷的互联网公司在推进研发效能方面做得要好得多。在 2000 年互联网泡沫之后，美国的互联网产业从疯狂增长进入到了“精耕细作”的阶段，需要通过比拼效能在竞争中取得优势，并在此过程中积累了很多经验。
在这其中，Facebook 的研发效能非常高，更是硅谷公司中的一个典范。比如，早在 2012 年 Facebook 月活达到 10 亿的时候，后端服务及前端网站的部署，采用的是每周一次全量代码部署、每天一次增量代码部署，以及每天不定次数的热修复部署，但部署人员就只有三个，达到平均每个部署人员支撑 3.3 亿用户的惊人效率。
又比如，社交网络出现 Bug 的时候，调测起来非常麻烦。因为要复现 Bug 场景中错综复杂的社交网络数据，困难并且耗时。但在 Facebook，它采用开发环境跟生产环境共享一套数据的方法。这就使得开发人员可以非常方便地在自己的机器上复现这个 Bug，进行调测。当然，这样的数据共享机制背后有着强大的技术和管理支撑来规避风险。
研发效能的提高，需要整个公司在研发流程、工程方法、个人效能和文化管理等方面进行精心设计。
网友评论