ACM通信
如何正确地衡量你的程序员
衡量还是不衡量，这是个问题。请原谅我诗意地说了这么多，但是度量是程序员和管理人员最敏感的话题之一。程序员应该被衡量吗?或者这样做是侵入性的和无效的?通常，答案取决于你的职位和你名片上的职位。
问程序员，许多人会告诉你测量是愚蠢的愚蠢之举。度量破坏了团队精神，或者它将动态解决方案简化为永远不能反映项目真正复杂性的数字。度量甚至可以在最有野心的程序员中引发英雄情结，使他们在减少协作的同时陷入失败。
这不是我的原话，但如果你经常和程序员打交道，你可能会听到类似的批评。你知道吗?这种说法有一定道理。然而，我认为也有很多误解。错误的度量和设计糟糕的绩效评估确实会破坏团队，从长远来看，也会破坏生产力。
然而，与此同时，如果没有度量，管理人员必须将项目的大部分(如果不是全部的话)控制权让给他们的程序员。在一种极端的情况下，经理们只需要相信程序员的话，即项目正在成功地推进，资源正在有效地投入工作。
在更糟糕的情况下，项目可能会陷入无政府状态。管理人员实际上沦落为行政助理，程序员在几乎没有监督的情况下操办一切。令人惊讶的是，项目开始偏离轨道，开发速度变慢，bug在代码中激增，就像许多蝗虫一样。
然而，我们应该根据最坏的情况来衡量测量结果吗?在我看来，绝对不是。在不称职的人手中，设计糟糕的度量可能会摧毁项目，分裂团队，并最终压倒公司。然而，正确的度量和审查过程可以使混乱变得有序，简化工作并产生优秀的结果。
好的，好的测量应该是什么样的呢?让我们来看看一些有前景的指标。
学员的结果:有些人认为度量可以分裂团队。新团队成员，包括徒弟，可能是风险最大的，在早期产生可衡量的糟糕结果。为什么不改写剧本呢?用合理的标准来衡量学员，并对那些帮助他们的导师给予肯定。现在，高级团队成员对新人才的成功有着既得利益。
功能实现:是的，衡量软件和编程性能是很棘手的。一个合理的方法是衡量交付或实现的特性。尽管如此，每当GitHub或内部售票系统上的程序员完成一个售票并添加一个功能时，你可以勾选并给他们积分。只要确保关闭票据的是产品经理，而不是程序员。
正常运行时间:正常运行时间是一种很好的、高级的衡量成功的方法。较高的正常运行时间表明该软件编程良好，没有出现严重的bug或其他问题。考虑各种度量，包括平均故障间隔时间(MTBF)、平均故障间隔时间(MTTF)、故障率和其他相关DevOps度量。
测量和修复的bug:测量已修复的bug是改进软件的好方法。有些公司会在程序员出现bug时惩罚他们。你猜怎么着?许多程序员只是试图隐藏或掩盖漏洞，导致软件即使在启动后也是不可靠的。
解决方案很简单:对发现bug和修复bug的程序员给予奖励。一旦你这样做了，你的程序员就不会让错误溜走，并且会有适当的动机去修复它们。只要确保产品经理或另一个程序员检查已经发现和修复的错误就可以了。
拉请求的成本:优秀的程序员会快速合并提交的pull request (PRs)。越快的拉请求被同行评审并发送到质量控制部门，效果越好。每走一步都要奖励你的团队成员，包括参与同行评审拉请求。
不可否认的是，初级程序员可能会提交大量或复杂的pr，这可能会在同行评审中造成严重破坏。但是让初级程序员跟上拉请求的速度是奖励导师的一件很好的事情。
版本发布:理想情况下，项目的新版本每天都发布。在混乱?新版本可能几周后才会出现。释放压力。然而，通过奖励定期、及时更新的程序员，就鼓励了频繁发布。
发布的文档:有些程序员不想为文档费心;毕竟，他们已经知道代码了。但是，适当和广泛的文档可以确保现在和将来的稳定性。根据程序员制作的文档数量奖励他们;只是要确保在发布之前进行了验证。
开始测量以上这些，你就有了一个良好的开始。然而，我需要强调的是:同行评审和质量控制是必不可少的。如果没有它，程序员将提交大量糟糕的文档，或者报告不存在的bug。每件事都必须再三检查。
此外，不要让你的团队受制于参数。最终，参数不应该是目的本身;目标是保持团队和项目正常运行。这需要一定的灵活性。以虫子为例;有些问题很小，不是特别紧急，而有些问题很复杂，解决它们至关重要。没有两个错误是相同的，因此要注意其紧迫性和严重性。您应该调整您的指标以考虑到这一点。
理想情况下，程序员将根据度量标准的表现获得奖励。在理想的情况下，我们应该放弃工资，而是根据新增的功能、推出的新版本、发布的文档页面以及其他内容向员工支付工资。这种方式的奖励与贡献是相称的。
就目前而言，工资可能会维持下去。最终，糟糕的管理者不会为衡量和工资膨胀而烦恼，因为他们试图让每个人都满意。另一方面，伟大的管理者会实施健全的衡量体系，并奖励那些付出努力的人。
叶戈尔·Bugayenko他是软件工程和管理平台Zerocracy的创始人和首席执行官。
没有发现记录