logo标签列表

需要为开发人员设定目标，但目标并不起作用

evaluation
86

普遍认为，为软件开发人员设定可衡量的目标不起作用，因为过于关注目标可能导致与组织目标相反的行为（所谓的“测量功能紊乱”）。

然而，在我们公司，所有员工都需要设定目标，并受到人力资源部门的鼓励来制定明确的目标。在过去，我和我的其他一级经理（团队领导）尝试了许多方法：

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

这些都不是理想的选择。如果您曾经处于类似的情况，不得不为软件开发人员创建有意义的、可衡量的目标，尽管有证据表明它们并不有效，您最好的方法是什么？

我找到了一些相关问题，但它们并不完全涉及同样的问题：

更新（2009年11月18日）：我的问题已经获得了10个赞，而最高评分的答案只有4个赞（其中一个是我自己）。我认为这告诉我们一些事情：也许Joel和其他人是正确的，stackoverflow的集体智慧无法提出任何令人信服、可衡量的开发目标，而不会对他们工作的真正（不可衡量）价值产生负面影响。谢谢你们的尝试！

16
我更喜欢愚笨的方法论："尽你所能，做到最好。" - Robert S.
3
大量的失效链接。 - crh225
链接已失效。 - Rodrigo Leite
11个回答
21
您最有效的方法是什么？
唯一的目标：在我作为审查人员的情况下，通过代码检查/同行评审，我不会找到任何漏洞或其他批评，并要求您重新做任何事情。
备注：
- 我不是在衡量新雇用人员完成任务的能力，并且也没有鼓励他们这样做：我希望人们学会如何做好（因为如果没有做好，那么就没有完成）。 - 人们会了解我在代码审查中寻找的内容：因此这是一个学习机会和质量控制措施，而不仅仅是管理目标。 - 我的评论将分为两类：
a. 这是一个漏洞：您必须在提交之前修复它 b. 作为建议，我会这样做
- 一段时间后，我对一个人的代码的审核不再发现任何“必须修复”的问题（此时我将不需要再次审核他们的工作）。
谢谢，我喜欢这个。当我审查他们的代码时，我通常会非常关注那些不太紧急但从长远来看很重要的事情，比如变量命名和代码风格。这样的目标可能会鼓励他们更快地思考我的想法！ - Paul Stephenson
6
我也喜欢这样，但这可能会导致一种狭隘的发展模式，每个人都只是试图取悦你，可能会以损害客观最佳代码为代价。你在多年中修复了自己方法中多少缺陷？你估计还有多少需要解决？ - Ed Guiness
1
对于我来说，变量命名和代码风格属于第二类；除非风格真的很糟糕，比如多次重复使用一个变量来完成不同的任务，否则我可能会说：“你必须重新改进这个，因为它对我来说太复杂了，我无法‘通过视觉检查’确定它是否正确”。 - ChrisW
@Paul：是的。我不是经理/雇主，所以如果你正在寻找“管理目标是什么？”，如果实际经理来问我，“你觉得这个新人怎么样？”那么我会基于类别1（仅限）回答。我会将类别2保留在“家庭”内：它们是“软性”问题。 - ChrisW
代码审查对于帮助所有人达到相同的风格非常有帮助。不要忽视更加软性的问题。 - David Thornley
显示剩余5条评论
14

对于目标，我个人尝试设定两种类型：

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

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

我认为以下几点很重要：

  • 目标必须具有SMART特性
  • 目标要与业务需求相一致
  • 你要在目标中包括“日常工作”，事实上这些是最重要的目标！
  • 雇员有机会超越你设定的目标

最后，我建议不要将软件度量作为目标——它们太容易被操纵，而且可能无法给你所需的结果。我只会在想要指导某个人进入或退出特定行为时使用度量标准。

9
这一切归结于“一级管理”以及大多数管理者不了解他们的员工。与其参与实际的日常规划和开发，他们却会提出SMART等理论。如果管理者能花更多时间与实际工作人员在一起，就不需要这些理论了。
个人而言，我更喜欢在敏捷环境中工作，因为在这种情况下，开发人员的生产力和质量意识是显而易见的。真正的敏捷方法要求不仅开发人员，还包括设计师、测试人员、客户和产品经理在内的所有人都参与其中。这自然会从管理者的角度带来更好的洞察力。
1
我基本上是一个团队领导，参与实际的日常规划和开发工作。我认为每个开发人员的表现水平都是“显而易见”的，但这只是我的主观看法，并不符合目标，因此它们变得毫无意义。我宁愿我们可以完全忽略它们！ - Paul Stephenson
重点是在这里你无法获得任何科学测量，因此尝试这样做注定会失败，我认为你应该把时间花在其他地方。http://martinfowler.com/bliki/CannotMeasureProductivity.html 上有一篇相关文章。 - Martin Wickman
8

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

  • 通过证书考试
  • 研究技术X并做关于它的演讲
  • 提交的构建破坏性更改次数
  • 编写在内部知识管理上的维基文章数量

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

