I think that having very specific goals up front, i.e., SMART (maybe we work at the same place actually), seems like a good idea in practice but it isn't very practical for most teams.
The problem really is our incremental goals change. The business changes and as developers we need to react and react properly and in a reasonable time frame.
Consider setting goals that tie with your team or group's purpose in the organization. Your team wouldn't be funded if it didn't serve a purpose - a macro purpose. Have collective goals that exist across your entire team and that align to the business. Give people responsibility and hold people accountable. Celebrate their successes and failures (if we don't fail at times we're likely not trying and that's what you want from people). HTH
We have a number of metrics that are collected as programmers do work, such as:
Number of SLOC changed / added
Number of errors / bugs injected in various stages of the process (during peer review, post peer review, post release)
Change requests fulfilled / rejected
Formal documents (software version descriptions, design docs, etc.)
All of these are tangibles which I find useful in presentations for management and software quality assurance. But I have never found them terribly useful in actual evaluations of people's performance - which is the point made by several of the links you listed. I've found that Joel's points here are valid - metrics never promote a good team atmosphere.
Unfortunately, we all live in a world where metrics are required by others (management, quality assurance, outside contractors, etc.). I've found that a balancing act is required - providing those metrics, but also providing evidence of intangibles - intangible being what each programmer has accomplished that is not necessarily tracked. For example, I had a programmer who spent a large amount of time investigating legacy code that no one else wanted to touch. Even though his metrics were low for that period of time, that effort was invaluable.
The only way I've found to include such things has been to push for the creation of an additional intangible category and give it equal weight with the other metrics. Usually this is sufficient to swing the balance for a particular programmer.
One of the problems would seem to be that as a division/department IT organisations don't have measurable strategic goals. If they did it would be easier to set the goals for the individuals.
e.g. If there was a departmental initiative to reduce the number of problem tickets raised, then, you could set an individuals goals based on the number of tickets related to the software they look after.
Since software development is largly a collabarative it would make more sense to set goals at the team level, and, then rate individuals according to thier contribution to the team.
Solicit N positive reviews of your involvement in a project from the project client.
This helps as it is always good to have some written positive feedback from customers (internal or external). Its not hard to get, its relevant and it is an easy, but not meaningless tick on the list.
Determining how to align personal development with the projects being done is a key point in this I think. Having developers analyze themselves to find weaknesses along with giving feedback on others may be a way to find what may be improved and then finding a way to measure it. For example, I may find that I rarely document completed items and so on my objectives for the year I can state that I want to improve this and that the amount of documentation I produce can be a measure of that. It may work or it may backfire depending on how I follow it really. On the one hand there may be valid concerns for this being how I improve my work and do what may be viewed as the proper way while a passive aggressive or childish view would be to produce a mountain of documentation if it isn't that good in terms of quality as that can be improved next year as this can be another point to consider: What is supposed to be the motivation to improve as much as possible all in a year compared to spacing things out?
Defining an effective developer is another element to this. Is it the person that fixes bugs best? Does new work quickest? Does new work complete with tests and documentation even though it isn't done quick? What are you calling effective since the "it depends" standard response should be clarified here.
Only one objective: pass a code inspection/peer review, with me as the reviewer, without me finding any bugs or having any other criticism, that has me asking you to redo something.
Notes:
I wasn't measuring new hires' ability to finish quickly, and didn't encourage them to: I wanted people to learn how to finish well (because if it's not finished well, then it's not finished)
People learned what I looked for in a code review: so it's a learning opportunity and a quality control measure, and not just a management objective
My comments would have two categories:
This is a bug: you must fix this before you check in
As a suggestion, I would have done such-and-such
After a while, my reviews of a person's code would stop finding any "must fix" items (at which point I wouldn't need to review their work any more).
Business-focussed objectives (this is why we are getting paid after all). For instance, "complete project X by 1 June 2009"). These objectives are often shared across several members of the team (and they are aware of this). The team can exceed the objective by bringing the project in early or by exceeding the functionality required. Individuals can exceed the objective by producing more functionality, having fewer bugs against them, or coaching and supporting other members of the team.
Personal growth objectives, for instance completing a project involving a technology that the developer wants to add to their skill set, understanding the user's domain better, gaining leadership experience etc.
I feel that it is important that:
Objectives are SMART
Objectives are aligned with the needs of the business
You do include "normal work" in objectives, in fact these are the most important objectives!
The employee has some opportunity to exceed the objectives you set
Finally, I would stay away from software metrics as objectives - they are too easy to game and probably won't give you what you need. I would only use a metric where I want to coach someone in or out of a particular behaviour.
This all boils down to the fact that "first level management", and most any management doesnt know their employees. Instead of being part of the actual day to day planning and development, things like SMART pops up. If managers were to spend more time with the guys who does the actual work, none of this would be needed.
Personally, I prefer working in an agile environment where it is obvious who of the developers performs in terms of productivity and quality awareness. A true agile approach requires that not only developers, but designers, testers, customers and product managers are included in the process. This naturally leads to better insights from the managers point of view.
"Ensure that at least n% of your code is tested by a suitable unit test" Use a coverage tool to prove it, and have someone else review for test quality.
发布评论
评论（11）
我认为预先制定非常具体的目标，即 SMART（也许我们实际上在同一个地方工作），在实践中似乎是一个好主意，但对于大多数团队来说并不是很实用。
问题实际上是我们的渐进目标发生了变化。 业务发生变化，作为开发人员，我们需要在合理的时间范围内做出正确的反应。
考虑设定与您的团队或团体在组织中的目的相关的目标。 如果你的团队没有达到某个目的（宏观目的），就不会获得资助。 拥有整个团队存在且与业务相一致的集体目标。 赋予人们责任，让人们承担责任。 庆祝他们的成功和失败（如果我们有时不失败，我们可能就不会尝试，这就是您希望人们做到的）。 华泰
I think that having very specific goals up front, i.e., SMART (maybe we work at the same place actually), seems like a good idea in practice but it isn't very practical for most teams.
The problem really is our incremental goals change. The business changes and as developers we need to react and react properly and in a reasonable time frame.
Consider setting goals that tie with your team or group's purpose in the organization. Your team wouldn't be funded if it didn't serve a purpose - a macro purpose. Have collective goals that exist across your entire team and that align to the business. Give people responsibility and hold people accountable. Celebrate their successes and failures (if we don't fail at times we're likely not trying and that's what you want from people). HTH
我们在程序员工作时收集了许多指标，例如：
所有这些都是有形的，我发现它们在管理和软件质量保证的演示中很有用。 但我从未发现它们在实际评估人们的表现方面非常有用 - 这是您列出的几个链接所指出的观点。 我发现 Joel 的观点此处是有效的 - 指标永远不会促进良好的团队氛围。
不幸的是，我们都生活在一个其他人（管理、质量保证、外部承包商等）都需要指标的世界。 我发现需要采取平衡措施 - 提供这些指标，但也提供无形资产的证据 - 无形资产是每个程序员所完成的工作，但不一定会被跟踪。 例如，我有一位程序员花费了大量时间研究其他人不想接触的遗留代码。 尽管他在那段时间的指标很低，但这种努力是无价的。
我发现纳入此类内容的唯一方法是推动创建一个额外的无形类别，并给予其与其他指标同等的权重。 通常这足以改变特定程序员的平衡。
We have a number of metrics that are collected as programmers do work, such as:
All of these are tangibles which I find useful in presentations for management and software quality assurance. But I have never found them terribly useful in actual evaluations of people's performance - which is the point made by several of the links you listed. I've found that Joel's points here are valid - metrics never promote a good team atmosphere.
Unfortunately, we all live in a world where metrics are required by others (management, quality assurance, outside contractors, etc.). I've found that a balancing act is required - providing those metrics, but also providing evidence of intangibles - intangible being what each programmer has accomplished that is not necessarily tracked. For example, I had a programmer who spent a large amount of time investigating legacy code that no one else wanted to touch. Even though his metrics were low for that period of time, that effort was invaluable.
The only way I've found to include such things has been to push for the creation of an additional intangible category and give it equal weight with the other metrics. Usually this is sufficient to swing the balance for a particular programmer.
问题之一似乎是，作为一个部门/部门，IT 组织没有可衡量的战略目标。 如果他们这样做的话，为个人设定目标就会更容易。
例如，如果有部门计划减少提出的问题单数量，那么，您可以根据与他们所管理的软件相关的单数数量来设定个人目标。
由于软件开发在很大程度上是一种协作，因此在团队级别设定目标，然后根据个人对团队的贡献对个人进行评分更有意义。
One of the problems would seem to be that as a division/department IT organisations don't have measurable strategic goals. If they did it would be easier to set the goals for the individuals.
e.g. If there was a departmental initiative to reduce the number of problem tickets raised, then, you could set an individuals goals based on the number of tickets related to the software they look after.
Since software development is largly a collabarative it would make more sense to set goals at the team level, and, then rate individuals according to thier contribution to the team.
我喜欢的一个目标是：
从项目客户那里征求 N 个对你参与项目的积极评价。
这很有帮助，因为从客户（内部或外部）那里获得一些书面的积极反馈总是好的。 它并不难获得，它是相关的，并且它是一个简单但并非毫无意义的清单上的勾号。
An objectives that I like is:
Solicit N positive reviews of your involvement in a project from the project client.
This helps as it is always good to have some written positive feedback from customers (internal or external). Its not hard to get, its relevant and it is an easy, but not meaningless tick on the list.
我认为，确定如何使个人发展与正在完成的项目保持一致是其中的关键点。 让开发人员分析自己以找出弱点，同时向他人提供反馈，这可能是找到可以改进的地方，然后找到衡量方法的一种方法。 例如，我可能会发现我很少记录已完成的项目，因此我可以声明我想改进这一年的目标，并且我生成的文档数量可以衡量这一点。 它可能会起作用，也可能会适得其反，这取决于我真正遵循的方式。 一方面，人们可能会担心我如何改进我的工作并做可能被视为正确的事情，而消极的攻击性或幼稚的观点可能会产生大量的文档，如果它在某些方面不太好的话。质量方面，因为明年可以改进，因为这可能是另一个需要考虑的点：与间隔时间相比，在一年内尽可能改进的动力应该是什么？
定义一个有效的开发人员是另一个要素。 是修复错误最好的人吗？ 新的工作最快吗？ 新工作是否完成了测试和文档，即使它没有很快完成？ 您所谓的有效是什么，因为“视情况而定”标准响应应在此处澄清。
Determining how to align personal development with the projects being done is a key point in this I think. Having developers analyze themselves to find weaknesses along with giving feedback on others may be a way to find what may be improved and then finding a way to measure it. For example, I may find that I rarely document completed items and so on my objectives for the year I can state that I want to improve this and that the amount of documentation I produce can be a measure of that. It may work or it may backfire depending on how I follow it really. On the one hand there may be valid concerns for this being how I improve my work and do what may be viewed as the proper way while a passive aggressive or childish view would be to produce a mountain of documentation if it isn't that good in terms of quality as that can be improved next year as this can be another point to consider: What is supposed to be the motivation to improve as much as possible all in a year compared to spacing things out?
Defining an effective developer is another element to this. Is it the person that fixes bugs best? Does new work quickest? Does new work complete with tests and documentation even though it isn't done quick? What are you calling effective since the "it depends" standard response should be clarified here.
只有一个目标：通过代码检查/同行评审，由我作为审阅者，没有发现任何错误或有任何其他批评，这让我要求你重做一些事情。
注释：
Only one objective: pass a code inspection/peer review, with me as the reviewer, without me finding any bugs or having any other criticism, that has me asking you to redo something.
Notes:
就我个人而言，我尝试设定两种目标：
以业务为中心的目标（这就是我们获得报酬的原因）。 例如，“在 2009 年 6 月 1 日之前完成项目 X”）。 这些目标通常由团队的多个成员共享（他们也意识到这一点）。 团队可以通过提前启动项目或超出所需的功能来超越目标。 个人可以通过生产更多的功能、减少针对他们的错误或指导和支持团队的其他成员来超越目标。
以
个人成长目标，例如完成一个涉及开发人员想要添加到其技能组合中的技术的项目、更好地了解用户的领域、获得领导经验等。
个人
我认为重要的是：
最后，我会远离软件指标作为目标 - 它们太容易被欺骗，并且可能不会给您带来您所需要的东西。 我只会在我想指导某人进行或不进行特定行为时使用指标。
Personally I try to set two sorts of objectives:
Business-focussed objectives (this is why we are getting paid after all). For instance, "complete project X by 1 June 2009"). These objectives are often shared across several members of the team (and they are aware of this). The team can exceed the objective by bringing the project in early or by exceeding the functionality required. Individuals can exceed the objective by producing more functionality, having fewer bugs against them, or coaching and supporting other members of the team.
Personal growth objectives, for instance completing a project involving a technology that the developer wants to add to their skill set, understanding the user's domain better, gaining leadership experience etc.
I feel that it is important that:
Finally, I would stay away from software metrics as objectives - they are too easy to game and probably won't give you what you need. I would only use a metric where I want to coach someone in or out of a particular behaviour.
这一切都归结为“一级管理层”，而大多数管理层并不了解他们的员工。 像 SMART 这样的东西突然出现，而不是成为实际日常规划和开发的一部分。 如果经理们花更多的时间和那些做实际工作的人在一起，那么这些都不需要了。
就我个人而言，我更喜欢在敏捷环境中工作，在这种环境中，谁的开发人员在生产力和质量意识方面的表现明显。 真正的敏捷方法不仅需要开发人员，还需要设计师、测试人员、客户和产品经理都参与其中。 从管理者的角度来看，这自然会带来更好的见解。
This all boils down to the fact that "first level management", and most any management doesnt know their employees. Instead of being part of the actual day to day planning and development, things like SMART pops up. If managers were to spend more time with the guys who does the actual work, none of this would be needed.
Personally, I prefer working in an agile environment where it is obvious who of the developers performs in terms of productivity and quality awareness. A true agile approach requires that not only developers, but designers, testers, customers and product managers are included in the process. This naturally leads to better insights from the managers point of view.
到目前为止我看到的可衡量目标：
直接询问您的开发人员是否有一些个人想法如何？那么开发可以用于实现目标吗？
Measurable objectives I have seen so far:
How about asking your developers directly if they have some ideas for personal development which then could be used for objectives?
如果您的开发人员不工作，也许某些目标正是他们所需要的，可以给他们一些激励？ ;-)
If your developers don't work, perhaps some objectives are just what they need to give them some incentive? ;-)
“确保至少 n% 的代码通过合适的单元测试进行了测试” 使用覆盖率工具来证明这一点，并让其他人审查测试质量。
"Ensure that at least n% of your code is tested by a suitable unit test" Use a coverage tool to prove it, and have someone else review for test quality.