不得不为开发者设定目标，尽pipe目标不起作用

人们普遍认为，为软件开发人员设定可衡量的目标是行不通的，因为过分关注目标会导致与组织目标（所谓的“ 测量function障碍 ”）相对立的行为。

但是，在我们公司，我们需要为所有员工设定目标，并受到人力资源部门的鼓励，使他们变得聪明。过去，我的一线经理（团队负责人）和我尝试了很多方法：

设定额外的正常工作的可衡量的目标，如“对X技术进行培训”，“为没有人理解的代码片段Y创build文档”等等。谈到年度绩效评估，评估开发商不是以书面目标为依据，而是以我对正常工作不可估量价值的看法，因为这实际上是公司关心的。
设定“任务pipe理系统logging的工作日”，“引入错误数”，“发生的生产数”等非常具体的目标。这导致了错误的估计和不正确的分类，以达到更好的“分数”。有趣的是，即使那些在这个系统上得分高的开发者也不喜欢它，因为团队内部的信任被破坏了，他们并不总是觉得自己应得的高位。
设定模糊的目标，是“做你的正常工作”的变体。在年度评估中，评级确实反映了绩效与目标的相关程度，但目标本身是不可衡量的，也是不可实现的。

这些都不是理想的。如果您遇到类似的情况，不得不为软件开发人员创build有意义的，可度量的目标，尽pipe有证据表明他们的有效性， 那么最适合您的方法是什么？

相关问题我发现不太相同的观点：

软件工程师有什么好的性能目标？
为开发人员设置性能目标
程序员有什么合适的性能指标？
什么是程序员公平的生产力测量技术？
明年我需要一些职业“目标”

更新（2009年11月18日）：对于我的问题，有10个赞成票，最高评分的答案只有4个赞成票（包括我的每个人）。我想这告诉了我们一些事情：也许Joel和其他人是对的，并且stackoverflow的联合智慧无法为开发人员提供任何令人信服的，可测量的目标，而这些目标如果不影响其真实（不可估量的）价值工作。感谢您尝试，但！

哪种方法最适合你？

只有一个目的： 通过一个代码检查/同行评审，作为审稿人，没有我发现任何错误或有任何其他批评，我要求你重做一些东西。

笔记：

我并没有衡量新员工快速完成的能力，也没有鼓励他们：我想要人们学习如何完成（因为如果没有完成，那么它没有完成）
人们在代码审查中学到了我所追求的东西：所以这是一个学习机会和质量控制措施，而不仅仅是一个pipe理目标
我的意见将有两个类别：
1. 这是一个错误：您必须在登记之前解决此问题
2. 作为一个build议，我会做这样的事情
过了一段时间，我对一个人的代码的评论将停止find任何“必须修复”的项目（在这一点上，我不需要再检查他们的工作）。

我个人试图设定两种目标：

以业务为中心的目标（这就是为什么我们得到报酬）。例如，“在2009年6月1日前完成项目X”）。这些目标经常在团队的几个成员之间共享（他们知道这一点）。通过提前实施项目或超越所需的function，团队可以超越目标。个人可以通过产生更多的function，减less对他们的错误，或者指导和支持团队的其他成员来超越目标。
个人成长目标，例如完成一个涉及开发者想要增加技能的技术的项目，更好地理解用户的领域，获得领导经验等。

我觉得重要的是：

目标是SMART
目标与业务需求保持一致
你的目标中包括“正常工作”，其实这些是最重要的目标！
员工有机会超过您设定的目标

最后，我将远离软件度量作为目标 – 它们太容易游戏，可能不会给你所需要的东西。我只会使用一个指标来指导某人进出特定行为。

这一切都归结为“一级pipe理”和大多数pipe理层不了解员工的事实。而不是实际的日常计划和发展的一部分，像SMART的东西popup。如果pipe理者们花更多的时间和那些做实际工作的人在一起，那么这些都不是必需的。

就个人而言，我更喜欢在敏捷的环境中工作，在这种环境下，开发人员在生产力和质量意识方面performance出色。一个真正的敏捷方法要求不仅包括开发人员，devise人员，testing人员，客户和产品经理。这自然会从pipe理者的angular度得到更好的见解。

