SMART 목표는 프로그래머에게 유용합니까? [닫은]

내가 아는 여러 조직 은 프로그래머에게 SMART 목표를 사용 합니다. SMART는 특정, 측정 가능, 달성 가능, 관련성 및 타임 바운드의 약어입니다. 그들은 대기업에서 상당히 일반적입니다.

SMART 목표에 대한 저 자신의 이전 경험이 그다지 긍정적 인 것은 아닙니다. 다른 프로그래머가 성능을 측정하는 효과적인 방법을 찾았습니까? 프로그래머를위한 좋은 SMART 목표의 예는 무엇입니까 (있는 경우).

한마디로

아니

첫째 : 나는 어떤 의미로 SMART 목표를 세울 수있을 정도로 프로젝트를 안정적으로 유지 한 적이 없다. 프로젝트에서 내 역할이 변경되는 시점과 성능 검토가 수행되는 시점 사이의 시간은 너무 동기화되지 않습니다.

둘째 : 개인 성과를 측정하는 것은 "나의 직업이 아닌"사고 방식과 개인 및 / 또는 조직의 다양한 하위 팀간에 부정적인 경쟁을 유발할 수있는 좋은 방법입니다. 시스템을 게임하기가 쉽고 팀 전체를 실제로 도와주지 않고 자신을 찾고 있는지 확인하십시오. 우리는 사람들이 팀 플레이어가되도록 격려해야하지만, 우리 조직은 정반대입니다.

이러한 종류의 시스템의 대부분은 팀 구성에 반 추적입니다. Mary Poppendieck은 LeanEssays : Team Compensation 에서 할 수있는 것보다 훨씬 더 잘 설명했습니다 .

Sue는 Janice로부터 인사부로 전화를 받았습니다. “Sue,”그녀는 말했습니다.“팀이했던 훌륭한 일! 모든 평가 입력 양식을 작성해 주셔서 감사합니다. 그러나 실제로 모든 사람에게 최고 등급을 줄 수는 없습니다. 평균 평점은 '예상을 충족'해야합니다. '한계를 초과 한 사람'은 한 명 또는 두 명만있을 수 있습니다 ... "

... 20 세기 최고의 사상가 중 한 사람인 W Edwards Deming은 측정 할 수없는 피해는 사람, 공로 시스템 및 인센티브 급여를 순위 화함으로써 발생한다고 썼습니다. Deming은 모든 비즈니스는 시스템이며 개인의 성과는 시스템 운영 방식의 결과라고 믿었습니다. 그의 관점에서 볼 때, 시스템은 비즈니스 문제의 80 %를 야기하며 시스템은 경영진의 책임입니다. 그는 개인이 경영 문제를 해결하도록 권고와 인센티브를 사용하는 것은 효과가 없다고 썼다. 제작에 대한 자부심을 파괴하기 때문에 반대 순위를 정하는 것은 문제의 원인이 아닌 증상을 다루기 때문에 장점이 있습니다.

... 직원 평가 및 보상 시스템에 대해 자세히 살펴보고 이들이 기능 장애를 일으키는 원인을 살펴 보겠습니다 ...

우리는 내가 일하는 대기업에서 SMART 목표를 사용했습니다. 그들은 대부분 의미가 없습니다.

경영진에서 내려 오는 목표는 고상하고 추상적입니다. 구체적인 프로젝트 및 개발과 관련시키는 것은 일반적으로 농담입니다. 그룹으로 들어오는 대부분의 프로젝트는 비즈니스에서 나 왔으며 특정 비즈니스 요구를 충족해야합니다. 따라서 프로젝트를 코딩하고 프로덕션 환경에 배치하고 평소와 같이 멋진 작업을 수행하십시오. 그것은 상급 경영진이 생각 해낸 목표와 어떤 관련이 있습니까?

우리는 자신의 목표를 달성 할 때 그룹으로서 훨씬 더 잘합니다. 때로는 특정 주제에 대한 교육이나 새로운 프로세스 변경, 실제로 우리가하는 일과 관련이있을 수있는 새로운 프로세스 변경 구현을 포함합니다. 그들은 여전히 ​​기업 환경에서 그룹을 전진시키는 데 도움이되는 것들이기 때문에 매일 코딩 작업과 관련이 없습니다.

편집하다

Mnementh가 정확하게 지적했듯이, 나의 대답은 SMART가 아닌 SMART 목표를 기반으로합니다. 프로그래머의 관리자이고 SMART 목표를 구현하려는 경우 SMART인지 확인하십시오. SMART 목표를 구현하지 않는 방법으로 저의 관리자의 예를 사용하십시오. 프로그래머를 관리하지 않고 누군가가 이제 SMART 목표를 사용하기 시작했고 우리 목표와 같이 끝났다고 말하면, 고급 관리에서 버즈 단어를 좋아하고 확인할 수있는 사람들이 있다는 것을 이해하십시오. 그것들은 그들이 구현 한 것들의 목록에서 벗어납니다.

