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

在软件行业中，定义和衡量程序员的生产率是大白鲸。这是巨大的投资价值的基础命题 的 众多 初创公司和工程经理或CTO的职位描述中最困难的部分之一。它也是所有经验水平的开发人员的焦虑之源：您如何知道自己是否做得足够（无论是全天候还是全天候）？当您所做的一切无形时，应如何衡量？可以衡量吗？在本文中，我将讨论生产力衡量的最大陷阱以及几种好的方法。

与其他领域一样，在软件开发中，许多人从投入和产出的角度来考虑生产力。在美国，专职开发人员每周工作40个小时，平均年薪为$ 107,510。工时和工资是可见的，易于量化的输入。然后，开发人员会定期产生软件功能，文档，部署和/或错误修复。这些是输出。如果开发人员像我们想象的那样简单地编写软件，那么提高他们的生产力应该和要求他们工作更多小时或付给他们更高的薪水一样简单。当然，这是一个童话。开发人员和软件都不会那样工作。

输入测量的问题

“工作时间”是用作衡量工作绩效的几种错误指标之一。我之所以首先提到它，是因为它是一个经常未经审查的默认值，是阻力最小的路径。如果一家公司不故意避免这样做，那么它迟早会恶化成一个小时的环境。在大范围流行的远程工作之外，仅数小时的环境的症状很容易识别。上班时间被认为是无法商量的，并且在办公室中出现被视为有人正在工作的证据。任何试图提早几个小时离开办公室的人都会遇到敌意（有时像有些眉毛一样柔和，有时甚至更无礼）。任何在深夜工作或在周末进来的人都被视为高绩效。不幸的是，这种“最后离开体育馆”文化的诱因是：开发人员被迫花越来越多的时间在工作上，没有其他任何方式来证明自己的价值，并被迫仅次于工作成果。随着时间的流逝，工作场所越来越成为每个人都在工作但无所事事的地方。

问题不止于此。如果我们假设所有工作都是“积极工作”，也就是说，所有工作都代表朝着目标的进展，那么我们就是错误的。在精疲力竭，分心或生病时工作的开发人员倾向于熟悉“负工作”的概念：工作做得很差，必须撤消或在以后进行补偿，从而增加而不是减少剩余的工作量。软件开发是复杂，抽象，专心的工作，因此对开发人员的心理状态敏感。也就是说，有隐藏的信息在起作用：焦虑，沮丧，倦怠，工作中的毒性，悲伤，微侵略以及其他一百多种可以在任何给定的一天降低或转化个人生产力的事物。如果公司文化要求一周又一周的长时间工作，或者甚至只有八小时的工作日，而没有灵活性或休假时间，那么开发人员将不可避免地将时间花在负面工作上：他们熬夜的工作实际上比回家时要少较早。由于疲劳，他们第二天的工作量也会减少。

另一方面，仅小时的环境并不是最坏的情况。它有一个公平的幽灵：如果两个开发人员工作相同的小时数，则它们之间存在一个明确的维度。他们似乎都没有懈怠，似乎也没有做得比他们应得的要多。如果他们的产量低于预期，那么，至少他们会投入时间。而且，“工作时间”度量标准不会像某些度量标准那样明显地激励不良代码。因此，尽管这是一个贫穷的指标，甚至工程对生产力在许多情况下，还有更糟糕的指标，我们应该讨论。

考虑一下软件开发的其他显而易见的投入：金钱。我开玩笑地向我的经理建议过一两次，生产率应该用薪水来衡量，如果薪水加倍，我将以世界一流的软件架构师的水平来编写代码。当然，您凭直觉知道这很荒谬。付钱让别人更多的钱不会马上让他们更有效率（虽然间接和有限的范围，它可能）。但是，在我看来，金钱和工时属于同一类：不仅是投入，而且是辅助性投入，只能持续提高生产率。一种是由雇主提供的，另一种是由雇员提供的，但是这种交换是附带创建有用的软件的。

