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

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

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

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

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

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

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

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

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

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

메모:

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

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

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

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

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

• 목표는 스마트합니다.
• 목표는 비즈니스 요구에 부합합니다.
• 당신은 목표에 "정상적인 작업"을 포함시킵니다. 사실 이것은 가장 중요한 목표입니다!
• 직원은 귀하가 설정 한 목표를 초과 할 수있는 기회가 있습니다.

마지막으로, 저는 소프트웨어 메트릭스를 목표로 삼을 것입니다. 게임하기가 너무 쉽고 필요한 것을 제공하지 못할 수도 있습니다. 특정 행동 안팎으로 누군가를지도하고 싶은 경우에만 측정 항목을 사용합니다.

이 모든 것은 "1 단계 관리"라는 사실로 귀결되며 대부분의 경영진은 직원을 알지 못합니다. 실제 일상적인 계획 및 개발의 일부가되는 대신 SMART와 같은 것이 나타납니다. 관리자가 실제 업무를 수행하는 사람들과 더 많은 시간을 보내 게된다면이 중 어느 것도 필요하지 않을 것입니다.

개인적으로 저는 생산성과 품질 인식 측면에서 개발자가 누구인지 가 분명한 애자일 환경에서 작업하는 것을 선호합니다 . 진정한 민첩한 접근 방식은 개발자뿐 아니라 디자이너, 테스터, 고객 및 제품 관리자가 프로세스에 포함되어야합니다. 이것은 당연히 관리자의 관점에서 더 나은 통찰력으로 이어집니다.

지금까지 본 측정 가능한 목표 :

• 인증서 시험 통과
• X 기술 연구 및 프레젠테이션 개최
• 커밋 된 빌드 중단 변경 수
• 내부 지식 관리에 대해 작성된 위키 기사 수

개발자에게 목표에 사용할 수있는 개인 개발 아이디어가 있는지 직접 물어 보는 것은 어떻습니까?

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

개발자가 작동하지 않는 경우, 아마도 약간의 목표는 단지 그들에게 약간의 인센티브를 줄 필요가 뭐? ;-)

"적절한 단위 테스트로 코드의 n % 이상을 테스트해야합니다."커버리지 도구를 사용하여이를 증명하고 다른 사람이 테스트 품질을 검토하도록합니다.

나는 매우 구체적인 목표를 미리 세우는 것, 즉 SMART (실제로는 우리가 실제로 같은 장소에서 일할 수도 있음)를 갖는 것이 실제로 좋은 생각처럼 보이지만 대부분의 팀에게는 실용적이지 않다고 생각합니다.

문제는 실제로 우리의 점진적인 목표 변경입니다. 비즈니스가 변화하고 개발자로서 우리는 적절한 시간 내에 적절하게 반응하고 대응해야합니다.

조직에서 팀 또는 그룹의 목적과 관련된 목표를 설정하는 것을 고려하십시오. 당신의 팀은 목적, 즉 거시적 목적에 부합하지 않으면 자금을받지 못할 것입니다. 전체 팀에 걸쳐 존재하고 비즈니스에 맞는 공동 목표를 가지고 있습니다. 사람들에게 책임을 부여하고 책임을 져야합니다. 그들의 성공과 실패를 축하하세요. HTH

프로그래머가 작업 할 때 수집되는 다음과 같은 여러 메트릭이 있습니다.

• 변경 / 추가 된 SLOC 수
• 프로세스의 다양한 단계에서 주입 된 오류 / 버그 수 (동료 검토 중, 동료 검토 후, 릴리스 후)
• 변경 요청 이행 / 거부
• 공식 문서 (소프트웨어 버전 설명, 디자인 문서 등)

이들 모두는 관리 및 소프트웨어 품질 보증을위한 프레젠테이션에서 유용하다고 생각하는 유형입니다. 그러나 나는 사람들의 성과에 대한 실제 평가에서 그것들이 끔찍하게 유용하다는 것을 결코 발견하지 못했습니다. 여기에서 Joel의 점수 가 유효 하다는 것을 알게되었습니다. 메트릭은 좋은 팀 분위기를 조성하지 않습니다.

안타깝게도 우리 모두는 다른 사람 (관리, 품질 보증, 외부 계약자 등)이 메트릭을 요구하는 세상에 살고 있습니다. 저는 균형 잡힌 행동이 필요하다는 것을 발견했습니다. 이러한 측정 기준을 제공 할뿐만 아니라 무형 자산의 증거도 제공합니다. 무형은 각 프로그래머가 수행 한 작업이며 반드시 추적되지는 않습니다. 예를 들어, 아무도 만지고 싶지 않은 레거시 코드를 조사하는 데 많은 시간을 소비 한 프로그래머가있었습니다. 그 기간 동안 그의 통계는 낮았지만 그 노력은 매우 소중했습니다.

내가 찾은 유일한 방법은 추가 무형 카테고리의 생성을 추진하고 다른 측정 항목과 동일한 가중치를 부여하는 것입니다. 일반적으로 이것은 특정 프로그래머의 균형을 맞추기에 충분합니다.

문제 중 하나는 부서 / 부서로서 IT 조직이 측정 가능한 전략적 목표를 가지고 있지 않다는 것입니다. 그렇게한다면 개인의 목표를 설정하는 것이 더 쉬울 것입니다.

예를 들어, 제기되는 문제 티켓 수를 줄이기위한 부서별 이니셔티브가있는 경우, 그들이 돌보는 소프트웨어와 관련된 티켓 수를 기반으로 개인 목표를 설정할 수 있습니다.

소프트웨어 개발은 ​​공동 작업이기 때문에 팀 수준에서 목표를 설정 한 다음 팀에 대한 기여도에 따라 개인을 평가하는 것이 더 합리적입니다.

내가 좋아하는 목표는 다음과 같습니다.

프로젝트 클라이언트로부터 프로젝트 참여에 대한 N 개의 긍정적 인 리뷰를 요청하십시오.

이는 고객 (내부 또는 외부)으로부터 긍정적 인 피드백을 서면으로받는 것이 항상 좋기 때문에 도움이됩니다. 구하기 어렵지 않고 관련성이 있으며 목록에서 간단하지만 의미없는 틱이 아닙니다.

수행중인 프로젝트와 개인 개발을 조정하는 방법을 결정하는 것이이 점에서 핵심이라고 생각합니다. 개발자가 자신을 분석하여 약점을 찾도록하고 다른 사람에게 피드백을 제공하는 것은 개선 할 수있는 사항을 찾은 다음이를 측정하는 방법을 찾는 방법이 될 수 있습니다. 예를 들어, 완성 된 항목을 거의 문서화하지 않기 때문에 올해의 목표에 대해 개선하고 싶다고 말할 수 있으며, 내가 생성하는 문서의 양이 그 척도가 될 수 있습니다. 실제로 어떻게 따르는 지에 따라 작동하거나 역효과를 낼 수 있습니다. 한편으로는 내가 어떻게 내 작업을 개선하고 적절한 방법으로 간주 될 수 있는지에 대한 타당한 우려가있을 수 있지만, 수동적 공격적이거나 유치한 견해가 그렇지 않은 경우 산더미 같은 문서를 생성하는 것입니다.

효과적인 개발자를 정의하는 것은 이것의 또 다른 요소입니다. 버그를 가장 잘 고치는 사람입니까? 새로운 작업이 가장 빨리 이루어 집니까? 새로운 작업이 빨리 완료되지는 않지만 테스트 및 문서화로 완료됩니까? 당신이 호출하는 어떤 효과 (가)부터 "이 달려있다" 표준 응답은 여기에서 명확히해야한다.