프로그래머가 다른 가능한 목표를 희생하면서 자신에게 제시된 기준에 상관없이 훌륭한 일을 할 것이라는 많은 연구가 있습니다.

이는 구체적이고 측정 가능한 목표를 달성하는 데 효과적이며, 구체적으로 명시되지 않은 것은 잘 수행하지 못함을 의미합니다. 즉, 목표 설정에 매우주의해야합니다.

코드 줄을 목표로 설정하고 싶지 않습니다. 날 믿어. 버그를 수정하면 버그가있는 코드를 작성할 수 있습니다. 기존 코드에서 버그 수정을 요청하면 "버그"(및 "수정")에 대한 매우 자유로운 정의가 생성됩니다. (또한 "달성 할 수있는"부분은 코드가 얼마나 버그가 많은지에 달려 있습니다.) 특정 시간에 기능의 완성도를 요구하는 것 ....

프로그래머가 원하는 것은 적절한 코드 품질로 적절한 시간에 유용한 내용을 작성하고 코드 품질을 유지하면서 향상시키고 수정하는 것입니다. 나는 좋은 기준이 될 구체적이고 측정 가능한 목표를 본 적이 없다.

우리는 매년이 운동을 겪습니다. 문제는 여기서 개발자가 자신이하는 일 (제품 관리자가 결정한 작업)에 대해 거의 자율권을 갖지 않는 것입니다. 우리는 적어도 종이에 목표를 추구하는 데 헌신 할 시간이 있다는 것이 운이 좋다. 그러나 현실적으로는 그보다 훨씬 적습니다.

이 프레임 워크 내에서 자기 개발 목표를 설정하는 것이 정말 효과적이라는 것을 알았습니다. 예를 들어 작년의 두 가지 목표는 다음과 같습니다.

1. 내년까지 디자인 패턴을 읽고 장난감 프로젝트를 작성하여 각 패턴을 배우고 시연합니다. 이것은 2 년이 걸리지 만 코딩 개선이 눈에 띄었습니다.
2. .NET 3.5 언어 기능을 연구하고 매 분기마다 동료에게 프리젠 테이션을합니다. LINQ에 대한 프레젠테이션은 결국 동료들이 냉담하고 온화한 관심을 가지고 다양한 정도로 평가했습니다. 그러나 나는 많은 것을 배웠고 C # 지식을 보여 주면서 아주 멋진 새 프로젝트를 수행하도록 옮겨졌습니다.

그렇습니다. 나는 그 일을하는 동안 유익을 얻었고 재미있었습니다.

솔직히 말해서, 우리 회사에서는 훌륭한 개발자 SMART 목표가 부족하다는 것은 회사 연설에 대한 무질서한 혐오와 관련이 있다고 생각합니다.

예, 올바르게 설정 한 경우

올바르게 설정하면 목표는 팀과 개인을 모두 향상시킬 수 있습니다. 그들은 직업에 맞게 조정되어야하며 개인을 위해 설계되어야합니다.

저는 DBA 팀 전체가 동일한 목표를 갖고있는 곳과 "KPI위원회가 결정한 글로벌 및 지역 KPI 준수"와 같은 높은 수준의 핸드 다운을 수행했습니다. 물론 아무도 모릅니다 ..

그런 다음 다시 관리자가 생각을 가지고 개별 목표를 설정하는 장소에 왔습니다.

편집하다:

Mary Poppendieck 기사를 읽었으며 SMART에 관한 것이 아닙니다. 예를 들어 "불가능의 인식"은 "달성"에 실패합니다.

개인을 위해 목표를 설정하고, 강도를 공유하고, 약점을 수정하고, 팀에 기여하도록 도와야합니다. 개인별 측정입니다.

x와 y의 비교는 없어야합니다.

x와 y의 목표는 시스템 내에서의 직급이나 직급에 비례해야합니다. 불공평합니다.

제한된 냄비에서 보너스 또는 급여를 설정하려면 일부 벤치 마크가 필요합니다. 대신 코드 줄을 세어야합니까? 동료 리뷰?

또한 글로벌 기업 정신을 바꿀 필요가없는 유효한 대안을 제시하십시오. 나는 SMART의 아무 비판이 없다 : 나는 어떻게 오줌 가난한 관리자의 비판이 ...

성과 프레임 워크로서 SMART는 목표가 관리자의 목표와 얼마나 밀접하게 연계되어 있는지만큼 효과적입니다. 때로는 SMART 목표가 먼저 DUMB 감소해야합니다. 그들을 만드십시오 :

• 할 수 있는
• 이해할 수 있는
• 다루기 쉬운
• 유익한

이상하게 들릴 수도 있습니다.

