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

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

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

输入测量的问题

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

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

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

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

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

输出测量的陷阱

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

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

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

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

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

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

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

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

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

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

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

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

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

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

许多组织在没有任何坚决措施的情况下蓬勃发展。在组织中，有用的软件被公认为是目标和主要（尽管很难量化）的标准。