민첩한 개발자로서“SMART”목표를 작성하는 방법은 무엇입니까?

많은 회사와 마찬가지로 제가 일하는 회사는 SMART 목표를 기반으로 성과 검토 시스템으로 전환하고 있습니다. 우리 팀은 Extreme Programming의 관행을 채택한 고도로 민첩한 개발 팀 입니다. 우리의 큰 이익을 위해 민첩한 관행의 고용은 즉각적이고 고위 경영진을 전적으로 지원합니다.

작업을 수행하기 위해 우리 팀은 3 주 반복을 사용합니다. 즉각적인 반복을 넘어서 우리는 일반적인 계획을 분기별로 계획했습니다. 우리가 지금부터 몇 분기 동안 성취 한 것이 바로 분기에 달성 할 수있는 것보다 훨씬 더 위험하다는 것을 의미합니다. 우리는 프로젝트가 어디로 향하고 있는지에 대한 일반적인 아이디어를 가지고 있지만 여기서 키워드는 일반적 입니다.

우리 팀을 포함한 프로젝트 계획 멤버에 대한 우리의 접근 방식을 감안할 때, 구체적이고 측정 가능하며 달성 가능하고 관련성 있고 시간 제한적인 (SMART) 목표를 작성하는 것이 어렵다는 것을 알게되었습니다.

SoftwareEngineering.se에 대한 두 가지 기존 질문은 다음과 같은 우려 사항을 해결하는 데 도움이됩니다.

• 프로그래머에게 좋은 SMART 목표의 예는 무엇입니까?
• SMART 목표는 프로그래머에게 유용합니까?

그러나 민첩한 개발 팀에서 일할 때 SMART 목표를 다루기위한 구체적인 내용보다 더 일반적인 응답이 도출되었습니다. 민첩한 개발자로서 구체적이고, 측정 가능하고, 달성 가능하고, 관련성 있고 시간이 제한된 5 년에서 7 년의 목표를 어떻게 작성합니까?

이 답변은 애자일 팀 주변에 그러한 성과 관리 시스템을 설치 한 사람의 관점에서 작성되었습니다. 여러분과 마찬가지로 팀의 모든 직원 은 Agile 그룹에 적용되는 1 년 동안 지속되는 SMART 목표 의 난이도 / 실용성을 깨달았습니다 .

아냐! 필요한 경우 (논리가 절반으로 구워진 경우) 다음 합리화를 호출하십시오. 그러나 직속 조직 외부의 검토 자에게이를 설명하면 성능 관리 시스템에 넣은 실제 "목표"의 단계가 설정됩니다.

• S : 구체적 : 각 스프린트 계획 동안, 팀은 달성 할 특정 작업 세트에 동의하고이를 수행하기로 약속합니다. 과제 (및 사용자 스토리)는 내가 달성하고자하는 목표, 목표 달성의 목적 / 이점, 참여 대상, 발생 위치 및 제약에 대한 질문에 답변합니다.
• 측정 가능한 M : 이러한 작업 목록과 개발에서 코드 검토, QA, 릴리스 (또는 흐름에 관계없이)에 이르기까지 스프린트 전체의 티켓 이동은 작업량과 달성시기에 대한 질문에 답변합니다. .
• 달성 가능 : 기능성 민첩한 그룹은 일반적으로 계획 단계에서 분명히 달성 할 수없는 한 무언가를 저 지르지 않습니다. 모든 부분이이를 달성하는 방법을 알고 있습니다.
• R : 관련 질문 : 가치있는 질문인지, 적시인지, 다른 노력과도 일치합니까? 스토리와 과제는 스프린트에 빠지지 않고 모든 질문에 대한 대답이 '예'가 아니라면 최선을 다합니다 ( 일반적으로 ... YMMV)
• 시간 제한에 대한 T : 스프린트는 반드시 2 주, 3 주, 또는 그 이하의 시간 제한입니다.

분기 별 작업 (및 1 년 간의 작업) 자체가 하나의 큰 SMART 목표이며 팀의 성과가 우수하고 속도가 긍정적이며 릴리스가 진행 중이므로 목표를 달성하고 있음을 이해하고 확신하는 경우 그런 다음 SMART 프로세스를 다른 사람의 이익을 위해 SMART 목표 세트로 변환하는 방법입니다.

나는 과거에 나에게 모호하고 잘 보이지 않는 것을 쓰면서 성공적으로이 작업을 수행 할 수 있었지만 실제로는 다른 사람들에게는 완벽하게 받아 들여질 수 없었습니다.

나를 위해 다른 곳에서 소집을 통과 한 몇 가지 예 :

• "내부 소프트웨어 개발 프로세스에 따라 전체 제품 개발 일정 (blah blah)에 따라 내년 3 개월마다 WidgetMaker의 새 버전을 출시하고 싶습니다."

• "백 로그 그루밍 프로세스의 점진적인 변화에 초점을 맞춰 팀의 개발 속도를 릴리스 A에서 릴리스 B까지 n % 씩 늘리고 싶습니다. 우리의 효율성을 높이고 제품 배송 지연을 줄이려고합니다."

아시다시피 이것이 실제 개발 그룹의 기본 원칙은 아니지만 전적으로 관련이 없으며 내 경험상 직접 조직 외부의 사람들에게 실제로 스마트하고 유용하게 보이는 유형입니다. 똑바로 거짓말 또는 완전히 절름발이).