在研发管理中，如何准确评估研发人员的效能一直以来都是一个挑战。传统的评估方式大多依赖于观察软性技能的表现，如问题的跟进实时性、反馈的有效性、推动事情的能力，以及解决技术问题的能力。然而，对于研发人员而言，他们的代码质量和效率往往是最直接、最硬性的评价标准。而代码很多时候是看不到的，特别是当团队规模到达一定数量的时候。

代码的质量和开发效率是研发同学工作的核心。好的代码不仅要能完成预设的任务，也要易于理解、修改和测试，以便其他开发者在未来能够维护和改进。代码的质量和开发效率可以直接反映开发人员的技术能力和专业知识。因此对于一个研发管理者来说，要想掌控一个团队的情况，从代码出发，从代码量和代码质量来度量是一个不可或缺的角度。

为何要度量代码？

代码是软件产品的基础，深入理解代码可以帮助我们更好地了解产品的健康状况、性能状况和维护情况。更重要的是，通过深入分析代码，我们可以发现代码中可能存在的问题和改进点，以便提前发现并解决问题，降低项目风险。基于代码的研发效能度量为我们提供了一个量化、可度量的评估标准，从而使我们能够更科学、更有效地管理和优化研发过程和研发分工。

基于代码的度量是什么？

基于代码的研发效能度量是一种通过对代码及代码提交进行深入分析和理解，从中洞察出可能存在的问题和改进点，以提高研发效率和产品质量的方法。这涉及到代码质量分析、代码性能分析、代码测试分析、代码维护性分析以及技术债务分析等多个方面。

从实际落地来说，基于代码的研发效能度量通常涉及到以下几个方面：

1. 代码质量：这是衡量代码健康状况的重要指标。

   • 代码复杂度：例如，使用圈复杂度（Cyclomatic Complexity）或 Halstead 复杂度（Halstead Complexity）度量代码的逻辑复杂度。
   • 代码规范性：如代码是否遵循了 PEP 8（Python编程规范）或其他语言的编程规范。
   • 代码重复率：如通过工具（如 SonarQube 或 PMD ）检测代码的重复部分，计算代码重复率。
   • 用例覆盖率：如使用工具（如 JUnit 和 Cobertura ）运行单元测试和集成测试，计算用例覆盖率。
   • 注释覆盖率：SonarQube 等工具可以分析出代码覆盖度

2. 开发活动：这是了解开发团队工作模式的重要度量。

   • 提交频率：如通过 Github 或其他版本控制系统统计每个开发人员的提交频率。
   • 代码修改频率：如统计某段代码或某个文件被修改的频率，以理解代码的稳定性。

3. 问题和缺陷：这是评估代码质量问题和风险的关键度量。

   • 缺陷密度：例如，通过错误跟踪系统（如Jira或Bugzilla）统计缺陷数量，然后除以代码行数，计算缺陷密度。
   • 问题解决时间：例如，统计从发现问题到解决问题的平均时间，了解团队的响应效率。

以上就是基于代码的研发效能洞察的主要组成部分。这些度量有助于我们理解代码的健康状况、开发过程的效率，以及代码质量的问题和风险。需要注意的是，这些度量并不能全面反映研发效能，还需要结合具体的项目情况和团队情况进行分析。

基于代码的研发效能度量如何实施

将以上的这些组成部分、时间、人、项目、团队这些结合起来就是一个基本完整的基于代码的研发效能分析系统。

做基于代码的研发效能洞察无非是回答如下的 2 类问题：

1. 做了什么，做了多少
   • 你的团队做了什么，做了多少
   • 你的团队成员做了什么，做了多少
   • 每个成员在团队中的水平处于什么样的水平，有没有特别突出的（多或少）
2. 做得怎么样
   • 你的团队的代码质量如何
   • 有没有比较突出（好或坏）的成员
   • 有没有共性的质量问题

要想回答这些问题，基于代码层面，通过代码度量研发的研发效能，影响力产出，代码质量等，拿到客观的数据度量到人、团队、项目。

我们做代码的洞察实施简化后可以有 4 步：

1.引入工具或系统：将代码这个盒子打开，看到度量后的数据。这里当然会有一个问题分析、行业方案对比的过程。

