Amir Kirsh
开发人员工作效率是一种衡量标准，可用于确定团队是否能够迅速高效地编写出运行良好且易于维护的高质量软件。开发人员工作效率越高，应用程序创建和面世的速度越快，获得价值回报的时间越短，投资回报越高。
数十年来，在投资回报和业务绩效的驱动下，开发人员工作效率无疑始终是研究的重点。最近受新冠疫情影响，软件行业内，包括开发人员在内的许多从业人员都转为在家远程办公。公司不得不克服新挑战，保证开发团队联系紧密，协作良好、高效。如果能够做到这一点，那么无疑会在未来的几年里，形成一种新的办公模式。
开发人员工作效率与开发人员速度有关。开发人员速度是麦肯锡公司在微软的帮助下于 2020 年首次发布的度量指标。开发人员是否在适当的环境下拥有适当的工具来开展创新，与开发人员速度息息相关，而这又与业务绩效密切关联。你可以下载我们的白皮书，其中列出了组织内部如何提高开发人员速度的方法。其中，工作效率是速度的一个子集，而本文主题侧重于解决工作效率这方面的问题。
在我们开始前，我还要提醒你一点：衡量和提高开发人员工作效率往往与开发环境有关。不过，我们热爱 C++（不单只是 C++，但大部分都是 C++），所以这篇博客里的大部分引用都使用了 C++ 语言。这应该不会困扰到你。即使你从未使用过 C++，用的是其它语言编程，相信你仍然能够很轻松地将 C++ 转换成你常用的编程语言和生态系统。
开发人员工作效率的神话和误解
长时间以来，一些组织内流传着关于开发人员工作效率的若干神话和误解。其中一个常见的错误观点就是：只使用一个合适的度量指标，就能轻松、有效地衡量开发人员工作效率。但实际上，从来没有哪种测量工具可以做到这一点，因为不同行业和组织之间可能存在太多不同的因素。实践中，可以使用若干度量指标的加权组合，但是即便如此，根据所在领域的不同，选择的度量指标和具体权重也会有所不同。
另一种错误理解是，开发人员工作效率主要关系到个人。但实际上，它影响的范围更深、更广。当然，团队中每个成员的绩效都有其价值，但除此以外，在团体活动中，他们对团队的贡献才是最关键的。团队中个体获得成功，并不意味着项目一定就会成功。其中还涉及到团队合作的程度。事实上，一加一大于二，整体并不仅仅是简单的各个部分的总和。
一些开发人员认为，衡量工作效率只是让管理者受益。其实，不管是个人还是团队，度量指标都可以为他们带来帮助。的确，管理者往往对工作效率的度量指标感兴趣，但除了他们以外，其实还有一些其他人员也想要了解工作进度并提高成功的机会。
开发人员工作效率是否能够衡量，是否应该衡量？
按常理讲，如果没有有效的衡量方法，那么就无法比较两种事物，或判断各版本之间的进度。也就是说，如果无法衡量目前你的处境和进步程度，那么就无法做出改进。因此，衡量开发人员的工作效率这一需求不仅合情合理，对于想要更高效发展的组织来说，还非常重要。
这就是为什么我们确实应该衡量工作效率。接下来要讨论就是如何衡量。要尽可能提高开发人员的工作效率，其中一项障碍就是：缺乏衡量标准。许多公司一直都有衡量开发人员工作效率的内部度量指标，其中一些与代码质量有关，一些与重要产品发布等活动有关。但是它们并没有统一的综合度量指标，因为衡量工作效率还面临诸多挑战。
衡量开发人员工作效率所面临的挑战
衡量开发人员工作效率表面上看只是一项很简单的任务，但事实并非如此。让我们选择几个传统的度量指标来加以说明。例如，统计每天编写的源代码行数 (LOC)，听起来似乎很合理，但就连新手程序员都知道，数量多并不一定就是更好的。
首先，物理代码行和逻辑代码行之间存在差异，一行也可能触发多个动作。这并非简单的一行与多行统计的问题，因为有些时候，隔开指令可以使代码更具可读性，而有时，紧凑的代码可能会更有效率。额外的注释行便于更好地维护代码，但行数过多可能会产生相反的效果。这往往需要权衡好精简与清晰两方面，而一个简单的度量指标，是远远不够的。
此外还有一些其它严重问题。当开发人员知晓其工作会按照代码行数进行衡量时，他们可能会编写出更冗长的代码，试图以量取胜。不同的编程语言在完成相同的任务时，所需的代码行数，有的更多，有的更少。这种情况在使用相同编程语言的项目中可能无关紧要，但在混合多种编程语言的大型项目中，却极为常见。例如，前端开发工作通常会采用不同的语言编写，而不是仅与数据库进行低等级交互的例行程序。相反，这些语言存在于同一项目中。
此外，利用代码行有效地衡量工作效率，还需要基于开发阶段进行加权处理。新增功能时，可能一开始需要大量的编码工作。当逐步转为调试时，可能只需要添加或修改极少数代码行。然而，测试和调试所花的功夫与开发初期相当，甚至更费时费力，但采用这种一维衡量标准，得出的绩效分数可能会很低。
同时，在某些情况下，整合新的公共库或将各部分代码统一成一个整体后，会减少代码行，这其实是一项成就；但按照代码行衡量标准，行数减少就不好。这样的话，反而不利于鼓励开发人员开展整合和统一工作。
工作小时数、缺陷数量、发现的错误数量、完成的工作单数量、静态代码分析得分、已识别漏洞的关键程度、敏捷环境内的故事点、功能数量、发布次数等都存在类似的争议。此外，审查代码时，编码风格、遵循编码惯例等方面的主观评价（表扬或批评），也是衡量开发人员工作效率的要点。
在某个行业、开发环境、公司文化或特定项目中有效的事物，到了其他行业、环境、公司或项目中可能就不管用了。更糟的是，选择了错误的度量指标，可能会损害整个团队的士气。例如，严格遵守计划发布和定期发布。发布多，且每次发布都有显著的提升，这当然值得赞扬。但是，固定不变的截止日期，不仅会向团队成员施加过大的压力，而且毫无疑问会导致错误的产生。这些错误会在后续的生产环节中显现出来。如果这些错误是被终端用户发现报告的，那么声誉可能会受损。相比采取积极主动的办法（即便花费的时间更长），这造成的代价会大得多。
最低底线就是使用一种不考虑具体环境的单一衡量方法，只是这样可能会导致出现更大的问题。不过在实现不常用功能时，不会造成重大业务影响。除非创新拥有合理发展路径，可以推动商业价值，否则唯一看起来还不错的就只有度量指标得分。同样地，软件发布多个版本，可能会损害质量，引入不必要的风险。所有这些都是衡量开发人员的工作效率时所面临的挑战。
基于 Git 的度量指标
与软件开发的其它领域一样，代码的度量指标也在不断地演变发展。没有完美的代码度量指标，不代表目前没有较好的衡量标准，也不能说明我们无法找到更好的标准。例如，有几家公司已经开始使用与其源控制系统相关的度量指标。这种元数据分析从新的视角出发，促进解决“开发人员工作效率是否已充分衡量”这一问题。
代码改动
目前正在使用的一种基于 Git 的度量指标是代码改动。这个理念，也称为“返工”，与代码段的编辑频率有关。代码范围各不相同，可能是短函数、大类，也可能是整个文件。使用这种度量指标的问题是：代码改动是好是坏并不一定。需要根据具体情况而定。代码改动大可能表明：即便到了最后一分钟，员工仍然在努力工作，以便让事情顺利运转。但是，这也可能是为了提高可维护性，发布中途出现了重大重构任务。这意味着，新改动量的意义重大，而且近度也是一项（需要考虑的）因素。
对于常规返工率较高的代码段，改动也许是因为要定期添加新功能，这与动态环境密切相关；也许是开发人员可能没使用正确的代码，总是不断地发现新的错误或性能问题。不管怎样，所述代码最近已经进入只需要极少编辑的阶段，目前已经稳定。要统计变动情况，查看一定时间周期内的代码变动，是一种有效的限定方式。
其中一种方法就是查看代码首次提交之后一个月内的变动率。代码经常变动，可能表示没有充分考虑复杂性，或者是存在最终会影响上一级项目的设计缺陷。另一种方法针对的是更为成熟的产品，查看导致计划发布的返工率。
不同组织、团队，甚至不同编程语言之间的代码变动程度也不同。我们都知道，如果代码一直变化，那么引入错误的概率会更高。当然，代码必定需要更新，但怎样的频率才算是过于频繁？ 这就是需要从组织层面考虑和测试的问题，如此才能确定合理的代码变动率。
审查覆盖率
目前正在使用的另一种基于 Git 的度量指标是审查覆盖率。让团队成员审查和评价同事们的代码，是一种常见的做法，对大小团队来说，都有好处。代码审查做得越好，软件质量越高，这一点毋庸置疑，因此考虑需要接受同行审查的代码库百分比，是合理且有意义的。
未来代码度量指标的发展
传统的代码度量指标已经可以有效地服务于项目经理和开发人员，但是，这并不表示没有改进的空间。尤其是，随着技术的进步，更有可能出现新的度量指标。例如，目前使用的基于 Git 的度量指标，在源控制广泛应用前根本无法实现，但现在却可以使用了；同时，根据编程语言不同，某些度量指标会更有效。随着编程语言、环境和技术不断演变，代码的度量指标当然也会不断发展。
正确衡量开发人员工作效率的不同方法
诚然，衡量开发人员的工作效率时会面临各种挑战。但同时，我们知道，它不仅有助于实现更优质的产品，同时也是我们走向优质产品道路的基本要素。通过组合法，可以形成不同的方法，各有其优缺点。
输入输出测量
其中一种方法就是输入输出测量法。采用这种方法，人们会从输入输出的角度，考虑软件开发的工作效率。上述工作小时数就是一种输入衡量标准。这方面存在若干问题，最重要的就是，除了静观其变，这种方法没有为人们展现其价值留出任何空间。我们不能仅凭“星期五上午发布后，下午工作仍然很饱和”，就判定工作效率高，甚至集体工作效率高。
要记住的一点是：输出不一定就是积极正向的。输出时间过长，可能导致程序员精疲力尽，进而降低工作效率。这样的话，程序员可能会犯错，反过来又会催生人际方面的问题，包括团队成员之间的争执。这非但不会促进形成健康的创新文化，反而导致员工士气低落、缺乏协作。选择任意输出衡量标准，如软件发布次数，都会出现类似问题。基本上，只要过度使用某种度量指标，就会导致其他价值无法展现。
SPACE 框架
开发人员工作效率的 SPACE 框架基于 5 方面衡量绩效：(a) 满意度、(b) 绩效、(c) 活动、(d) 沟通和协作，以及 (e) 效率。此框架的制定者很清楚，不可能使用单一的度量指标来衡量开发人员的工作效率，相反，他们创建了一种可以囊括所有方面的多维度衡量标准。
满意度
SPACE 不仅注重建立和改善开发人员的体验，同时还聚焦于促进健康的团队合作文化。理由是开发人员满意度与工作效率高度相关，积极的工作环境有助于保持较高的工作效率。反过来，如果工作压力过大，员工会感到精疲力尽，极为不利于提高工作效率。
绩效：结果与产出的比较
SPACE 框架下的绩效衡量与结果有关，但不是严格意义上的输出。考虑上述度量指标，统计发布次数。相比能否按时发布，更重要的是能否实现发布的目标。显然，这个结果与项目长期良好状态的关联更密切。
活动
SPACE 框架包括活动的概念，即基本的工作单元，如提交代码块。活动可以采用一系列代码度量指标来进行描述和衡量，正如我们已经讨论的那样，活动只是整体的一部分，并且与环境高度相关。但是，衡量进度时，代码度量指标起着至关重要的作用，需要加以考虑。
沟通和协作
我们都知道，项目过大，一个人完不成的时候，需要团队合作。而高效的协作，需要切实有效的沟通，以及一系列足以处理项目各方面工作所需的技能。更新的技能审核，以及证明团队成员密切合作的适当网络度量指标，是衡量和促进协作的宝贵文件。
效率
效率是诸多工具、技巧和框架的驱动因素。在许多情况下，按时完成项目和预算是关键因素，但是，无论处于哪个行业，这样做的代价并必须加以控制，但又不能一成不变。高效的流程体现在项目从开始到交付的方方面面，通过一系列完善且优化步骤实现。效率就是要缩短整个流程中的时延，例如，减少参与的团队数量，并考虑因此花销而损失的时间。
SPACE 的终极目标是逐渐发展技术负债更少、代码更可维护的更优质代码库，从而获得更好的投资回报。这种基于多方面的方法新增了一层管理以及问责制的多个重要方面。
OKR
OKR 框架适用于目标管理，涉及目标和关键结果等概念。本质上来讲，OKR 由一个目标（明确方向）和多个关键结果组成，是指示目标实现进度的衡量标准。OKR 将问题分解成可管理的目标，通过明确定义成功的标准来增加透明度，帮助开发人员专注于手头上的任务。这是一种非常直接（同时也非常聪明）的方法。你可以衡量实际目标，但明确相应的代价。项目各部分需要定义新的目标和测量，有时甚至需要进行迭代。如果在整个项目生命周期内都没有设定新的目标或更新测量，我们将回到定向测量。
提高开发人员工作效率的方法
关于这一点，我们知道，对某一团队、某一项目或某一公司有效的方法，对其他团队、项目或公司可能不管用，即便是同类项目。选择适合你所在团队和项目的适当衡量标准（即使不是“完美的衡量标准”），将有助于衡量开发人员工作效率，获得定量理解，便于进一步分析。选择到可用的衡量标准后，就可以考虑如何进行改进了。
工作效率工具
目前有无数种工作效率工具，可以帮助提高开发人员工作效率（当然，Incredibuild 也居于前列）。无论你是否考虑 C++ 开发人员工作效率工具还是更常用的 DevOps 工具，这些解决方案都很有用。
即便是现代 IDE 中内置的简单增效功能，都有助于促进协作，建立具有优质代码库的产品。为了获得最佳开发人员体验，优化 IDE 也很重要。例如，微软就提供了优化 Visual Studio 的技巧。
而对于更倾向于选择 Vim 等简单工具的人员，了解 Vim 的技巧或正在使用的任何工具，当然同样有用。
此外，我们还需要一种测量办法，一种更为主观，涉及人工评估，但同样很重要的测量办法：是否使用了正确的工具？可以自行设置一套测量工具：列出一系列工具域，检查是否在各个域使用了适当的工具，以及是否正确地使用了这些工具（有关 C++ 工具的更多信息，观看 2022 最佳 C++ 生态系统虚拟圆桌会，会议中讨论了 C++ 生态系统和工具堆栈）。
关注效率
提高工作效率不仅仅是一项计划，还是一种思维模式，涉及一系列技术。例如，从长远看，积极努力地，可以提高工作效率。同样地，你还应采用各种方法缩短 C++ 编译时间，努力改进开发时间。
采用自动化，也可以提高效率。显然，如果测试大多数都是手动测试，那么效率肯定不高。DevOps 流程就存在这样的问题。
最后的感想
在以最短的时间内上市高质量应用程序时，提高开发人员工作效率是其中的重要一环。目前并没有完美的衡量开发人员工作效率的度量指标或方法，但已经有许多流行方案，可供你根据具体环境进行选择。随着软件开发领域的进步，出现了许多新的度量指标，代码质量和开发人员工作效率的衡量也逐渐兴起。
采用和开发高效且切实适用于你所在环境的代码度量指标，有助于衡量进度，不仅仅针对具体编码人员的进度，还有团队协作进度。这一点非常重要，因为工作效率绝非仅与个人有关。只有准确衡量工作效率，才能采用适当工具和技术，着重提高工作效率。同时，定期检查度量指标是否能够帮助你达成目标，这一点同样非常重要，否则，如果遵循了错误的度量指标（如朴素的代码行度量指标），偏离方向之后，只会产生虚假的进度结果。
采用正确的工具和技术，可以积极主动地解决并成功测量许多问题，其中就包括提高代码质量。而正确的规划和协作，可以减少错误，例如，采用静态代码分析工具等生产前准备工作，可以有助于控制软件漏洞等问题。只要恰当的度量指标、工具和技术落实到位，确实有可能提高工作效率，并获得持续进步。
最终，合理推动提高和衡量开发人员工作效率，不仅有助于实现更好的产品、更高的质量和更短的上市时间，还能营造更好的工作环境：管理更有序、突发状况更少、灭火救场的情况更少。
