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

Posted 2023-05-08

【中文标题】即使目标不起作用，也必须为开发人员设定目标[关闭]

【英文标题】：Having to set objectives for developers, even though objectives don't work [closed]

【发布时间】：2010-10-01 14:18:00

【问题描述】：

对于软件开发人员 doesn't work 来说，setting measurable objectives 是 generally accepted，因为过分关注目标会导致行为与组织目标背道而驰（所谓的“measurement dysfunction”）。

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

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

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

---

我发现并没有完全解决同一问题的相关问题：

What are some good performance goals for a software engineer? Setting Performance goals for Developers What are suitable performance indicators for programmers? What is a fair productivity measurement technique for programmers? I need some career “Goals” for the next year

---

更新（2009 年 11 月 18 日）：我的问题有 10 人点赞，而评分最高的答案只有 4 人点赞（包括我自己的点赞）。我认为这告诉了我们一些事情：也许 Joel 和其他人是对的，*** 的综合智慧无法为开发人员提出任何令人信服的、可衡量的目标，而这些目标无法在不对开发者产生不利影响的情况下进行游戏。他们工作的真实（不可衡量的）价值。感谢您的尝试！

【问题讨论】：

我更喜欢 DUMB 方法：“尽最大努力。”

很多断开的链接。

链接已损坏

【参考方案1】：

哪种方法最适合您？

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

注意事项：

我没有衡量新员工快速完成任务的能力，也没有鼓励他们：我希望人们学习如何完成任务（因为如果完成得不好，那就没有完成） 人们在代码审查中学到了我所寻找的东西：所以这是一个学习机会

和

质量控制措施，而不仅仅是一个管理目标 我的 cmets 有两个类别：

这是一个错误：您必须在签入前修复此问题 作为建议，我会做某事

一段时间后，我对某人代码的审查将不再发现任何“必须修复”的项目（此时我不再需要审查他们的工作）。

【讨论】：

谢谢，我喜欢这个。当我确实查看他们的代码时，我通常对变量命名和代码样式等不那么紧急但长期重要的事情感到非常不满。像这样的目标可能会鼓励他们更快地按照我的思路思考！

我也喜欢这种方式，但它可能会导致一种狭隘的开发模式，每个人都只是试图取悦你，而可能牺牲客观上最好的代码。这些年来，您在自己的方法中修复了多少错误，您估计还有多少需要解决？

对我来说，变量命名和代码风格属于第二类；除非样式真的不好，例如为太多不同的目的重用一个变量，我可能会说“你必须重做这个，因为它对我来说太复杂了，我无法通过检查来判断它是否正确”。

嘿，显然我知道什么是客观上最好的:-)。但是，是的，他们可能会花时间取悦我的疯狂怪癖，而不是做更多有用的事情。我认为新开发人员比经验丰富的老手更适合。

@edg：关于“眨眼”和“试图取悦我”的确如此，但他们的代码当然也必须通过 QA 的黑盒系统测试。而且，我判断 I 是否可以在必要时维护他们的代码是一个相当客观（不仅仅是主观）的衡量标准，不是吗？

【参考方案2】：

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

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

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

我觉得重要的是：

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

最后，我会远离将软件指标作为目标——它们太容易玩弄，可能无法满足您的需求。我只会使用我想指导某人进入或退出特定行为的指标。

【参考方案3】：

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

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

【讨论】：

我基本上是团队负责人，我是实际日常规划和开发的一部分。我也认为每个开发者的表现水平是“显而易见的”，但这是我的主观意见，不符合目标，所以它们变得毫无意义。我宁愿我们可以完全忽略它们！

关键是你不能在这里得到任何科学测量，因此试图这样做是注定的，你应该把时间花在其他地方。 martinfowler.com/bliki/CannotMeasureProductivity.html 有一篇关于它的文章。

【参考方案4】：

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

通过证书考试 研究技术 X 并举办关于它的演讲 提交的构建中断更改数 关于内部知识管理的 wiki 文章数量​​li>

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

【讨论】：

我的方法是除了破坏构建之外的所有方法 1：发生的情况是，优秀的开发人员说“我太忙于做你要求我做的那个关键项目，所以我没有做演示或写文章”。我不能为此惩罚他们，所以目标变得毫无意义。

同上 Paul 所说的，我会遇到像写 wiki 文章这样短暂的问题 - 它们有什么好处吗？他们还在吗？编辑贡献呢？他们甚至有空闲时间吗？

【参考方案5】：

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

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

【讨论】：

幽默+1：我确实想知道这是否模棱两可，但只有在您故意误解时才决定:-)

请注意，有人将标题更改为“即使他们（目标）不起作用”。从那以后，我将其收紧为“即使目标不起作用”。只需为对此答案感到困惑的任何人添加评论！

【参考方案6】：

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

【讨论】：

定义“行使”。如果您只是使用覆盖工具，则无需实际执行即可轻松执行代码。

@Kent，我的意思是锻炼 == 执行。您能否扩展执行不锻炼的方式，我很乐意更新我的建议

当然。只需编写一个调用您的方法但不对调用结果做出任何断言的单元测试。您已经执行了代码 - 从而产生了更高的代码覆盖率 - 没有实际证明它在功能上是正确的。

谢谢，这样的事情可能是可行的，因为单元测试将成为他们开发和维护工作中不可或缺的一部分。但是，当人们可以做更多有用的工作时，编写无价值的单元测试来实现目标可能会出现问题。

同意，可能总会有办法玩弄任何特定的测量，这加强了 OP 点。

【参考方案7】：

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

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

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

【参考方案8】：

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

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

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

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

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

【参考方案9】：

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

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

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

【讨论】：

+1 仅用于在团队级别设定目标。将每个问题单都钉在一个人身上会让人失去动力，破坏团队精神，并且通常会对真实情况做出不准确的衡量，尤其是在可能的问题单数量非常少的情况下（例如，每个开发人员大约一个）。

【参考方案10】：

我喜欢的一个目标是：

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

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

【讨论】：

如果您全年都在为一个尚未交付给客户的项目工作怎么办？ 0 条评论。如果您在没有固定客户列表的通用网站上工作怎么办？

在这两种情况下，您仍在从事一个有客户的项目，无论是否是内部客户。您正在征求对您与客户的参与情况的审查，而不是对项目的审查。

【参考方案11】：

我认为，确定如何使个人发展与正在完成的项目保持一致是其中的一个关键点。让开发人员分析自己以发现弱点，同时对他人提供反馈，这可能是一种找到可以改进的地方，然后找到衡量它的方法。例如，我可能会发现我很少记录已完成的项目等我的年度目标，我可以声明我想要改进这一点，并且我制作的文档数量可以衡量这一点。它可能有效，也可能适得其反，这取决于我如何真正遵循它。一方面，我可能会担心我如何改进我的工作并做被认为是正确的方式，而消极的攻击性或幼稚的观点会产生大量的文档，如果它不是那么好质量方面，因为明年可以改进，因为这可能是另一个需要考虑的问题：与间隔时间相比，在一年内尽可能地改进的动机应该是什么？

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