1. 机制化跟进：需要有一个组织来承接事项，无组织即无成果。结合管理人员的机制化跟进，根据度量的数据和系统的指标，以某个时间间隔来做洞察，发现问题。
2. 整体洞察：从下往上，形成整体效能的洞察，根据发现的问题，明确代码产出的问题点和能衡量状态的指标。
3. 复盘：以 3 个月以一个区间来盘点指标和问题，清晰团队/项目的变化。

基于代码的研发效能度量的优势与挑战

当我们引入某些工具或系统来做了基于代码的度量或洞察后，可以得到如下的一些东西：

1. 全面的代码质量管理：通常能够全面地对代码质量进行管理，包括代码质量分析、代码审查等。
2. 技术债务管理：通常提供了一种有效的方式来管理技术债务。
3. 提高团队效率：通过对代码的持续分析和审查，可以帮助团队提高效率，减少错误和问题。
4. 提供具有洞察力的数据和报告：通常能够提供具有洞察力的数据和报告，帮助团队更好地理解代码质量和研发效能。

以上是一些好的方面，但是也有一些不好的点：

1. 需要一定的学习和适应：对于新的系统和工具，团队成员可能需要一段时间来学习和适应。
2. 可能存在一定的成本：这类系统通常需要付费使用，这可能会增加公司的开支。
3. 可能与现有的流程和工具不兼容：如果团队已经有了自己的流程和工具，那么使用新的系统可能会导致一些兼容性问题。
4. 安全或隐私问题：如果系统是基于云的服务，这意味着代码需要上传到外部服务器进行分析。这可能会引发一些安全和隐私问题。一般我们选择通过私有化部署来解决，但是成本会更高一些。

最后，随着时间的推移，可能会出现「面向指标编程」的情况。这通常发生在过度重视某些度量标准并以此作为主要驱动开发的团队或组织中。这些度量标准可能包括代码行数、问题数、提交频率、测试覆盖率等。

这样可能会带来一些问题：

1. 优化错误的指标： 有时，开发同学可能会在不影响或甚至损害总体产品质量的情况下优化这些指标。比如，如果过度关注代码行数，开发者可能会写出冗长和复杂的代码来增加代码行数。
2. 忽视质量和实用性： 过度关注指标可能会导致开发者忽视代码质量、可读性、可维护性和实用性。例如，开发者可能编写无实际价值的测试，只是为了提高测试覆盖率。
3. 鼓励短视行为： 如果某些指标被用作评估性能或提升的基准，开发者可能会采取短期行为来满足这些指标，而忽视了长期的技术健康状况。

为避免「面向指标编程」，作为团队的管理者应该谨慎选择和使用度量标准。应该选择那些能反映出代码质量、可维护性和实用性的指标，并且要注意平衡多个指标，避免过度优化某一个指标。同时，要培养一个开放的团队文化，鼓励开发同学关注长期的技术健康状况，而不仅仅是满足短期的指标。

在互联网软件企业，今年是一个大家都在非常努力降本增效的年份，包括且不限于人员优化、人员结构优化、技术成本优化，提高人效，提升研发效能等等。 这篇文章我们从研发效能出发，尝试梳理一下打造高效能研发团队的 5 个关键步骤：目标、流程、团队、个人、度量。

1. 找到正确的目标

技术最终都是通过业务产生价值，就算是技术类的产品，最终产生价值也是业务，只是这个业务是一个强技术属性的业务。

一个高效能的研发团队管理者，其首要任务是为团队找到正确的方向和目标。这里正确的目标可以分为业务目标和技术目标。

业务目标的设定可以分为两步：

1. 和业务方、上级沟通，弄清楚他们的目标是什么，以及明确他们对于研发团队的预期是什么；
2. 在业务方目标和上级预期目标的基础上，分解目标，内化为带有一定进取的团队目标。

技术目标的设定可以分为两类：

1. 解决过去留下来的问题，历史的问题我们通常称之为技术债，技术债分为主动债务和被动任务，主动债务大多数是在业务发展过程中为了追求速度而做的一种技术妥协，而被动债务大多数是团队能力或水平不足、业务的演化或技术的发展导致的代码或架构劣化任务，或者不再适用于当下的环境。技术债不一定是一个坏事，一个产品进化到要偿还技术债时，说明业务应该还不错了，在这个当下，找准时机，有计划的偿还一些技术债务是非常有必要的事情。
2. 解决将来可能出现的问题，将来的问题我们一般称为技术前瞻性，即对即将出现或已经出现但不是很成熟的技术做一些预研和准备，居安思危，提前布局技术投资。