1
除了破坏构建之外，都是我的方法1：好的开发人员会说“我太忙于做你要我工作的关键项目，所以我没有做演示或写文章”。我不能因此惩罚他们，因此目标变得毫无意义。 - Paul Stephenson
1
同保罗所说，我对编写维基百科文章这样短暂的事情有些困扰 - 它们是否好？它们还在吗？编辑贡献怎么办？他们甚至有空闲时间做这个吗？ - annakata
8

即使开发人员没有工作，也需要为他们设定目标

如果你的开发人员没有工作，也许一些目标正是他们需要的刺激呢？;-)

3
幽默加一分: 我确实想知道这是否有歧义，但我决定只有当你故意误解时才会有歧义 :-) - Paul Stephenson
2
请注意，有人将标题更改为“即使它们（目标）不起作用”。我已经将其简化为“即使目标不起作用”。只是为了让任何被这个答案困惑的人添加评论！ - Paul Stephenson
7

"确保至少有n％的代码通过适当的单元测试进行了测试"，使用覆盖率工具来证明它，并请其他人审核测试质量。

1
定义“被测试”。如果你只是使用覆盖率工具，很容易让代码在不实际执行的情况下运行。 - Kent Boogaart
@Kent，我的意思是exercise == execute。您能详细解释一下执行和锻炼的区别吗？我很乐意更新我的建议。 - Ed Guiness
当然可以。只需编写一个单元测试来调用您的方法，但不对调用结果进行任何断言。这样，您就可以执行代码（从而获得更高的代码覆盖率），而无需实际证明它在功能上是正确的。 - Kent Boogaart
谢谢，这样的东西可能是可行的，因为单元测试将成为他们开发和维护工作的重要组成部分。然而，可能会出现人们编写没有价值的单元测试以达到目标，而本可以做更有用的工作的问题。 - Paul Stephenson
同意，可能总会有方法来操纵任何特定的测量方式，这也加强了原帖作者的观点。 - Ed Guiness
一种操纵这个度量的方法是只实现所需功能的十分之一，并进行彻底测试：“代码覆盖率”作为一项统计数据，不能衡量应该存在但不存在的代码；它也不能阻止复制和粘贴代码。 - ChrisW
4

我认为最开始制定非常具体的目标，比如SMART（也许我们实际上在同一家公司工作），在实践中似乎是一个好主意，但对于大多数团队来说并不是很实用。

问题实际上是我们的增量目标会发生变化。业务会发生变化，作为开发人员，我们需要适时、合理地做出反应。

考虑制定与您的团队或组织的目的相符合的目标。如果您的团队没有提供宏观目标服务，那么它将无法获得资金。制定整个团队都存在且与业务保持一致的集体目标。赋予人们责任并追究责任。庆祝他们的成功和失败（如果我们有时不失败，那么我们可能没有尝试过，而这正是你想要的）。希望有所帮助。

3
我们有许多指标可以作为程序员工作时收集的数据，例如：
  • 更改/添加的源代码行数
  • 在过程的各个阶段中注入的错误/漏洞数量（在同行评审期间、同行评审后、发布后）
  • 变更请求的实现/拒绝情况
  • 正式文件（软件版本说明、设计文档等）
所有这些都是有形的数据，我认为它们在向管理层和软件质量保证方面做演示时非常有用。但是我从未发现它们在实际评估人员绩效方面非常有用-这是你列出的几个链接所指出的要点。我发现Joel在这里提出的观点是正确的-指标从来没有促进良好的团队氛围。
不幸的是，我们所有人都生活在需要他人（管理层、质量保证、外部承包商等）提供指标的世界中。我发现需要一种平衡的方式-提供这些指标，同时提供无形的证据-即每个程序员所完成的不能被跟踪的任务。例如，我有一个程序员花了大量时间研究其他人不愿意涉及的旧代码。即使他在那段时间内的指标很低，但这种努力是无价的。
我发现唯一的解决方法是推动创建一个额外的无形类别，并将其与其他指标同等对待。通常，这已足以为特定程序员改变平衡。
2
作为一个部门，IT组织似乎存在的问题之一是缺乏可衡量的战略目标。如果有的话，就可以更容易地为个人设定目标。
例如，如果有一个部门倡议来减少问题工单的数量，那么你可以根据与他们负责的软件相关的工单数量来设置个人的目标。
由于软件开发主要是协作的，因此更合理的做法是在团队层面上设定目标，然后根据个人对团队的贡献进行评价。
1
只为团队设定目标是一个好习惯，而将每个问题单独钉在个人身上会让人失去动力，破坏团队精神，并且通常会给出偏颇和不准确的真实情况，特别是如果可能存在的问题单数量相当低（例如每个开发者约一个）。 - Paul Stephenson
1
我喜欢的一个目标是：
从项目客户那里获得N个关于你在项目中参与的积极评价。
这有助于获得一些书面的客户（内部或外部）积极反馈，这总是很好的。它不难获得，它是相关的，并且它是一个简单但有意义的任务清单勾选项。
如果您整年都在一个未被客户发布的单一项目上工作，却没有得到任何评论该怎么办？如果您在一个没有确定客户名单的通用网站上工作呢？ - jmucchiello
1
在这两种情况下，您仍在处理具有客户的项目，无论是内部还是外部。您正在请求对您与客户的互动进行审查，而不是对项目进行审查。 - Nat
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接