我目前看到的可衡量的目标是：

通过证书考试
研究X技术并进行介绍
构build中断更改的数量
在内部知识pipe理上撰写的wiki文章的数量

如果直接询问你的开发人员是否对个人发展有一些想法，然后才能用于目标呢？

“确保至less有n％的代码是通过适当的unit testing进行testing的”使用覆盖工具来certificate它，并让其他人检查testing质量。

必须为开发人员设定目标，即使这些目标不起作用

如果你的开发者不工作，或许有些目标正是他们需要给他们一些激励的东西。 😉

我认为，事先具有非常具体的目标，即SMART（也许我们实际上在同一个地方工作），在实践中似乎是一个好主意，但对大多数团队来说这不是很实际。

问题的确是我们的增量目标的变化。业务发生变化，作为开发者，我们需要在合理的时间范围内做出正确的反应和反应。

考虑设定与你的团队或组织在组织中的目标相一致的目标。如果没有达到目的，你的团队将不会获得资助 – 这是一个macros观目标。在整个团队中存在集体目标，并与业务保持一致。给予责任，追究责任。庆祝他们的成功和失败（如果我们不失败，有时我们可能不会尝试，这是你想要的人）。 HTH

我们有很多在程序员工作时收集的指标，比如：

SLOC数量已更改/添加
stream程不同阶段注入的错误/错误数量（在同行评审期间，同行评审后，发布后）
更改请求已完成/拒绝
正式文件（软件版本说明，devise文件等）

所有这些都是我在pipe理和软件质量保证演示中发现的有形的东西。但我从来没有发现它们在实际评估人们的performance方面非常有用 – 这是您列出的几个链接所提出的观点。我发现乔尔的观点是有效的 – 度量从来不会促进良好的团队氛围。

不幸的是，我们都生活在一个需要其他人（pipe理，质量保证，外部承包商等）要求的世界里。我发现需要一个平衡的行为 – 提供这些指标，但也提供无形的证据 – 无形的，每个程序员已经完成的事情，不一定跟踪。例如，我有一个程序员花了大量的时间去调查没有人想要的遗留代码。尽pipe这段时间他的指标很低，但是这个努力是无价的。

我发现包括这样的东西的唯一方法是推动创build一个额外的无形类别，并与其他指标给予同等重视。通常这足以摆动特定程序员的天平。

其中一个问题似乎是，作为一个部门/部门，IT部门没有可衡量的战略目标。如果他们这样做了，那么为个人设定目标会更容易一些。

例如，如果部门主动减less问题门票的数量，那么您可以根据与他们所关心的软件相关的门票数量来设定个人目标。

由于软件开发是一个相当庞大的工作，因此在团队层面设定目标会更有意义，然后根据他们对团队的贡献对个人进行评分。

确定如何使个人发展与正在进行的项目相一致是我认为的一个关键点。让开发人员分析自己，发现缺点并给予他人反馈，可能是find可以改进的方法，然后find一种方法来衡量它。例如，我可能会发现，我很lesslogging完成的项目等等，我可以说我想改进这一点，而我所生成的文档数量可以作为衡量这一点的一个指标。它可能工作，也可能适得其反，这取决于我如何真正遵循它。一方面可能会有这样一个有效的担忧，那就是我如何改进我的工作，做什么可以被看作是正确的方式，而被动的侵略性或幼稚的观点如果不是那么好，因为这可以在明年得到改善，因为这可以是另一个考虑的问题：与隔离事件相比，什么是一年中尽可能改进的动机？

定义一个有效的开发人员是另一个要素。是最好修复错误的人吗？新工作最快吗？新工作是否完成了testing和文档，尽pipe没有很快完成。你认为什么是有效的，因为“取决于”的标准答案应该在这里澄清。

我喜欢的目标是：

征求您对项目客户参与项目的积极评价。

这有助于获得来自客户（内部或外部）的书面正面反馈总是好的。它不难得到，它的相关性，这是一个容易，但不是没有意义的清单上的勾号。