2. 优化流程，做到极致

所谓流程，是基于时间线做一件事的过程，是指一系列的、连续的、有规律的活动，而这些活动以特定的方式进行，并导致特定的结果的产生。其关注的是过程，我们希望通过优化和设计过程来最终达到一个更好的结果。我们做任何一件事情时，都会有流程，只不过有些流程是自发的，有些是被设计出来的，或者说是优化后的。在团队演化的过程中，流程优化和流程管理经常会提出，这些操作都是为了提炼流程或优化流程，让效率更高，让质量更有保障。

流程最终目的在于创造价值，也就是增值，这里价值在研发过程中更多的是质量提高、效率提升等。

研发流程要重点关注两个问题：

1. 流程对于做正确的事的辅助作用，是否能通过「过程正义」得到「结果正义」；
2. 流程本身的效率，是否整个流程是顺畅且高效的。

在具体实施时我们可以考虑如下一些方式：

1. 提高流程的自动化水平或者说工程化水平，如快速的本地构建速度、完善的自测环境、自动化测试、持续集成、流程的系统化等等；
2. 减少流程的沟通成本，比如说 DevOps 减少的是研发和运维的沟通成本，又或者全栈，减少的是前后端的沟通成本；
3. 流程分层：针对不同的级别将流程描述清楚，高层次流程较为粗略，中层流程和操作级流程会非常详细，以方便项目各级管理者和基层员工按照相应的流程开展工作；
4. 大处着眼，小处着手：先全局出发找问题，再深入细节解决问题，比如我们希望提升研发流程的交付速度，可以收集产品周期中每一个阶段所占用的时间，包括计划的时间和最后实际花费的时间，然后通过对比寻找问题最严重的环节，再去解决这个环节。在具体落地时可以考虑流程的可视化。

3. 提升团队效能

我们是要打造一个高效能的研发团队，团队是作为一个整体存在，在团队之间有分工，团队成员之间有协同，沟通等等，如何让 1 + 1 > 2 是在团队层面要解决的问题。以下有一些方法可以提升团队的研发效能：

1. 减少团队认知成本：如统一开发 IDE；提供完善且性能强劲的统一开发环境和联调环境；团队分工以模块负责人为核心，一个小团队一直聚集于一个模块，不经常轮换；
2. 增加知识流通，促进知识共享：如知识库的建设、好用的文档系统、代码审查、机制化的分享会等；
3. 团队的技术债会慢慢累积，在尽量减少债务的前提下把业务跑出来后，在适当的时候偿还部分债务，出来混迟早都是要还的，技术债也一样。
4. 快速开发模式，尝试测试左移或测试右移。
   • 测试左移是指在研发流程中，把测试的覆盖范围从传统的测试节点中释放出来，将其向左扩展，介入代码提测之前的部分，如开发阶段阶段，需求评审阶段，让研发人员在架构设计时就考虑产品的可测试性，并尽量进行开发自测，同时评估需求的质量，比如分析需求的合理性以及完整性等。
   • 测试右移是指把测试的覆盖范围从传统的测试环节中切出来，将其向右扩展，更多地融入代码部署、发布，甚至上线之后的步骤中。
5. 灰度发布，监控，A/B测试，混沌工程
6. 专业的项目管理，研发人数达到 30 人以上时，由于缺乏项目过程中的沟通、控制能力，是造成开发项目混乱，需求返工，研发效率低下的重要原因。如果能够在产品规划时提前发现新产品的技术难点，就可以提前进行相关的技术研究和技术开发工作，减少产品开发项目实施过程中的技术风险。在项目过程中，加强沟通、协调，及时发现各种风险因素和意外情况并采取应对措施，有助于项目计划的顺利实施，从而提高研发的效率。

4. 强化单兵能力

研发最终是要落在人身上，强化单兵能力，对于提升整个团队的效能有极大的促进作用，单兵能力的高低能决定团队总体效能的高低。

一个人的单兵能力可以从目标、效率和初心三个方面来分析：

4.1 目标

高效能人士的七个习惯的第 2、3 个习惯分别是以终为始和要事第一，当我们需要做一件事情的时候先明确本质的要解决的问题是什么，规避掉「XY Problem」，寻找到解决方案以及实现方案的过程中聚焦最重要的任务。

