打破衡量开发人员生产力的概念

衡量开发人员的生产力是软件项目管理的一个方面，在过去的几十年里，它一直是整个组织进行大量审查的来源。事实上，一些经理认为这是一项如此复杂的任务。

也就是说，大多数项目经理和 CEO 都同意，虽然定义理想的指标来评估软件开发人员的效率是一个复杂的过程，但毫无疑问，所获得的信息是有益的。

在软件项目管理中，根据项目管理协会 ( PMI ) 共享的信息，大约 50% 的项目实施失败，这在一定程度上意味着生产力在任何软件产品推出的成功率中都起着决定性的作用。

出于这个原因，与许多其他原因一样，为了评估给定软件项目的进展（或缺乏进展），经理们依靠一系列指标来衡量开发人员的生产力。

总的来说，每当经理想到项目管理的指标时，他们会立即想到与输入和输出相关的指标。虽然查看这些指标有一些价值，但软件开发与任何其他类型的项目不同，这意味着在其他项目中应用用于输入和输出的相同原则指标存在危险。

为什么传统的输入指标不能衡量开发人员的生产力？

输入指标是一种衡量单位，它描述了一个人投入项目以实现特定输出的所有有形和无形元素。从本质上讲，它们描述了影响您的企业建立的最终总体目标所需的一系列行动或行为。

通常，它们是可计算的或易于数值量化的，也可以很容易地在内部进行控制。

考虑到这一点，对于一般项目，输入指标可能是指着陆页或付费广告上特定数量的点击率，甚至可以计算对潜在客户的呼出电话数量，具体取决于业务模型和类型的项目。

然而，对于软件项目，即软件开发人员来说，输入度量往往具有略微不同的特征，不仅在它们的性质方面，而且主要在它们作为测量工具的有效性方面。

让我们仔细看看在软件开发中使用的一些更常见的，以及为什么它们是管理者不应该陷入的陷阱：

工作时间

顾名思义，工作时间只是指开发人员致力于您的项目的可量化的小时数或时间量。对许多经理来说，这是一个默认的输入指标，对他们来说，它是员工生产力的明确指标，并且在他们不知道的情况下，这是他们发现自己陷入的狡猾陷阱的开始。

一个人在给定任务上花费的小时数并不一定意味着一个人在那段时间里一直很有生产力。所有工作都是积极工作的观点是一种谬论，它削弱了生产力的概念。

一方面，与完成工作量相关的数值并未考虑开发人员是否在生病、分心或筋疲力尽时工作。

因此，该指标本身并没有考虑纠正做得不好的任务所需的时间，也没有说明为修复开发人员犯下的任何错误而投入的任何经济补偿。

另一方面（尤其是与内部开发人员相关），在场并长时间工作，并不一定意味着开发人员的工作效率很高。同样，对于那些在别人预料到之前离开办公室的开发人员经常扬起的眉毛弊大于利。

简而言之，这种文化间接地鼓励开发人员花更多时间在工作上，试图让其他人相信他们的工作效率很高，这种副作用会对员工敬业度产生负面影响，进而（具有讽刺意味地）生产力。

这并不一定意味着该指标完全不好：这意味着它不应该以表面价值来衡量。

生成的代码

根据软件开发人员编写的代码行数来衡量生产力，除了计算工作时间之外，您无需进一步确定真正的生产力。

理解这一点的最好方法是将编写代码与写一本书进行比较。

一个句子中的更多单词并不意味着你的写作更好：事实上，它最终可能会变得更糟！

代码库中的更多行并不等同于更好的代码质量或生产力。有时，最复杂的编码解决方案只需要工程团队的几行编码。

关键是更聪明地工作，而不是更努力地工作。自然地，你工作得越聪明，你就会在更短的时间内完成更多的工作，这在理论上意味着你会更有效率。

错误修复

这个指标本身与衡量生产力是矛盾的。

尽管众所周知，任何软件开发人员在构建软件时都会犯错误，但无论您如何看待，通过纠正错误数量的能力来衡量他们的生产力似乎都是不对的。

同样（顺便说一句），以财务或其他方式奖励软件开发人员发现并纠正的错误数量同样不合逻辑。

完成的任务数

在软件开发领域，个人开发人员和团队通常根据在给定时间范围内完成的任务数量来衡量生产力。

听起来合乎逻辑，对吧？

从表面上看，这似乎是一个可以接受的指标。

然而，与之前的类似，它在真正揭示开发人员的生产力方面的能力很浅。

让我们来看看这两个开发人员之间的并排比较。一个人一天完成 100 项任务，而另一个人一天完成 10 项。在纸面上，人们会自动假设完成更多任务的人更有效率。

然而，问题在于上述场景没有考虑给定任务的难度级别。将完成 100 个简单任务的开发人员的生产力水平与在同一时间段内完成 10 个高度复杂任务的开发人员的生产力水平进行比较是不公平的。