研发效率破局之道阅读总结(1)研发效能

研发效率破局之道阅读总结(1)研发效能

Author: Once Day Date: 2025年4月8日

一位热衷于Linux学习和开发的菜鸟，试图谱写一场冒险之旅，也许终点只是一场白日梦…

漫漫长路，有人对你微笑过嘛…

全系列文章可参考专栏: 程序的艺术_Once-Day的博客-CSDN博客


注: 本文内容摘抄于原文前4节，文中"我"代表原作者【葛俊】大佬视角。


原始文章和课程: 研发效率破局之道

---

1. 概述

团队的研发效率(研发效能)有如下常见问题：

1. 研发团队看起来人也不少，大家也很辛苦，加班也不少了，但是产品发布还是常常延期，上线后产品问题频发。
2. 用户需求从需求分析、产品设计、开发、测试最终流到部署，但最终发布的产品与用户需求偏差却很大。
3. 产品发布上线时出现大量提交、合并，导致最后时刻出现很多问题，团队成员集体熬夜加班，却将大把的时间花在了等待环境、等待验证上。
4. 开发提测质量不好，大量压力聚集到测试这一步，导致代码返工率很高。引入单元测试、代码审查，效果却都不明显。
5. 开发人员疲于应付业务，没有精力或者兴趣去精进技术，对 Git、命令行等强大工具的使用仅限于皮毛，士气低迷、工作效率低下。

如何定义研发效能？

团队能够持续地为用户产生有效价值的效率，包括有效性（Effectiveness）、效率（Efficiency）和可持续性（Sustainability）三个方面。

研发效能的提高，需要整个公司在研发流程、工程方法、个人效能和文化管理等方面进行精心设计。

2. 如何理解效能

硅谷的公司有没有 996？

在硅谷，很少有公司要求 996。不过，在初创公司，因为业务紧张、同事间的竞争，加班也很常见。但是，硅谷和国内的公司有一个很大的区别，就是硅谷的公司一般是任务驱动，只要完成任务就行，不管你花了多少时间。而国内很多实行 996 的公司不仅仅是要求完成任务，更强调工作时长。但其实，专注时长的这种操作在软件开发行业是不合理的，因为长期加班不能保证持续的高效产出。

从我以及身边许多开发者的经验来看，每天能够高效地产出代码五六个小时，已经相当不错 了。短期突击加班会有效果，但如果长期加班，通常效率、质量会下降，产生了 Bug 就要花费更多的精力去修复。如果这些 Bug 发布到了用户手上，损失就会更大，得不偿失。

长期加班还会出现无效加班的结果。比如，有个朋友在一家国内一流的互联网公司工作，据他反馈，公司实行 996，很多人加班其实是磨洋工，低效加班非常明显。可想而知，其他 推行 996 工作制的公司，大概率也会存在这种问题。

研发效能的模型是什么？

软件开发本质上就是一条超级灵活的流水线。这个流水线从产品需求出发，经过 开发、测试、发布、运维等环节，每一个环节的产出流动到下一个环节进行处理，最后交付给用户。

软件开发具有超强的灵活性：

• 最终产品目标的灵活性。在精益开发实践中，常常使用 MVP（最小可行性产品，Minimal Viable Product）来不断验证产品假设，经过不断调整最终形成产品。
• 节点之间关系的灵活性，比如流水线上的多个节点可以互相融合。
• 每个节点的灵活性，每一个生产环节都会不断涌现出新的生产方式/方法。
• 每个节点上的开发人员的灵活性，对一个相同的功能，可以选择很多不同的 方式、不同的工具来实现。

研发效能模型主要包括四个方面：优化流程、团队工程实践、个人工程实践以及文化和管理。

3. 如何度量效能

管理学大师彼得 · 德鲁克（Peter Drucker）曾经说过，“一个事务，你如果无法度量它， 就无法管理它”（If you can’t measure it, you can’t manage it）。要想提高研发效能，自然要首先解决效能的度量的问题。

事实上，效能的度量是一个出了名的难题，至今没有哪个公司敢号称已经找到了效能度量的完美答案。不仅如此，绝大部分软件公司在使用研发效能度量这个工具时，不但没有起到正向作用，还伤害了产出和团队氛围

研发效能的度量代表一组可量化的数据或参数，用来跟踪和评估开发过程的“健康”状况。 换句话说，研发效能的度量，从应用程序开发的生命周期中获取数据，并使用这些数据来衡量软件开发人员的工作效率。通过这样的度量，能够根据客观的数据而不是个人的主观意见去决策，从而实现以下几点：

• 跟踪团队的表现、提高团队的绩效。通过确定研发效率指标，公司可以明确团队和成员的工作预期，从而使得开发人员能够目标性更清晰地投入研发。
• 提高项目计划的精确度。团队负责人可以通过度量来估算一个需求端到端的成本，包括收集成本、设计系统成本、开发测试成本，以及运维成本等，来了解每项活动在项目总成本中的占比，从而更好地确定这些活动的优先级。
• 了解流程是否高效，寻找需要改进的关键领域。我们可以衡量进行每项研发活动所需的时间，并估算其对质量和生产效率的影响，然后比较成本和收益，最终确定哪些步骤是高效的，以及哪些步骤是需要改善的。

效能度量被大量误用，问题究竟出在哪儿？

