即使目标行不通，也必须为开发人员设定目标[关闭]

人们普遍认为，为软件开发人员设置可衡量的目标是行不通的，因为对目标的过多关注会导致行为违背组织目标（所谓的“测量功能障碍”）。

但是，在我公司，我们必须为所有员工设定目标，并受到人力资源部门的鼓励，使他们成为SMART。过去，我的第一级管理人员（团队负责人）和我尝试了多种方法：

1. 设置除正常工作之外的可衡量目标，例如“对技术X进行培训”，“为没人能理解的代码段Y创建文档”等。在进行年度绩效评估时，不对开发人员的书面目标进行评分，而是根据我对他们正常工作的不可估量价值的评价，因为这实际上是公司所关心的。
2. 设定非常具体的目标，例如“任务管理系统记录的工作日数”，“引入的错误数”，“引起的生产数”。这导致虚高的估算值和错误的错误分类，从而获得更好的“分数”。有趣的是，即使那些在该系统上得分很高的开发人员也不喜欢它，因为团队内在的信任受到了损害，他们并不总是觉得自己应得的地位。
3. 在“做好您的正常工作”上设置模糊的目标。在进行年度评估时，它们的评级确实反映了相对于目标的绩效，但是目标本身是不可衡量的或不可实现的，因此对此表示怀疑。

这些都不是理想的。如果您面临类似的情况，尽管有证据表明它们的有效性，也必须为软件开发人员创建有意义的，可衡量的目标，那么哪种方法最适合您？

我发现相关问题并不能完全解决同一问题：

• 软件工程师有哪些好的性能目标？
• 为开发人员设定绩效目标
• 什么是适合程序员的性能指标？
• 对于程序员来说，什么是公平的生产率衡量技术？
• 我明年需要一些职业“目标”

更新（2009年11月18日）：我的问题有10个投票，而评分最高的答案只有4个投票（包括我每个人的投票）。我认为这告诉了我们一些事情：也许乔尔和其他人是对的，并且对于那些无法在不负面影响其真实（不可衡量的）价值的情况下进行开发的开发商来说，stackoverflow的综合智慧无法提出任何令人信服的，可衡量的目标。工作。感谢您的尝试！

哪种方法最适合您？

只有一个目标：以代码审查/同行审查的身份，以我为审查者，而没有发现任何错误或任何其他批评，这要求我重做一些事情。

笔记：

• 我没有衡量新员工的快速完成能力，也不鼓励他们：我希望人们学习如何良好地完成工作（因为如果做得不好，那么就没有完成）
• 人们了解了我在代码审查中寻找的内容：因此，这是一个学习机会和质量控制措施，而不仅仅是管理目标
• 我的评论将分为两类：
  1. 这是一个错误：签入之前必须解决此问题
  2. 作为建议，我会做某某某事
• 一段时间后，我对一个人的代码的评论将停止找到任何“必须修正”的项目（此时，我将不再需要审查他们的工作）。

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

• 以业务为中心的目标（这就是为什么我们获得报酬的原因）。例如，“在2009年6月1日之前完成X项目”）。这些目标通常在团队的几个成员之间共享（他们知道这一点）。通过尽早进行项目或超出所需的功能，团队可以超越目标。个人可以通过产生更多的功能，减少针对他们的错误或指导和支持团队的其他成员来超越目标。

• 个人成长目标，例如完成一个涉及开发人员想要添加到他们的技能中的技术的项目，更好地了解用户的领域，获得领导经验等。

我认为重要的是：

• 目标是聪明的
• 目标与业务需求保持一致
• 您的目标中确实包含“正常工作”，实际上，这是最重要的目标！
• 员工有机会超越您设定的目标

最后，我会远离软件指标作为目标-它们太容易玩了，可能无法满足您的需求。我只会在要指导某人从事某种特定行为的情况下使用指标。

这一切都归结为“第一层管理”这一事实，并且大多数管理人员都不认识他们的员工。弹出的不是SMART之类的东西，而是实际的日常计划和开发的一部分。如果管理人员要花更多的时间与实际工作的人在一起，则不需要这些。

