목표가 작동하지 않더라도 개발자를위한 목표를 설정해야 함

목표가 작동하지 않더라도 개발자를위한 목표를 설정해야 함

---

그것은되어 일반적으로 인정 된 것을 측정 가능한 목표를 설정하는 소프트웨어 개발자를 위해하는 일을하지 않는 목표에 너무 많은 초점은 조직의 목표에 행동 카운터로 이어질 수있는, (소위 " 측정 기능 장애 ").

그러나 우리 회사에서는 모든 직원에 대한 목표를 설정해야하며 인사부로부터 그들을 스마트 하게 만들도록 권장합니다 . 과거에는 동료 1 차 관리자 (팀장)와 여러 가지 접근 방식을 시도했습니다.

1. "기술 X에 대한 교육 수행", "아무도 이해할 수없는 코드 Y에 대한 문서 작성"등과 같이 일반 작업에 추가되는 측정 가능한 목표를 설정합니다. 연례 성과 평가에 관해서는 개발자를 서면 목표가 아니라 평범한 작업의 측정 할 수없는 가치에 대한 내 의견에 따라 평가하십시오. 그것이 실제로 회사가 관심을 갖는 것이기 때문입니다.
2. "작업 관리 시스템에 기록 된대로 수행 된 작업 일수", "도입 된 버그 수", "발생한 생산 수"와 같은 매우 구체적인 목표를 설정합니다. 이로 인해 더 나은 "점수"를 얻기 위해 부풀려진 추정치와 잘못된 버그 분류가 발생했습니다. 흥미롭게도이 시스템에서 높은 점수를받은 개발자들조차도 팀 내부의 본질적인 신뢰가 손상되었고 항상 높은 지위를받을 자격이 있다고 생각하지 않았기 때문에이 시스템을 좋아하지 않았습니다.
3. "정상적인 일을 잘하십시오"에 변형 인 모호한 목표를 설정하십시오. 연간 평가에 관해서는, 그들의 평가는 목표에 대한 성과를 반영하지만 목표 자체는 측정 할 수 없거나 달성 할 수 없어 눈살을 찌푸립니다.

이들 중 어느 것도 이상적이지 않습니다. 효과에 대한 증거에도 불구하고 소프트웨어 개발자에게 의미 있고 측정 가능한 목표를 만들어야하는 비슷한 상황에 처해 있었다면 어떤 접근 방식이 가장 효과적 이었습니까?

---

동일한 요점을 다루지 않는 관련 질문 :

• 소프트웨어 엔지니어에게 좋은 성능 목표는 무엇입니까?
• 개발자를위한 성능 목표 설정
• 프로그래머에게 적합한 성능 지표는 무엇입니까?
• 프로그래머를위한 공정한 생산성 측정 기법이란 무엇입니까?
• 내년 경력 "목표"가 필요합니다

---

업데이트 (2009 년 11 월 18 일) : 내 질문에 대해 10 개의 찬성표가 있으며 가장 높은 등급의 답변에는 4 개의 찬성표 만 있습니다 (각각 1 개 포함). 나는 이것이 우리에게 뭔가를 알려줍니다 생각 : 조엘과 다른 사람이 맞다 아마 것을, 그리고 유래의 결합 된 지혜를 가지고 올 수없는 어떤 악영향의 실제 (측정 불가) 값에 영향을주지 않고 gamed 수없는 개발자를위한 강력한 측정 가능한 목표를 자신의 작업. 그래도 시도해 주셔서 감사합니다!

---

어떤 접근 방식이 가장 효과적 이었습니까?

단 하나의 목표 : 버그를 찾거나 다른 비판을받지 않고 리뷰어로서 코드 검사 / 동료 리뷰를 통과하여 무언가를 다시 실행하도록 요청하는 것입니다.

노트:

• 나는 신입 사원의 빨리 끝내는 능력을 측정하지 않았고 그들을 격려하지도 않았다 : 사람들이 잘 끝내는 법을 배우 길 원했다 (잘하지 못하면 끝나지 않기 때문이다)
• 사람들은 코드 검토에서 내가 찾은 것을 배웠습니다. 따라서 단순한 관리 목표가 아니라 학습 기회 이자 품질 관리 측정입니다.
• 내 의견에는 두 가지 범주가 있습니다.
  1. 이것은 버그입니다. 체크인하기 전에이 문제를 해결해야합니다.
  2. 제안으로, 나는 그런 일을했을 것입니다.
• 잠시 후, 사람의 코드를 검토하면 "반드시 수정해야하는"항목을 찾지 못할 것입니다 (이 시점에서 더 이상 작업을 검토 할 필요가 없습니다).

---

개인적으로 저는 두 가지 종류의 목표를 설정하려고합니다.

• 비즈니스 중심의 목표 (이것이 결국 우리가 돈을받는 이유입니다). 예 : "2009 년 6 월 1 일까지 프로젝트 X 완료"). 이러한 목표는 종종 팀의 여러 구성원이 공유하며이를 알고 있습니다. 팀은 프로젝트를 일찍 시작하거나 필요한 기능을 초과하여 목표를 초과 할 수 있습니다. 개인은 더 많은 기능을 생성하거나, 버그를 줄이거 나, 팀의 다른 구성원을지도하고 지원함으로써 목표를 초과 할 수 있습니다.

• 개인 성장 목표, 예를 들어 개발자가 기술 세트에 추가하려는 기술을 포함하는 프로젝트 완료, 사용자의 도메인을 더 잘 이해, 리더십 경험 얻기 등.

다음 사항이 중요하다고 생각합니다.

• 목표는 스마트하다
• 목표는 비즈니스 요구에 부합합니다.
• 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.

---

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?

---

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

---

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? ;-)

---

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.

---

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.

참고URL : https://stackoverflow.com/questions/446720/having-to-set-objectives-for-developers-even-though-objectives-dont-work