开发人员的生产力可以衡量吗？

介绍

专家们一致认为

那么，我们该做什么呢？

一个温和的建议

结论

介绍

如果你去谷歌搜索“衡量软件开发人员的生产力”，你会发现什么都找不到。真的，什么都没有。

好吧，也不是完全没有。你会找到一大堆链接。但几乎所有链接都会讨论如何有效地衡量软件开发人员的生产力。有些人甚至会认为根本不应该尝试。还有一些人会描述一些衡量开发人员生产力的技术，而这些技术，嗯，大家都知道，根本行不通。

过去曾有过许多勇敢的尝试来衡量开发人员的生产力，但似乎都以失败告终。（我们都知道，用“代码行数”来衡量生产力是会让人觉得可笑的。）实际上，任何可以应用于软件开发过程的客观衡量标准，都可能被“玩弄”而屈服。

开发过程中涉及的变量实在太多，难以涵盖所有因素。衡量其中任何一个变量，甚至只是衡量几个变量的组合，都无法有效地捕捉所有相关因素。你无法选择替代指标来衡量，但由于人性，开发人员的反应方式可能会影响测量结果。

关于这个话题已经有很多研究，但成果寥寥。每个负责填写开发人员评估或决定奖金发放的软件开发经理都曾为此苦苦挣扎。许多顶尖专家和大师都曾思考并研究过这个棘手的话题。

专家们一致认为

而没有一位专家提出一个衡量个人生产力的好主意或方法。衡量团队和项目生产力的优秀且有效的想法有很多，但衡量个人绩效和生产力的方法却严重匮乏，甚至完全缺乏。

例如，罗伯特·D·奥斯汀就这个主题写了一本名为《组织绩效衡量与管理》的书，他得出的结论是：除非你能对某件事进行100%的衡量——也就是说，它的每个方面——否则衡量就毫无意义。如果你试图衡量某项活动中涉及的不到100%的内容，你就会陷入他所说的“功能障碍”，或者你我称之为“钻系统空子”的境地。由于软件开发是一项极其复杂且富有创造性的工作，因此几乎不可能衡量其每个方面。通常，它实际上意味着你坐在电脑屏幕前。你如何衡量它的生产力呢？

以下是马丁·福勒在题为“无法衡量生产力”的文章中得出的结论：

“我认为我们必须承认这一点，我们确实无知。”

InfoWorld 的 Neil McAllister 在一篇题为“开发人员生产力指标的无用性”的文章中写道

然而，对于大多数其他公司来说，最好的办法或许是干脆放弃衡量开发人员生产力的想法，转而依赖那些久经考验的方法。没错：一支高效、高效的开发人员队伍往往源于高质量、高效的管理。可惜的是，目前还没有人为此开发出一个衡量标准。这是巧合吗？

Joel Spolsky 写道：

“衡量程序员的生产力相当困难；几乎任何你能想到的指标（调试代码行数、功能点、命令行参数数量）对游戏来说都是微不足道的，而且很难获得大型项目的具体数据，因为很少有两个程序员被要求做同样的事情。”

广受尊敬的学者、作家和顾问史蒂夫·麦康奈尔 (Steve McConnell)说：

“因此，尽管我看到了在研究环境中衡量个人表现的价值，但我认为很难找到在实际项目上证明这种努力是合理的案例。”

正如我所说的，很难找到一位顶尖专家来支持客观测量，而很容易找到许多人说你甚至不应该尝试。

所以，我认为认同“没有客观的方法来衡量软件开发人员的生产力”这一观点并不难。我知道这颇具争议，但在我看来，软件与其说是科学，不如说是艺术，而衡量艺术的生产力，嗯，根本行不通。人们不会告诉米开朗基罗，他画西斯廷教堂花了太长时间，因为他应该每天画1.4平方英尺而不是1.2平方英尺。那样就太荒谬了。

那么，我们该做什么呢？

任何负责管理和领导开发人员的人都会陷入困境。我们想要公平，但如果一切都是主观的，我们又该如何做到公平呢？

没有客观的衡量开发人员生产力的标准，并不意味着你无法衡量它。这只是意味着你必须主观地衡量它。我们就是这样做的，不是吗？你可以环顾你的工作室，看看哪些开发人员最高效。你可能认识一些开发人员，他们比其他人更快地编写出好的代码，并且更有效地修复错误。为了方便讨论，我将这位开发人员命名为“Jason”。

那么，你怎么知道杰森更有效率、更有价值呢？你当然知道。你一眼就能看出来。但如果你停下来思考，杰森有一些你可以发现并记录下来的特质。

我的意思是，如果你停下来审视杰森和他的作品，你会发现有些东西可以描述他这个人。当然，这些都是主观的，但你可以把它们写下来，并对这些主观的东西进行“客观”的衡量。

一个温和的建议

所以，我提出的方案是通过一套主观的衡量标准来衡量开发人员的生产力和价值。你可以把它看作是对“你肯定 Jason 很高效”这一说法的一种验证。

以下是列表：

生产率

• 开发人员在给定的时间内是否完成了合理量的工作？
• 开发人员修复错误的速度是否足够？

订婚

• 开发人员是否专注于自己的工作？
• 开发人员是否致力于按时交付软件？
• 开发人员是否致力于公司的成功？

注重品质

• 开发人员的代码在多大程度上按照设计运行？
• 开发人员在签入代码之前是否彻底测试了代码并相信它是正确的？
• 针对他/她的代码所报告的错误数量是否最少？
• 开发人员是否为所有新代码编写单元测试？
• 开发人员是否遵循童子军规则，使模块比他或她处理之前更干净？

代码库知识和管理

• 开发人员对分配给他/她的代码库有多大程度的理解？
• 开发人员是否对其团队的代码库负责，并在每个机会中改进它？
• 遵守编码指南和技术
• 开发人员的代码是否通常符合编码标准？
• 代码审查是否能发现最少的问题和差异？
• 开发人员是否使用依赖注入来确保代码解耦？

学习与技能

• 开发人员是否不断学习并提高自己的技能？
• 开发人员是否对软件开发工艺表现出热情？

个人责任

• 开发人员是否首先假设错误在于他或她的代码中？
• 开发人员是否明白他或她对其代码的正常运行负全部责任？
• 开发人员是否对他们的代码感到自豪，确保它干净、经过测试、易于阅读和易于维护？

再次强调，这七项都是主观衡量标准。所有问题都需要评估者做出主观判断。但一位优秀的领导/经理之所以能占据这样的位置，大概是因为他们对这些事情有着良好的判断力，因此他们应该能够运用这些“衡量标准”对杰森的生产力做出公正准确的评估。

大多数问题都要求回答“是”或“否”，但所有问题都可能引发与管理层甚至被评估开发人员的讨论。您可以在正式的评估表上使用这些指标。无论您如何运用它们，都可能比您现在可能采取的“一看便知”的方法更好。

结论

归根结底，任何对单个开发人员的生产力或价值的评估、评判或其他评估都将是主观的。在我们这个极其复杂的行业中，至今还没有人找到一种客观的方法来衡量个人生产力。但我想说，对一组特定的标准进行限定和判断是可能的，这仅仅是迈向我们行业迄今为止非常困难的事情的一小步，也是我们迈向这一目标的谦逊之举。

我的建议是，我们只需接受现实，并接受衡量开发人员绩效的主观性和缺乏客观性。