就个人而言，我更喜欢在敏捷的环境中工作，在生产力和质量意识方面，显然谁是开发商。真正的敏捷方法不仅需要开发人员，而且还需要设计人员，测试人员，客户和产品经理。从经理的角度来看，这自然会带来更好的见解。

到目前为止，我已经看到了可衡量的目标：

• 通过证书考试
• 研究技术X并就此进行演示
• 已提交的构建突破性更改的数量
• 有关内部知识管理的Wiki文章数量

直接问您的开发人员是否对个人发展有一些想法可以用于目标？

即使开发人员无法使用，也必须为其设定目标

如果您的开发人员不工作，那么也许只是一些目标才是他们激发他们动力所需要的？;-)

“确保至少有n％的代码已通过适当的单元测试进行了测试”使用覆盖率工具进行证明，并请其他人检查其测试质量。

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

问题确实是我们的增量目标发生了变化。业务不断变化，作为开发人员，我们需要在合理的时间范围内做出适当的反应。

考虑设置与您的团队或团队在组织中的目的相关的目标。如果您的团队没有达到目的-宏目的，就不会得到资助。拥有整个团队中存在并与业务保持一致的集体目标。赋予人们责任并追究人们的责任。庆祝他们的成功和失败（如果我们有时不失败，我们可能就不会尝试，而这正是您希望人们获得的）。高温超导

随着程序员的工作，我们收集了许多指标，例如：

• 更改/添加的SLOC数量
• 在流程的各个阶段（同行评审，同行评审后，发布后）注入的错误/错误数
• 变更请求已实现/被拒绝
• 正式文档（软件版本说明，设计文档等）

所有这些都是有形的，在管理和软件质量保证的演示中我发现它们很有用。但是，我从未发现它们在实际评估人们的绩效方面具有非常有用的作用-这是您列出的几个链接所提出的观点。我发现乔尔的观点在这里是有效的-指标从未促进良好的团队氛围。

不幸的是，我们都生活在一个其他人需要度量（管理，质量保证，外部承包商等）的世界中。我发现需要采取一种平衡的行为-提供这些指标，还提供无形的证据-无形是每个程序员所完成的事情，不一定要跟踪。例如，我有一个程序员，他花了大量时间研究其他人都不想接触的遗留代码。即使在这段时间内他的指标很低，这种努力也是无价的。

我发现包含此类内容的唯一方法是推动创建其他无形类别，并赋予其与其他指标同等的权重。通常，这足以平衡特定程序员的平衡。

问题之一似乎是作为部门的IT组织没有可衡量的战略目标。如果他们做到了，则为个人设定目标会更容易。

例如，如果部门采取了减少提出问题单的数量的举措，那么您可以根据与他们所管理的软件相关的票据的数量来设置个人目标。

由于软件开发在很大程度上是一种协作，因此在团队级别设定目标，然后根据他们对团队的贡献来对个人进行评分会更有意义。

我喜欢的目标是：

向项目客户征询您对项目参与的正面评价。

这很有帮助，因为总是有一些来自客户（内部或外部）的书面积极反馈总是很好的。它并不难获得，具有相关性，并且是清单上的简单但并非毫无意义的勾号。

我认为，确定如何使个人发展与正在完成的项目保持一致是关键。让开发人员进行自我分析以发现弱点，并提供有关其他方面的反馈，这可能是一种发现可以改进的地方，然后找到一种衡量它的方式。例如，我可能发现我很少记录完成的项目，因此我可以说我要改进这一年的目标，并且我产生的文件数量可以用来衡量。根据我的实际情况，它可能起作用或适得其反。一方面，我可能会对此存在真正的担忧，那就是我如何改善自己的工作并做一些被视为正确的方法，而被动的，激进的或幼稚的观点将是产生大量的文档，如果不是的话。

定义有效的开发人员是这的另一个要素。是最能解决错误的人吗？新工作最快吗？即使没有快速完成，新工作是否也包含测试和文档？您所说的有效是什么， 因为此处应阐明“取决于”标准响应。