衡量开发人员的生产力

Warning: Can only detect less than 5000 characters

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

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

当一项措施成为目标时，它就不再是一项好的措施。 〜古德哈特定律

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

（顺便说一句，我祝贺这个人的贡献图，这是为了养成每天的编码习惯，也是不时休假的时间。就我而言，这都是积极的信号，尽管我不会这样做。更不用说更深入地了解他们的贡献历史了。

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

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

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

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

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

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

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

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

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

许多组织蓬勃发展，根本没有采取任何坚决措施。在组织中，有用的软件既是开发工作的目标又是主要的（尽管难以量化）测量结果，并且相应地降低了输入的优先级，这具有深远而深远的影响。开发人员可以解放自己，随时随地尽自己的最大努力。这看起来可能是9：5。有些人会根据喜好或必要，在清晨和深夜进行大部分工作。其他人则以零散的方式工作：这里一个小时，那里几个小时。有些会在家中工作，有些会在办公室工作，有些会在旅途中工作。这是一个功能，而不是错误。它强调真正的生产力，而不是试图将其折磨成一种可观察的启发式方法，并且它使工作场所能够为更深层次的人才库提供支持，其中包括例如在职父母和残疾人。关于“只有结果的工作环境”（ROWE），远程工作，减少在会议上花费的时间和灵活的时间的好处的文章很多，并有很多发言。所有这些都只是精明的生产率指标的体现。

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

标签：管理，测量，生产力