必须为开发人员设定目标，即使目标不起作用

对于软件开发人员而言，制定可衡量的目标是 没用，因为过于关注目标会导致违背组织目标的行为(所谓的“ 测量功能障碍”)。

然而，在我的公司，我们被要求为所有员工设定目标，并被人力资源部鼓励使他们 精明。过去，我和我的一级经理同事(团队负责人)曾尝试过多种方法:

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

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

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

更新 (2009年11月18日) : 我的问题有10个赞，最高分的答案只有4个赞(包括我自己的一个)。我认为这告诉了我们一些事情: 也许 Joel 和其他人是对的，堆栈溢出的智慧结合在一起不能为开发人员提出 任何引人注目的、可测量的目标，这些目标不能在不影响他们工作的真正(不可测量的)价值的情况下进行游戏。谢谢你的努力！

81718 次浏览
小开

"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.

小开

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:

  • Pass a certificate exam
  • Research technology X and hold a presentation about it
  • Number of build breaking changes committed
  • Number of wiki articles written on the internal knowledge management

How about asking your developers directly if they have some ideas for personal development which then could be used for objectives?

小开

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

小开

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.

小开

what approach has worked best for you?

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:
    1. This is a bug: you must fix this before you check in
    2. 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).
小开

Having to set objectives for developers, even though they don’t work

If your developers don't work, perhaps some objectives are just what they need to give them some incentive? ;-)

小开

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.

小开

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.

小开

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:

  • 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.


提交答案