SMART 유형의 목표 설정 은 프로그래밍 컨텍스트에서 유용 할 수 있지만 지능적으로 수행해야하거나 다른 답변에서 지적했듯이 시간이 많이 걸리거나 더 나빠질 수 있습니다.

유용한 목표를 달성하려면 SMART 약어의 의미에 동의하는 데 도움이됩니다. 빠른 Google 검색 에서 다양한 정의가 발견되었습니다 .

• S : Specific에 대해 합의가있는 것 같습니다 (비록 그 의미에 대해 약간의 의견 차이가 있지만)
• M : 의미 있고 동기 부여가 더 일반적인 측정 가능의 대안입니다
• A : 가장 자주 달성 할 수있는 것으로 보이지만 동의 함을 보았습니다.
• R : 어디를 보느냐에 따라 현실적이고 관련성이 높으며 결과 중심
• 강조는 다양하지만 T는 항상 시간을 참조하는 것 같습니다.

먼저, 목표 설정 협상의 양측은 프로세스에 대한 일반적인 이해에서 작동해야합니다.

다음으로 조직, 부서, 그룹, 팀 (또는 모든 계층 구조와 관련된)에 대한 전반적인 목표를 설명하고 이해해야합니다. 이 시점에서 개인 (IMO, 목표는 가치가있는 개인 수준에서 설정되어야 함)이 개인의 활동을 진행시키는 데 도움이되는 적은 수의 목표에 동의 할 수 있어야합니다.

그것이 끝날지라도 여전히 모든 사람들의 시간 낭비였습니다. 목표는 정기적으로 검토하고 조정해야합니다. 달성 된 경우, 새로운 목표를 설정할 수있는 가능성을 고려해야하며, 달성되지 않은 경우 이유를 파악하고 필요한 경우 시정 조치를 취해야합니다.

관심있는 모든 사람들은 진지하게 또는 알고리즘 적으로 취해지지 않으면 이런 종류의 운동이 가치가 없다는 것을 알고 있어야합니다. 추출되는 가치는 노력에 비례합니다.

사람들이 SMART 목표에 유용하다고 생각하는 것을 보는 것이 도움이 될 수 있습니다. 여기에 질문을했습니다 ...

SMART 목표의 문제점은 그들이 측정 할 수있는 것을 선택해야한다는 것입니다. 측정 할 수있는 것과 조직의 성공에 중요한 것은 종종 같은 것이 아니며 (실제로는 프로그래밍에 결코 포함되지 않음) SMART 목표는 항상 내 경험에서 성능 평가에 실패합니다. 때로는 상황이 측정 가능하지만 별다른 노력을 기울이지 않는 경우도 있습니다 (SMART 목표와 같이 한 시간 동안 모든 이메일에 4 시간 이내에 답변했습니다. 실제로 1 년 동안 수천 건의 이메일을 통과하려고하는 사람이 있는지 확인하십시오. 정보를 제공했거나 답변이 필요한 경우 보낸 이메일을보고 응답했는지 확인한 다음 모든 전화 통화의 녹음을 듣고 응답했는지 확인하고 IM 로그를 확인하여 응답했는지 확인합니다. 토요일 밤 자정에 나에게 보낸 이메일은 어떻습니까?)

NO라고 답한 모든 사람들에게 당신의 목표는 충분히 똑똑하지 않았을 것입니다.

나는 그것들을 사용했고 그것들이 엄청나게 유용하다는 것을 알았습니다. 우리에게 적합한 것을 시도해 볼 수도 있습니다.

1. 분기 별 목표 설정
2. 측정 가능한 목표를 설정하십시오.
3. 개인에게 하나의 목표 만 설정
4. 목표가 너무 야심적이라고 말하면 개인이 목표를 수락하도록하십시오. 두 사람 모두 동의 할 때까지 재조정하십시오.
5. 분기 말에 부울 값이 나타납니다. 달성 된 목표 = 참 또는 거짓.

이것은 매우 강력하며 개발자에게 책임을 부여합니다. 6 개월 정도 지나면 변명을 찾고자하는 사람들

추신 : 나는 사람들이 대답을 투표로 이해하는 것을 이해할 수 있지만, 내가 알지 못하는 것을 배우게 될 관련 코멘트를 적어주십시오 :-)

SMART는 더 나은 목표를위한 몇 가지 기준을 기억하는 약어입니다. 따라서 SMART를 도입하면 경영진이이 원칙을 더 잘 준수해야합니다. SMART 관리가 없다면 어쨌든 목표를 세울 것이지만 너무 어려울 것입니다.

따라서 프로그래머는 아무런 변화가 없어야하기 때문에 경영진은 SMART를 구현하기 위해 스타일을 변경해야합니다. 그리고 그들이 옳다면, 프로젝트의 방향이 더 명확하고 시간 프레임이 설정되어 있기 때문에 프로그래머로서의 작업이 쉬워 질 수 있습니다.

경영진이 제대로하지 않으면 크게 변하지 않을 것입니다.