长话短说，测量输入是一种不足的技术，因为软件开发不是方程式，并且组装线无法构建代码。因此，让我们谈谈输出。

输出测量的陷阱

在这里，也许是违反直觉的，我们发现了软件开发世界中许多最糟糕的指标。有些人掉入了一个陷阱，认为软件开发的工作输出是代码行或提交到版本控制中。当然，这些是过程的一部分，但它们更像是副产品，而不是结果。严格来说，没有解决问题的代码行总比没有代码差。因此，通过开发人员贡献多少代码来衡量开发人员的生产力，就像通过他们产生多少废物来衡量发电厂，或者通过他们通过多少法案来衡量国会一样；它与实际值相切。

更糟糕的是，玩这些测量非常容易。按代码行付费的开发人员可以轻松地在一天之内赚取全年的薪水，而不会产生任何业务价值。大多数开发人员都会采用更巧妙的方法，但是同样，您应该小心自己的期望。

当一项措施成为目标时，它就不再是一项好的措施。

开发人员大体上都了解这一点，但是令人尴尬的是，我们仍然倾向于使用提交和代码行作为众所周知的孔雀羽毛。当我们看到Google（代表2015年所有Google品牌产品）跨越20亿行代码，或者Windows团队每天执行超过8400次代码推送时，即使我们都不知道这两个代码都可以是什么使Google或Windows有用。

无论如何，我们都可以将这些措施添加到无效代理列表中。如果要解决的问题稍微多一点，则根据已修复的错误，已完成的任务或所提供的功能来衡量生产率同样是徒劳的。如果目标是修复更多的错误，则开发人员可以故意编写有错误的软件，然后编写大量的修复程序；例如，或者，为了实现相反的目标，他们可以通过尽可能慢地编写功能来减少错误计数。如果目标是发布功能，则他们可以快速而幼稚地编写它们，从而导致软件运行缓慢且几乎无法运行。如果目标是完成任务，那么整个团队都可以融入政治，因为每个开发人员都在争夺最简单（或最被高估）的人。一个好的团队可能会忽略您的措施而只是工作，

一些组织表现出深刻的妄想症，将间谍软件安装在员工的计算机上，以跟踪诸如鼠标移动，按键和屏幕截图之类的瞬间工作的细节。对我而言，目前尚不清楚在这种审查下，任何员工如何开展创意工作。我希望大多数开发人员都会立即退出。但是，与上面讨论的方法一样，这是最明显的失败，即它没有捕获到对企业或其客户真正有意义的任何东西。您会因为他们在Reddit上花费大量时间或没有足够移动鼠标而对高效率的开发人员进行培训吗？您会因为他们花很多时间在Visual Studio中进行打字而提拔他们，即使他们很难与他们合作吗？一些经理显然这样做了，但是希望我们大多数人都比这更聪明。

在正确的水平上衡量生产力

现在，您已经被警告不要尝试使用最糟糕的措施，让我们来谈谈一些好的措施。不幸的是，个人绩效几乎无法通过“该团队成员贡献”或“该团队成员不贡献”的二元状态来衡量。而且它不能远距离测量。 

软件开发团队不是一群孤立地工作的人；每个团队成员的工作成果都是其所有队友的工作成果的函数，更不用说一天中一些有意义的，不可衡量的互动。单个工作的相互依赖性和细微差别太复杂，无法衡量由外部观察者。例如，某些团队成员是团队其余成员的力量乘数-他们可能无法独自完成很多工作，但如果没有他们的帮助和影响，他们的队友的生产力就会大大降低。像这样的人是有效的工程组织的秘密武器，但是他们的生产力无法以个人规模来衡量。其他团队成员可能不会产生很多功能，而是充当“代码管理员”，无论他们身在何处，都应进行仔细的测试，清理和重构代码，以便其团队成员可以更快，更轻松地开发功能。他们作为个人的生产力也是无法衡量的，但是它们对团队生产力的影响却是指数级的。即使对于定期发布新功能的程序员，也可以提高工作效率在短期内往往会有很大的变化，扼杀了对其进行任何特异性跟踪的努力。出于这样的原因，个人绩效最好留给个人贡献者自己和彼此衡量。

