85

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

但是，在我的公司，我们需要为所有员工设定目标，并受到人力资源部的鼓励，使他们变得SMART。过去，我和我的一级经理（团队领导）同事尝试了多种方法：

  1. 设定正常工作之外的可衡量目标，例如“对技术 X 进行培训”、“为无人理解的代码 Y 创建文档”等等。当谈到年度绩效评估时，不是根据书面目标来评价开发人员，而是根据我对他们正常工作的不可估量价值的看法，因为这实际上是公司关心的。
  2. 设定非常具体的目标，例如“任务管理系统记录的工作天数”、“引入的错误数量”、“导致的生产发布数量”。这导致了夸大的估计和错误的错误分类，以便获得更好的“分数”。有趣的是，即使是那些在这个系统上得分很高的开发人员也不喜欢它，因为团队内部的内在信任被破坏了，他们并不总是觉得自己配得上这个高职位。
  3. 设定模糊的目标，这些目标是“做好你的正常工作”的变体。当谈到年度评估时，他们的评级确实反映了目标的绩效，但目标本身是不可衡量或可实现的，这是不受欢迎的。

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

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

更新（2009 年 11 月 18 日）：我的问题有 10 个赞成票，而评分最高的答案只有 4 个赞成票（包括我每个人的赞成票）。我认为这告诉我们一些事情：也许 Joel 和其他人是对的，stackoverflow 的综合智慧无法为开发人员提供任何令人信服的、可衡量的目标，而这些目标无法在不影响他们真正（不可衡量的）价值的情况下被玩弄。工作。不过感谢您的尝试！

4

11 回答 11

21

哪种方法最适合您？

只有一个目标：通过代码检查/同行评审，我作为审阅者，没有我发现任何错误或有任何其他批评，这让我要求你重做一些事情。

笔记：

  • 我没有衡量新员工快速完成工作的能力，也没有鼓励他们：我希望人们学习如何完成工作（因为如果做得不好，那就没有完成）
  • 人们学到了我在代码审查中寻找的东西：所以这是一个学习机会和质量控制措施，而不仅仅是一个管理目标
  • 我的评论将分为两类：
    1. 这是一个错误：您必须在签入前修复此问题
    2. 作为一个建议，我会做某事
  • 过了一段时间，我对一个人的代码的审查将停止发现任何“必须修复”的项目（此时我不再需要审查他们的工作）。
于 2009-01-15T14:07:09.547 回答
14

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

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

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

我觉得重要的是：

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

最后，我会远离作为目标的软件指标——它们太容易玩弄，可能不会给你你需要的东西。我只会使用我想指导某人进入或退出特定行为的指标。

于 2009-01-29T21:51:37.783 回答
9

这一切都归结为“一级管理”这一事实，大多数管理人员都不了解他们的员工。SMART 之类的东西并没有成为实际日常规划和开发的一部分。如果经理们要花更多的时间与实际工作的人在一起，那么这些都不需要。

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

于 2009-01-15T13:41:48.833 回答
8

到目前为止我看到的可衡量的目标：

  • 通过证书考试
  • 研究技术 X 并举行关于它的演讲
  • 提交的构建重大更改数
  • 关于内部知识管理的 wiki 文章数量

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

于 2009-01-15T13:43:09.097 回答
8

必须为开发人员设定目标，即使他们不工作

如果您的开发人员不工作，也许某些目标正是他们需要激励的？;-)

于 2009-01-15T14:26:35.530 回答
7

“确保至少 n% 的代码通过合适的单元测试进行测试” 使用覆盖率工具来证明这一点，并让其他人检查测试质量。

于 2009-01-15T13:35:59.313 回答
4

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

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

考虑设定与您的团队或小组在组织中的目的相关的目标。如果你的团队没有达到一个目的——一个宏观目的，你的团队就不会得到资助。拥有贯穿整个团队并与业务保持一致的集体目标。赋予人们责任，让人们承担责任。庆祝他们的成功和失败（如果我们有时不失败，我们可能不会尝试，这就是您希望人们提供的）。高温高压

于 2009-01-15T13:50:15.633 回答
3

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

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

所有这些都是有形的，我发现它们在管理和软件质量保证的演示中很有用。但我从来没有发现它们在实际评估人们的表现时非常有用——这就是你列出的几个链接的意义所在。我发现 Joel 的观点是有道理的——指标永远不会促进良好的团队氛围。

不幸的是，我们都生活在一个其他人（管理、质量保证、外部承包商等）需要指标的世界中。我发现需要一种平衡行为——提供这些指标，但也提供无形资产的证据——无形资产是每个程序员已经完成的，不一定要跟踪。例如，我有一位程序员花费大量时间研究其他人不想接触的遗留代码。尽管那段时间他的指标很低，但这种努力是无价的。

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

于 2009-01-15T15:28:55.297 回答
2

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

例如，如果有一个部门主动减少提出的问题工单的数量，那么您可以根据与他们所关注的软件相关的工单数量来设定个人目标。

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

于 2009-01-15T14:01:17.187 回答
1

确定如何使个人发展与正在完成的项目保持一致是我认为的一个关键点。让开发人员分析自己以发现弱点，同时对他人提供反馈，这可能是一种找到可以改进的地方，然后找到衡量它的方法。例如，我可能会发现我很少记录已完成的项目等我的年度目标，我可以声明我想要改进这一点，并且我制作的文档数量可以衡量这一点。它可能会起作用，也可能适得其反，这取决于我如何真正遵循它。一方面，我可能会担心我如何改进我的工作并做可能被视为正确的事情，而消极的攻击性或幼稚的观点会产生大量的文档，如果不是的话。

定义一个有效的开发人员是另一个要素。是最好的修复错误的人吗？新工作最快吗？新工作是否完成了测试和文档，即使它没有快速完成？你说什么是有效 的，因为这里应该澄清“它取决于”标准响应。

于 2009-01-23T16:56:39.190 回答
1

我喜欢的一个目标是：

征求项目客户对您参与项目的 N 项正面评价。

这很有帮助，因为从客户（内部或外部）那里获得一些书面的正面反馈总是好的。它不难获得，它是相关的，它是一个简单但并非毫无意义的勾选。

于 2009-01-15T21:47:22.363 回答