在个人的目标中，我们常见的目标包括业务成功、帮助团队、个人成长。这三个目标是有递进关系的。

• 业务成功是我们工作的最根本目标，也是基础；
• 在业务成功的基础上，下一步考虑帮助团队成长；
• 在帮助团队的同时，给自己带来一些直接或间接的成长机会。

4.2 效率/速度

可以仔细评估个人研发过程中哪些部分可以提速，如在开发前、开发中和开发后：

1. 开发前：完善而友好的开发环境，不要过度设计，在保证一定扩展性的够用就行，鼓励方案的讨论，并将其机制化；
2. 开发中：熟悉而高效的编辑工具和代码管理工具（如 Vim、Git，需要有一些刻意练习）让你能高效的编码，个人技能的边界扩展（如前端懂一些后端，在沟通交流中障碍就会很多；甚至全栈，沟通交流在自己脑袋里面完成）；
3. 开发后：尽快让代码跑起来，快速的本地构建、完善而快速的联调环境，使用单元测试和持续集成。

4.3 初心

对于业务，对于当下手上的事情能自驱的完成，最好是将目标和兴趣结合起来，主动的提出自己的想法并推动实施。

5. 合理度量但不追逐度量

著名管理大师德鲁克有句名言：“没有度量就没有管理”。

当我们开始想把研发过程的效能管理起来的时候，一定需要明确度量，即哪些指标可以表示效能的高低，并以此来判断是否有改进。 我们可以从三个方面来度量：

1. 研发效率/速度：开发的速度，构建的速度，需求的吞吐率，需求的周期，代码行数，平均修复时间等；
2. 研发质量：测试 BUG 数、新旧 BUG 比，缺陷率、缺陷修复率、线上 BUG 数、线上事故数，性能、安全等；
3. 业务价值：营收、NPS、功能使用用户数、客服反馈数等。

度量的大概过程是从研发过程中获取数据，并用这些数据来评估过程的效率，质量和价值。 通过度量来评估研发团队的表现，发现对研发工作效率有阻碍的地方，了解流程是否有待改进的关键点并寻求改进的方案。

在我们度量的过程中，度量指标尽量不要与绩效挂钩，而是应该作为参考和工具，帮助团队提高效能。 不要过度追逐度量，不要让度量最后变成一个「数字游戏」，避免只关注一些局部指标而导致局部优化和全局优化脱节的情况，对于过度的不顾大局的局部优化说 No，因为这种局部的优化可能导致整体效能的降低。

6. 小结

我们实现一个系统或一个需求，其实就是在生产一个产品，需要若干个「工序」，从产品需求出发，经过开发、测试、发布、运维等环节，从一种工种流转到另一个工种，最后交付给用户。 在整个研发过程中，把每道工序定义清楚，明确输入和输出的标准，保证每个工序产出的质量，提升每个工序的速度，衔接好工序与工序，就能让整个过程更高效能的流转。

从这里可以看出一个高效能的过程包括如下三个方面：

1. 清晰的「工序」定义、每个工序有标准的输入和输出；
2. 保证每个「工序」的质量和速度，做到极致；
3. 保障「工序」之间连接的有序；

转化成研发过程，一个高效能的开发过程包括如下四个方面：

1. 清晰定义每个环节，明确每个环节的输入和输出的标准，做好自测；
2. 保证每个环节的质量，产品需求有需求的质量要求，设计有设计的质量要求，研发有研发的质量要求；
3. 强化每个环节中个体的单兵能力，提升每个环节的速度；
4. 通过专业的项目管理，保障环节之间的有序进行，不快一步也不慢一步。

那么如何简单评估一个研发团队是否是高效能的呢？

看这个研发团队的一个需求从想法到上线，全流程平均生命周期需要多久，上线后的质量如何。

你好，我是潘锦，超过 10 年的研发管理和技术架构经历，出过书，创过业，带过百人团队，也在腾讯，A 股上市公司呆过一些年头，现在在一家 C 轮的公司负责一些技术方面的管理工作。早年做过 NOI 和 ACM，对前端架构、跨端、后端架构、云原生、DevOps 等技术始终保持着浓厚的兴趣，平时喜欢读书、思考，终身学习实践者，欢迎一起交流学习。微信公众号：架构和远方，博客： www.phppan.com