另一方面，团队绩效更明显。追踪问题的最佳方法也许就是问，这个团队是否在数周至数月的时间范围内持续生产有用的软件？这呼应了敏捷的第三项原则：“频繁交付工作软件，从几周到几个月不等，而更倾向于缩短时间。” 定期生产有用的软件的团队富有成效。一个没有的团队应该被问到为什么不这样做。通常有缺乏生产力的正当理由；大多数非生产性团队希望提高生产效率，而大多数生产性团队希望提高生产率。

可以通过简单，整体的观察在组织规模上衡量团队的生产力。而且由于队友往往很了解彼此的贡献（无论是否可衡量），因此可以通过良好的组织习惯来发现个人生产力方面的任何严重缺陷，例如，经理与直属人员之间经常进行一对一的访谈报告；定期收集诚实，匿名的反馈；并鼓励每个团队成员通过报告自己的成就并对失败承担责任来行使个人责任感。

这里有很多取决于人，而不是趋势图和原始数据。这是软件不可回避的事实：与人类有关的远不止于零和一，而且一直如此。生产力跟踪工具和激励计划永远不会像工作场所中的积极文化那样产生巨大的影响。当问责制和健康的沟通融入这种文化中时，最有能力解决这些问题的人们将很快意识到生产力的关键时刻。

许多组织将速度作为衡量团队生产力的首选指标，如果做得对，这可能是了解软件开发过程的有用工具。速度是团队随时间推移完成的任务的总体度量，通常考虑开发人员自己对每个任务的相对复杂性的估计。它回答诸如“该团队在接下来的两周中可以做多少工作？”之类的问题。基准答案是“大约与过去两周一样”，而速度是该陈述的背景。这是一项计划性措施，而不是追溯性措施，任何尝试对其施加激励的人都将发现其准确性在压力下蒸发（有关此问题的更多信息，请参阅软件开发的本质）。 （罗恩·杰弗里斯）。在确定功能开发的优先级，与客户设定期望并计划产品的未来时，了解团队，部门或公司的速度可能是基础。

没有比“任务乘以复杂性”更有效的措施了。像某些工具一样，衡量提交，代码行或编码所花费的时间，在团队规模上比在个人规模上更有用。团队产生的代码工件的数量，他们花在代码工件上的时间与贡献的价值之间根本就没有关系。

许多组织在没有任何坚决措施的情况下蓬勃发展。在组织中，有用的软件既是开发工作的目标又是主要的（尽管难以量化）测量结果，并且相应地降低了输入的优先级，这具有深远而深远的影响。无论何时何地，开发人员都可以放手去做最好的工作。这看起来可能是9：5。有些人会根据喜好或必要，在清晨和深夜进行大部分工作。其他人则以零散的方式工作：这里一个小时，那里几个小时。有些会在家中工作，有些会在办公室工作，有些会在旅途中工作。这是一个功能，而不是错误。它强调的是真正的生产力，而不是试图将其折磨成可观察的启发式方法，残疾人。关于“只有结果的工作环境”（ROWE），远程工作，减少在会议上花费的时间和灵活的时间所带来的好处，已经有很多论述，并发表了很多看法。所有这些都只是精明的生产率指标的体现。

有人说，您得到了您所要衡量的。因此，您仅应衡量自己真正想要的内容，无论它是否可以绘制为折线图。对于某些人来说，做或管理无法减少的工作可能会令人沮丧。但是随着软件开发工作的细致和抽象，我们越深入细节，就越无法实现自己的目标。有用的软件是我们的目标，我们不应满足（或衡量）任何其他要求。