研发效能难以度量的最根本原因在于，软件开发工作是一项创造性很强的知识性工作，非常复杂且伴随有大量不确定因素。

比如，软件产品的需求变化很快，需求文档的更新常常滞后于工程实现，甚至有的敏捷方法论提倡完全抛弃需求文档。

又比如，软件产品的实现方式有很大的不确定性。一个相同的功能，可以采用多种语言、框架、平台，使用各种不同的研发流程生产出来。

在这种情况下，我们很难通过度量来衡量这些不同研发方法和中间过程的优劣。 面对这样的一个复杂系统，我们不可能覆盖其全部参数。而如果这时，研发人员的利益和这个度量结果相关，那么他就很可能会通过“做数字”来欺骗度量系统。

关于这个主题，美国著名学者罗伯特·奥斯汀（Robert Austin）写过一本书，叫作 《衡量和管理组织绩效》(Measuring and Managing Performance in Organizations) 。他在这本书中给出的结论是，如果你不能度量一个事物的所有方面，那就不要去度量它。否则，你将得到“做数字”的欺骗行为。

我在文稿里放了一组有名的 Dilbert 漫画。这组漫画，讲的是一个公司宣布使用 Bug 修复 数量做度量，每修复一个 Bug 奖励 10 美元，消息一出，开发人员欢呼雀跃。一个程序员当场表示，当天下午就要给自己写出一辆汽车，因为他很容易就可以写出很多简单的 Bug，然后马上去修复它们。

通过这个例子，我想要和你说明的重点是：度量与绩效挂钩，结果是指标上去了，却没给软件产品带来任何好处。

研发效能难以度量的第二个原因，和上面提到的根本原因相关，但有其特殊性。很多公司有竖井（silo）存在，所以常常会把注意力放到某一两个竖井上，进行局部优化。但是，局部优化并不代表全局优化，甚至会让全局恶化。

研发效能难以度量的第三个原因在于，度量指标一般用来度量软件产品的生产过程和产品质量，但是公司真正需要关注的是产品能否解决用户问题，也就是说能否产生用户价值。技术产品输出和用户价值输出之间的沟壑难以打通。

4. 如何选择指标和方法

成功使用度量的关键在于：首先要对度量的分类有一个比较系统的了解，然 后根据效能度量的特点，以及自己团队的目标来选取度量指标和方法。

效能度量的指标分类：

• 速度：天下武功，唯快不破，速度指标主要用来衡量团队研发产品的速率。比如，前置时间，从任务产生到交付的时长。
• 准确度：关注产品是否跟计划吻合，跟用户需求吻合，能否提供较大的用户价值。一个例子是功能的采纳率，也就是有百分之多少的用户使用了功能x。
• 质量：如果质量有问题，产品的商业价值会被大打折扣。质量包括产品的性能、功能、可靠性、安全等方面。
• 个人效能：个人开发过程中的效率指标，比如开发环境生成速度、本地构建速度等。

效能度量的原则：效能度量不与绩效挂钩，是正确使用效能度量最重要的一点，再怎么强调也不为过。所以， 我向你推荐的效能度量的原则就是：效能度量不要与绩效挂钩，而应该作为参考和工具，帮助团队提高效能。

效能度量的推荐方法：

第一，目标驱动，度量对的事。提供用户价值是公司存在的根本，因此与之相关的指标是最最重要的。

第二，先从全局上找瓶颈，再深入细节。局部优化往往对全局优化无效，还会影响团队之间的关系，带来负面效果。正确的做法应该是，先检查全局，找到关键瓶颈之后，再进入细节分析和解决的环节。

使用累积流程图(Cumulative Flow Diagram)来发现瓶颈：

第三，通过主观的方式来评价、提高效能。推荐收集人工反馈的办法，来帮助我们做出尽量公平的主观评价。

针对个人研发效能作评价，可以采用类似 360 度绩效考评的方式来收集同事之间的评价。

第四，关注个人维度的指标提高效能。个人效能相关的度量，直接反映开发人员的开发效率和满意度，对团队产出影响很大。

一般来说，“个人调测环境构建速度”是一个比较重要的指标。它描述的是开发人员在本地做好一个改动，到能够进行本地调测的时长。开发人员每次修改自行验证都要经历这个步骤，对它进行优化非常有用。

我以前在 Facebook 的时候，后端代码及网站的绝大部分修改都可以在一分钟之内在本地开发机器上使用线上数据进行验证，非常爽快，效率极高。

但是，我曾经在其他公司见到过这样一种情况：一个修改需要在本地编码，上传到服务器编译，再通过工具下载到另外一个机器上验证。这个过程至少需要一个小时，在这种情况下， 即使是在验证时发现一个简单错误，修改后简单验证也需要再花费一个小时。

不难想象这种情况下开发者的沮丧心情。如果能解决个人效能维度上的痛点，必然对提高产出和士气有重大作用。

最后，我来分享一下我个人对效能度量的两大感受：

• 度量只是工具，不是目的。切记度量的真正的目标是提高效能，不要舍本逐末。比如说，如果度量花费的时间超过了收益，那就不要去做。
• 虽然我们推崇数字驱动，但在效能的度量上，不要迷信数字，适当使用主观反馈效果反而更好。

注: 本文内容摘抄于原文前4节，文中"我"代表原作者【葛俊】大佬视角。

原始文章和课程请访问: 研发效率破局之道