사람에 집중한 개발자 생산성 측정
개발자 생산성 을 측정하기가 무척 어렵다는 것을 알고있다. 사람들이 하는 것들을 정량적 데이터로 뽑아내고 그것을 다시 추상적인 '퍼포먼스'라는 개념으로 바꿔내야한다.
하지만 적절한 수준에서 팀의 퍼포먼스를 추적할 수 있다면 가질 수 있는 장점이 많다. 현재 우리가 과거에 비해 얼마나 잘하고 있는 것인지 파악할 수 있으며 그것을 바탕으로 문제점을 찾고 개선하여 제품을 더 높은 품질로 빠르게 전달할 수 있을 것이다. 혹은 C-레벨의 누군가나 다른 이해관계자들과 효과적으로 커뮤니케이션을 할 수 있는 수단이 될 수도 있을 것이다.
예전에 속했던 팀에서는 DORA 지표 기반의 개발자 생산성 을 측정해주는 'Swarmia' 라는 SaaS 솔루션을 쓰면서 팀의 퍼포먼스를 측정했었다. 하지만 시간이 지나면서 어딘가 부족한 부분을 느낄 수 있었다. 저 지표가 정말로 우리 팀의 역량을 대표할 수 있을까? 저것들을 개선하면 정말로 우리팀의 퍼포먼스가 더 좋아지는 것일까? 와 같은 의구심이 들었다.
마틴 파울러가 개발자 생산성 측정과 관련된 글을 올렸다. 이 글에선 람에 집중한 ‘정성적 지표’를 정량적 지표와 상호보완적으로 사용하면서 더욱 폭넓고 다양한 측면에서 생산성을 측정할 수 있다고 이야기한다.
어려운 문제라 생각해왔고 관심있는 문제이기 때문에 번역을 해두고 두고두고 보면 좋겠다고 생각해서 번역을 했다.
원문은 Measuring Developer Productivity via Humans 에서 확인할 수 있다.
이 글에 있는 인상적인 인용구를 하나 가져오자면
"저는 엔지니어는 로봇이 아니라 인간이라는 사실을 매우 굳게 믿고 있으며, 많은 엔지니어들도 이를 인정하고 있다고 생각합니다. 그리고 기본적인 수치만으로는 모든 것을 파악할 수 없습니다. 그래서 저희는 전체 개발자 경험을 이해하는 데 도움이 되는 포괄적인 설문조사를 실시하는 것이 정말 중요했습니다."
Measuring Developer Productivity via Humans
개발자 생산성 을 측정하는 것은 어려운 과제입니다. 개발 주기 시간과 처리량에 초점을 맞춘 기존의 지표는 한계가 있으며, 이에 대한 대안으로 어디로 눈을 돌려야 할지에 대한 명확한 해답도 없습니다. 정성적 지표는 개발자 자신으로부터 도출된 데이터를 사용하여 개발자 생산성 을 측정하고 이해하는 강력한 방법을 제공합니다. 조직은 시스템 데이터보다는 사람의 데이터를 사용하여 개발자 생산성 을 측정하는 데 우선순위를 두어야 합니다.
지금 이 순간에도 어딘가에서 기술 담당 임원이 상사에게 이렇게 말합니다: "엔지니어링 팀의 생산성을 측정할 수 있는 방법이 필요합니다." 여러 팀들이 모여 잠재적인 솔루션을 모색하고 몇 주 후 리드 타임, 배포 빈도, 엔지니어당 생성된 풀 리퀘스트 수와 같은 메트릭을 구현할 것을 제안합니다.
얼마 지나지 않아 시니어 엔지니어링 리더들이 모여 새로 만든 대시보드를 검토합니다. 곧바로 질문과 의문이 제기됩니다. 한 리더는 "우리의 리드 타임은 2일로 벤치마크에 따르면 '저성과'인데, 실제로 문제가 있는 건가요?"라고 말합니다. 또 다른 리더는 "우리 팀 중 일부가 다른 팀보다 배포 빈도가 낮다는 것은 그럴 수 있는 일이고 이것이 개선할 문제인지 잘 모르겠습니다."라고 말합니다.
이 이야기가 낯설게 느껴지더라도 걱정하지 마세요. 세계 최대 규모의 기술 기업을 포함한 대부분의 기업에게 익숙한 이야기이기 때문입니다. DORA와 같은 측정 지표가 리더가 기대했던 인사이트를 제공하지 못할 때 측정 프로그램이 실패하는 경우는 드물지 않습니다.
하지만 더 나은 접근 방식이 있습니다. 속도와 결과물이라는 기본적인 측정에만 의존하지 않고 개발자 스스로 인사이트를 포착하는 데 중점을 두는 접근 방식입니다. 저희는 많은 조직이 이러한 사람 중심의 접근 방식으로 전환하도록 지원해 왔습니다. 그리고 이를 통해 개발자의 생산성에 대한 이해가 극적으로 향상되는 것을 직접 확인했습니다.
여기서 말하는 것은 정성적 측정입니다. 이 글에서는 이 여정에서 많은 조직을 지원한 경험에서 얻은 이 접근법에 대한 입문서를 제공합니다. 먼저 정성적 측정지표의 정의와 이를 옹호하는 방법부터 설명합니다. 이어서 이러한 데이터를 캡처, 추적 및 활용하는 방법에 대한 실용적인 지침을 제공합니다.
오늘날 개발자 생산성 은 재정 긴축과 AI와 같은 혁신적 기술을 배경으로 하는 비즈니스의 중요한 관심사입니다. 또한 기업이 애자일과 데브옵스 전환을 넘어서는 혁신을 모색하면서 개발자 경험과 플랫폼 엔지니어링에 대한 관심도 높아지고 있습니다. 이러한 모든 관심사의 공통점은 의사 결정을 안내하고 진행 상황을 추적하는 데 도움이 되는 측정에 의존한다는 것입니다. 이를 위해서는 정성적 측정이 핵심입니다.
참고: 개발자 생산성 이란 개발자의 개별 성과가 아니라 개발자가 원활하게 업무를 수행할 수 있는 정도를 의미합니다. 일부 조직에서는 '개발자 생산성'이라는 용어가 개발자에게 잘못 해석될 수 있기 때문에 문제가 되는 용어라고 생각합니다. 조직에서는 개발자에게 더 긍정적인 의미가 담긴 '개발자 경험'이라는 용어를 사용하는 것이 좋습니다.
정성적 메트릭이란 무엇인가요?
"메트릭"이라는 단어의 정의는 모호하지 않습니다. 그러나 '정성적'이라는 용어는 2019년 저널 논문인 ' 정성적 연구에서 정성적이란 무엇인가'에서 언급했듯이 권위 있는 정의가 없습니다:
질적 연구에 대한 정의는 여러 가지가 있지만, '질적'이라는 특징을 다루는 정의를 찾다 보면 광범위한 사회과학 분야 전반에 걸친 문헌이 빈약합니다. 이 글의 주된 이유는 연구자들이 질적 연구가 무엇인지 알고 있는 것처럼 행동하지만 일관된 정의를 내릴 수 없다는 역설에 있습니다.
우리가 들어본 또 다른 정의는 정성적 지표는 품질을 측정하는 반면, 정량적 지표는 양을 측정한다는 것입니다. 이 정의는 두 가지 이유로 문제가 있습니다. 첫째, '정성적 지표'라는 용어에는 산출물이 수량 (즉, 측정값)임을 의미하는 메트릭이라는 용어가 포함되어 있습니다. 둘째, 품질은 일반적으로 수치와 점수로 변환되는 서수 척도를 통해 측정되는데, 이 역시 정의와 모순됩니다.
감성 분석(sentiment analysis)의 결과는 숫자로 나타나기 때문에 정량적이라는 또 다른 주장도 있습니다. 감성 분석의 결과 데이터가 정량적이라는 것에는 동의하지만, '정성적 지표'가 완전히 모순이라는 입장을 취하지 않는 한 원래의 정의에 따르면 이는 여전히 정성적 지표 (즉, 정성적으로 산출된 양)입니다.
정성적 지표가 무엇인지 정의하는 문제 외에도 문제가 되는 구어체도 발견되었습니다. 한 가지 예로 '소프트 메트릭'이라는 용어가 있습니다. 이 표현은 사람에게서 수집한 데이터가 시스템에서 수집한 '하드 메트릭'보다 약하다는 해롭고 잘못된 의미를 내포하고 있기 때문에 이 표현을 사용하지 않도록 주의합니다. 또한 "주관적 지표"라는 용어는 다음 섹션에서 설명하듯이 사람으로부터 수집한 데이터가 객관적일 수도 있고 주관적일 수도 있다는 사실을 오해할 수 있으므로 사용하지 않는 것이 좋습니다.
이 문서의 뒷부분에서 이러한 측정치를 수집하고 사용하는 방법에 대한 지침을 제공하지만, 먼저 이 접근 방식이 실제로 적용된 실제 사례를 소개하겠습니다.
펠로톤은 정성적 메트릭을 중심으로 개발자 생산성 측정 전략을 펼치는 미국의 기술 회사입니다. 이 회사는 정성적 지표를 수집하기 위해 제품 운영 조직의 일부인 기술 지원 및 개발자 경험 팀이 주도하는 반기별 개발자 경험 설문조사를 실시합니다.
기술 학습 및 인사이트 책임자인 탄샤 사다차람은 다음과 같이 설명합니다: "저는 엔지니어는 로봇이 아니라 인간이라는 사실을 매우 굳게 믿고 있으며, 많은 엔지니어들도 이를 인정하고 있다고 생각합니다. 그리고 기본적인 수치만으로는 모든 것을 파악할 수 없습니다. 그래서 저희는 전체 개발자 경험을 이해하는 데 도움이 되는 포괄적인 설문조사를 실시하는 것이 정말 중요했습니다."
각 설문조사는 개발자의 약 절반에 해당하는 무작위 표본에게 전송됩니다. 이러한 접근 방식을 사용하면 개별 개발자는 1년에 한 번만 설문조사에 참여하면 되므로 설문조사 작성에 소요되는 전체 시간을 최소화하면서도 통계적으로 유의미한 대표 데이터 결과를 얻을 수 있습니다. 또한 기술 지원 및 개발자 경험 팀은 설문조사 결과를 분석하고 조직 전체의 리더와 공유하는 역할을 담당합니다.
펠로톤의 개발자 경험 설문조사에 대한 자세한 내용은 탄샤 사다차람과의 인터뷰를 들어보세요.
정성적 메트릭 옹호
경영진은 정성적 지표의 신뢰성이나 유용성에 대해 회의적인 경우가 많습니다. Google과 같이 고도로 과학적인 조직도 이러한 편견을 극복해야 했습니다. 엔지니어링 리더들은 시스템 점검을 위한 원격 측정 데이터 작업에 익숙하기 때문에 시스템 메트릭을 선호하는 경향이 있습니다. 하지만 사람을 측정할 때는 이와 같은 접근 방식에 의존해서는 안 됩니다.
정성적 지표와 정량적 지표를 서로 비교하는 것은 피해야 합니다.
일부 조직에서는 내부적으로 '지표 싸움'을 벌이는 경우가 있는데, 이는 시간이나 에너지를 낭비하는 일입니다. 한가지 조언을 드리자면, 정성적 지표와 정량적 지표를 양자택일 식으로 서로 대립시키지 말라는 것입니다. 이 글의 마지막 부분에서 다루겠지만, 정성적 지표와 정량적 지표는 상호 보완적인 도구라고 주장하는 것이 더 좋습니다.
정성적 데이터에 대한 반대의 근본적인 원인은 아래에서 설명하는 오해에서 비롯된다는 사실을 발견했습니다. 이 글의 뒷부분에서는 무형의 데이터를 측정하고 중요한 맥락을 드러내는 능력과 같은 자체 보고 데이터(self-reported data)의 뚜렷한 이점에 대해 간략하게 설명합니다.
오해: 정성적 데이터는 주관적일 뿐이다
기존의 직장 설문조사는 일반적으로 직원의 주관적인 의견과 느낌에 초점을 맞춥니다. 따라서 많은 엔지니어링 리더는 설문조사를 통해 개발자의 주관적인 데이터만 수집할 수 있다고 직관적으로 생각합니다.
다음 섹션에서 설명하겠지만 설문조사는 사실이나 사건에 대한 객관적인 정보도 수집할 수 있습니다. Google의 DevOps 연구 및 평가(DORA) 프로그램이 훌륭한 구체적인 예입니다.
객관적인 설문조사 질문의 몇 가지 예
- 커밋된 코드에서 프로덕션 환경에서 성공적으로 실행되는 코드가 되기까지 얼마나 걸리나요?
- 조직에서 코드를 프로덕션에 배포하거나 최종 사용자에게 릴리스하는 빈도는 얼마나 되나요?
오해: 정성적 데이터는 신뢰할 수 없다
설문조사의 한 가지 문제점은 다양한 배경을 가진 사람들이 특별한 교육 없이 설문조사 질문을 작성한다는 것입니다. 그 결과, 많은 직장 설문조사가 신뢰할 수 있거나 유효한 측정값을 산출하는 데 필요한 최소한의 기준을 충족하지 못합니다. 하지만 잘 설계된 설문조사는 정확하고 신뢰할 수 있는 데이터를 생성합니다(설문조사 작성 방법에 대한 지침은 이 글의 뒷부분에서 확인할 수 있습니다).
일부 조직에서는 사람들이 설문조사에서 거짓말을 할 수 있다는 우려를 가지고 있습니다. 이는 데이터가 어떻게 사용될지에 대한 두려움이 있는 상황에서 발생할 수 있습니다. 경험상 설문조사가 개발자에게 영향을 미치는 병목 현상을 이해하고 개선하는 데 도움이 되는 도구로 배포되는 경우 응답자가 거짓말을 하거나 시스템을 조작할 유인은 없습니다.
설문조사 데이터가 항상 100% 정확한 것은 아니지만, 저희는 종종 리더들에게 시스템 지표도 불완전한 경우가 많다는 점을 상기시킵니다. 예를 들어, 많은 조직에서 파이프라인에서 집계된 데이터를 사용하여 CI 빌드 시간을 측정하려고 시도하지만 정확한 결과를 얻기 위해서는 데이터를 정리하는 데 상당한 노력(예: 백그라운드 작업 제외, 병렬 작업 고려)이 필요하다는 사실을 알게 됩니다.
두 가지 유형의 정성적 메트릭
정성적 지표에는 두 가지 주요 유형이 있습니다:
- 태도 측정지표는 특정 주제에 대한 주관적인 감정, 의견 또는 태도를 포착합니다. 태도 측정지표의 예로는 질문에 대한 응답으로 캡처된 숫자 값을 들 수 있습니다: "1~10점 척도에서 IDE에 얼마나 만족하십니까?"라는 질문에 대한 응답으로 캡처한 수치입니다.
- 행동 측정지표는 개인의 업무 경험과 관련된 객관적인 사실이나 사건을 포착합니다. 행동 측정 항목의 예로는 다음 질문에 대한 응답으로 포착된 갯수를 들 수 있습니다: "변경 사항을 프로덕션에 배포하는 데 얼마나 걸리나요?"
대부분의 기술 실무자가 정성적 지표를 고려할 때 행동 측정을 간과한다는 사실을 발견했습니다. 이는 앞서 언급한 Google의 DORA 프로그램과 같이 소프트웨어 연구에서 정성적 행동 측정이 널리 사용되고 있음에도 불구하고 발생하는 문제입니다.
DORA는 변경 리드 타임, 배포 빈도, 변경 실패율과 같은 메트릭에 대한 연간 벤치마크를 발표합니다. 많은 사람들에게 알려지지 않은 사실이지만, DORA의 벤치마크는 아래와 같은 설문조사 항목을 통해 정성적 방법을 사용하여 측정됩니다:
리드 타임
작업 중인 주요 애플리케이션 또는 서비스의 변경 리드 타임(즉, 커밋된 코드에서 프로덕션에서 성공적으로 실행되는 코드가 되기까지 걸리는 시간)은 얼마나 되나요?
- 6개월 이상
- 1개월~6개월
- 1주일에서 1개월
- 하루~1주일
- 하루 미만
- 1시간 미만
배포 빈도
작업하는 주요 애플리케이션 또는 서비스의 경우 조직에서 코드를 프로덕션 환경에 배포하거나 최종 사용자에게 릴리스하는 빈도는 얼마나 되나요?
- 6개월에 한 번 미만
- 한 달에 한 번에서 6개월에 한 번 사이
- 일주일에 한 번에서 한 달에 한 번 사이
- 하루에 한 번에서 일주일에 한 번 사이
- 시간당 한 번에서 하루에 한 번 사이
- 온디맨드(하루에 여러 번 배포)
변경 실패 비율
작업 중인 주요 애플리케이션 또는 서비스의 경우 프로덕션 또는 사용자 릴리스에 대한 변경으로 인해 서비스가 저하되고(예: 서비스 장애 또는 서비스 중단으로 이어짐) 이후에 수정이 필요한(예: 핫픽스, 롤백, 수정 포워드, 패치 필요) 비율은 몇 퍼센트인가요?
- 0-15%
- 16-30%
- 31-45%
- 46-60%
- 61-75%
- 76-100%
복원하는 데 걸리는 시간
작업하는 주요 애플리케이션 또는 서비스의 경우 사용자에게 영향을 미치는 서비스 사고 또는 결함(예: 계획되지 않은 중단, 서비스 장애)이 발생했을 때 서비스를 복원하는 데 일반적으로 얼마나 걸리나요?
- 6개월 이상
- 1주~6개월
- 1주일에서 1개월
- 1일~1주일
- 하루 미만
- 1시간 미만
태도 데이터와 행동 데이터를 동시에 수집할 수 있다는 것은 정성적 측정의 강력한 이점입니다.
예를 들어, 행동 데이터는 릴리스 프로세스가 빠르고 효율적이라는 것을 보여줄 수 있습니다. 그러나 태도 데이터만으로는 개발자의 번아웃과 리텐션에 중요한 영향을 미치는 원활하고 고통이 없는지 여부를 알 수 있습니다.
비기술적인 비유를 들어 설명하자면, 몸이 아파서 병원을 방문했다고 상상해 보세요. 의사가 혈압, 체온, 심박수를 측정한 후 "다 괜찮은 것 같네요. 아무 이상이 없습니다."라고 말합니다. 여러분은 깜짝 놀랄 것입니다! "잠깐만요, 뭔가 잘못된 것 같은데요."라고 말할 것입니다.
정성적 지표의 장점
정성적 메트릭의 장점 중 하나는 개발자가 경영진으로부터 '측정당하고 있다'는 느낌을 받지 않는다는 것입니다. 이는 특히 개발자의 Git 또는 Jira 데이터에서 파생된 메트릭과 비교할 때 사실이지만, 정성적 접근 방식이 제공할 수 있는 주요 객관적인 이점을 다루지는 않습니다.
개발자의 생산성을 측정할 때 정 성적 메트릭의 세 가지 주요 이점이 있습니다:
정성적 메트릭을 사용하면 다른 방법으로는 측정할 수 없는 것들을 측정할 수 있습니다.
리드 타임 및 배포량과 같은 시스템 메트릭은 파이프라인이나 티켓팅 시스템에서 일어나는 일을 포착합니다. 하지만 생산성 향상을 위해 개발자의 업무에는 개발자가 흐름에 맞춰 작업하거나 코드베이스를 쉽게 탐색할 수 있는지 여부와 같이 이해해야 할 더 많은 측면이 있습니다. 정성적 지표를 사용하면 측정하기 어렵거나 불가능한 이러한 무형의 요소를 측정할 수 있습니다.
이에 대한 흥미로운 예로 기술 부채를 들 수 있습니다. Google에서는 기술 부채에 대한 지표를 파악하기 위한 연구에서 잠재적 지표로 제안된 117개의 지표를 분석했습니다. Google 연구원들은 실망스럽게도 단일 지표 또는 지표의 조합이 유효한 지표로 밝혀지지 않았습니다(Google의 기술 부채 측정 방법에 대한 자세한 내용은 이 인터뷰를 들어보세요).
아직 발견되지 않은 기술 부채에 대한 객관적인 지표가 존재할 수도 있지만, 기술 부채의 평가는 시스템이나 코드베이스의 현재 상태와 상상된 이상적인 상태를 비교하는 데 의존하기 때문에 불가능할 수도 있다고 생각할 수 있습니다. 즉, 사람의 판단이 필수적입니다.
정성적 메트릭은 팀과 시스템 전반에서 누락된 가시성을 제공합니다.
티켓팅 시스템과 파이프라인의 메트릭은 개발자가 수행하는 일부 작업에 대한 가시성을 제공합니다. 하지만 이러한 데이터만으로는 전체 스토리를 파악할 수 없습니다. 개발자는 티켓이나 빌드에 캡처되지 않는 많은 작업을 수행합니다. 예를 들어 주요 기능을 디자인하거나 프로젝트의 방향을 정하거나 팀원의 온보딩을 돕는 등의 작업을 수행합니다.
시스템 데이터만으로는 이러한 모든 활동에 대한 가시성을 확보하는 것이 불가능합니다. 이론적으로 시스템을 통해 모든 데이터를 수집할 수 있다고 해도 계측을 통해 메트릭을 캡처하는 데는 또 다른 어려움이 있습니다.
한 가지 예로 서로 다른 팀 워크플로우에서 지표를 표준화하는 것이 어렵다는 점을 들 수 있습니다. 예를 들어 작업의 시작부터 완료까지 걸리는 시간을 측정하려는 경우 티켓팅 툴에서 이 데이터를 얻으려고 할 수 있습니다. 하지만 각 팀마다 워크플로우가 서로 달라 정확한 지표를 생성하기 어려운 경우가 많습니다. 반대로 개발자에게 일반적으로 작업에 걸리는 시간을 물어보는 것이 훨씬 더 간단할 수 있습니다.
또 다른 일반적인 문제는 시스템 간 가시성입니다. 예를 들어, 소규모 스타트업의 경우 Jira와 같은 이슈 트래커만 사용하여 TTR(복원 시간)을 측정할 수 있습니다. 하지만 대규모 조직은 엔드투엔드 시스템 가시성을 확보하기 위해 계획 시스템 및 배포 파이프라인 전반에서 데이터를 통합하고 교차 어트리뷰션해야 할 가능성이 높습니다. 이 작업에는 1년이 걸릴 수 있지만, 개발자로부터 이러한 데이터를 캡처하면 빠르게 기준선을 제공할 수 있습니다.
정량적 데이터에 대한 컨텍스트를 제공하는 정성적 메트릭
기술자는 정량적 측정에 집중하기 쉽습니다. 결국 정량적 지표는 깨끗하고 명확해 보이니까요. 그러나 더 풍부한 데이터가 없으면 전체 이야기를 전달하지 못하고 엉뚱한 것에 집중하게 될 위험이 있습니다.
한 가지 예로 코드 검토를 들 수 있습니다. 일반적인 최적화는 코드 검토 속도를 높이는 것입니다. 코드 검토를 기다리면 시간 낭비나 원치 않는 컨텍스트 전환이 발생할 수 있으므로 이는 논리적으로 보입니다. 검토가 완료되는 데 걸리는 시간을 측정하여 팀이 이를 개선하도록 인센티브를 제공할 수도 있습니다. 하지만 이러한 접근 방식은 리뷰를 서두르는 리뷰어나 리뷰를 수행할 적절한 전문가를 찾지 못하는 개발자와 같은 부정적인 행동을 조장할 수 있습니다.
코드 리뷰는 고품질의 소프트웨어가 제공되도록 하는 중요한 목적을 위해 존재합니다. 속도보다는 프로세스의 결과에 초점을 맞춰 보다 전체적인 분석을 수행하면 코드 검토를 최적화하여 우수한 코드 품질, 보안 위험 완화, 팀원 간의 공유 지식 구축은 물론 동료가 기다리지 않도록 보장해야 한다는 것을 알 수 있습니다. 정성적 측정은 이러한 결과가 충족되고 있는지 평가하는 데 도움이 될 수 있습니다.
또 다른 예는 개발자 온보딩 프로세스입니다. 소프트웨어 개발은 팀 활동입니다. 따라서 신규 개발자가 커밋하는 비율이나 첫 커밋 시간 등 개별 결과 지표만 측정하면 개발자가 가져온 아이디어를 충분히 활용하고 있는지, 개발자가 안심하고 질문할 수 있는지, 다른 부서 동료와 협업하고 있는지 등 중요한 결과를 놓칠 수 있습니다.
정성적 지표를 캡처하는 방법
많은 기술 실무자들은 좋은 설문조사 질문을 작성하고 좋은 설문조사 도구를 설계하는 것이 얼마나 어려운 일인지 깨닫지 못합니다. 실제로 심리측정학이나 산업심리학 등 이와 관련된 연구 분야가 존재합니다. 가능하면 여기에 전문 지식을 가져오거나 구축하는 것이 중요합니다.
다음은 조직에서 가장 흔히 저지르는 실수를 피하기 위한 설문조사 작성에 대한 몇 가지 좋은 규칙입니다:
- 설문조사 항목은 신중하게 작성해야 하며 모든 질문은 한 가지 질문만 해야 합니다.
- 설문조사 간의 결과를 비교하려는 경우, 질문의 문구를 변경하여 다른 것을 측정하는 것처럼 보이도록 주의해야 합니다.
- 문구를 변경하는 경우 엄격한 통계 테스트를 수행해야 합니다.
설문조사 전문 용어로 "좋은 설문조사"란 "타당성과 신뢰성" 또는 "좋은 심리측정 특성을 보여주는 것"을 의미합니다. 타당도는 설문조사 항목이 측정하고자 하는 구성을 실제로 측정하는 정도입니다. 신뢰도는 설문조사 항목이 모집단에서 그리고 시간이 지나도 일관된 결과를 산출하는 정도입니다.
기술 실무자에게 도움이 되는 설문조사 설계에 대한 한 가지 사고 방식은 설문조사 응답 과정을 사람의 마음속에서 일어나는 알고리즘으로 생각하면 됩니다.
개인에게 설문조사 질문이 제시되면 응답에 도달하기 위해 일련의 정신적 단계가 진행됩니다. 아래 모델은 2012년 출간된 저서 '설문조사 응답의 심리학'에서 가져온 것입니다:
설문조사 응답 프로세스를 세분화하고 각 단계를 점검하면 보다 정확한 설문조사 결과를 도출하기 위해 입력을 세분화할 수 있습니다. 좋은 설문조사 항목을 개발하려면 소프트웨어를 설계하는 과정과 마찬가지로 엄격한 설계, 테스트 및 분석이 필요합니다!
하지만 좋은 설문조사 디자인은 성공적인 설문조사 운영의 한 측면에 불과합니다. 참여율, 데이터 분석, 데이터에 대한 조치 방법 파악 등 추가적인 과제가 있습니다. 다음은 저희가 배운 몇 가지 모범 사례입니다.
팀 및 페르소나별로 결과 세분화하기
조직 리더들이 흔히 저지르는 실수는 팀과 페르소나(예: 역할, 근속 기간, 연차)별로 세분화된 데이터 대신 회사 전체의 결과에 집중하는 것입니다. 앞서 설명했듯이 개발자 경험은 상황에 따라 크게 달라지며 팀이나 역할에 따라 크게 다를 수 있습니다. 집계된 결과에만 초점을 맞추면 모바일 개발자와 같이 회사 내에서 작지만 중요한 집단에 영향을 미치는 문제를 간과할 수 있습니다.
자유롭게 쓰는 댓글이 가장 가치 있는 경우가 많습니다
지금까지 정성적 지표에 대해 이야기했지만, 자유 텍스트 댓글은 매우 가치 있는 정성적 데이터의 한 형태입니다. 개발자는 마찰이나 워크플로우를 설명하는 것 외에도 개발자 경험을 개선할 수 있는 많은 훌륭한 아이디어를 가지고 있을 것이며, 자유 텍스트를 통해 이를 포착하고 후속 조치를 취할 대상을 파악할 수 있습니다. 또한 자유 텍스트 댓글은 설문조사에서 다루지 않은 부분을 드러낼 수 있으며, 향후 추가할 수도 있습니다.
벤치마크와 결과 비교
비교 분석은 데이터의 맥락을 파악하고 행동을 유도하는 데 도움이 될 수 있습니다. 예를 들어, 코드 품질에 대한 개발자의 감정은 일반적으로 부정적으로 왜곡되어 실제 문제를 식별하거나 그 정도를 측정하기 어렵습니다. 실행 가능한 데이터 포인트가 많을수록 "우리 개발자들이 다른 팀이나 조직보다 코드 품질에 대해 더 불만이 많은가?"입니다. 동료보다 감정 점수가 낮은 팀과 업계 동료보다 점수가 낮은 조직은 주목할 만한 개선 기회를 발견할 수 있습니다.
적절한 경우 트랜잭션 설문조사 사용
트랜잭션 설문조사는 개발자 워크플로우의 특정 접점이나 상호작용 중에 피드백을 수집합니다. 예를 들어, 플랫폼 팀은 내부 개발자 포털에서 새 서비스를 만드는 동안 트랜잭션 설문조사를 사용하여 개발자에게 피드백을 요청할 수 있습니다. 또한 트랜잭션 설문조사는 더 높은 빈도의 피드백과 더 세분화된 인사이트를 생성하여 정기 설문조사의 데이터를 보강할 수 있습니다.
설문조사 피로 방지
많은 조직이 시간이 지나도 설문조사에 높은 참여율을 유지하는 데 어려움을 겪고 있습니다. 후속 조치가 부족하면 개발자가 설문조사에 반복적으로 응답하는 것이 가치가 없다고 느낄 수 있습니다. 따라서 리더와 팀은 설문조사 후 후속 조치를 취하고 의미 있는 조치를 취하는 것이 중요합니다. 대부분의 조직에서는 분기별 또는 반기별 설문조사 주기가 가장 적합하지만, 일부 조직에서는 회고와 같은 정기적인 팀 의식에 설문조사를 통합하여 더 자주 실시하는 것이 성공적이라는 것을 확인했습니다.
설문조사 템플릿
다음은 설문조사를 시작하기 위한 간단한 설문조사 질문 모음입니다. 아래 질문을 선호하는 설문조사 도구에 로드하거나 바로 사용할 수 있는 Google 설문조사 템플릿을 복사하여 빠르게 시작하세요.
템플릿은 의도적으로 간단하지만 측정 전략이 성숙해지면 설문조사의 규모가 상당히 커지는 경우가 많습니다. 예를 들어, Shopify의 개발자 설문 조사는 20분 길이이며 Google 설문조사는 30분이 넘습니다.
응답을 수집한 후에는 평균 또는 최고 상자 점수를 사용하여 객관식 문제에 점수를 매깁니다. 평균 점수는 각 옵션에 1에서 5 사이의 값을 할당하고 그 평균을 구하여 계산합니다. 최고 상자 점수는 가장 선호도가 높은 상위 두 옵션 중 하나를 선택한 응답의 백분율로 계산됩니다.
훌륭한 정보를 포함할 수 있는 공개 텍스트 응답을 반드시 검토하세요. 많은 수의 댓글을 수집한 경우 ChatGPT와 같은 LLM 도구를 사용하여 핵심 주제와 제안을 추출하는 데 유용할 수 있습니다. 결과 분석이 끝나면 응답자들이 설문조사에 참여한 시간을 가치 있게 느낄 수 있도록 결과를 응답자들과 공유하세요.
[조직 이름 삽입]에서 개발자 또는 기술 기여자로서 업무를 수행하는 것이 얼마나 쉽거나 어려운가요?
- 매우 어려움
- 다소 어려움
- 쉽지도 어렵지도 않음
- 다소 쉬움
- 매우 쉬움
작업하는 주요 애플리케이션 또는 서비스의 경우 변경에 소요되는 리드 타임(즉, 커밋된 코드에서 프로덕션에서 성공적으로 실행되는 코드가 되기까지 걸리는 시간)은 얼마나 되나요?
- 한 달 이상
- 1주일에서 1개월
- 하루~1주일
- 하루 미만
- 1시간 미만
업무 생산성이 높다고 느끼는 빈도는 얼마나 자주인가요?
- 전혀
- 조금 자주
- 어느 정도
- 대부분의 시간
- 항상
다음 문항에 대한 동의 또는 비동의 여부를 표시해 주세요:
Strongly disagree Disagree Neutral Agree Strongly agree 우리 팀은 개발 모범 사례를 따릅니다. □ □ □ □ □ 깊이 있는 작업을 할 시간이 충분합니다. □ □ □ □ □ 프로젝트의 자동화된 테스트 커버리지에 만족 합니다. □ □ □ □ □ 프로덕션 환경에 쉽게 배포할 수 있습니다. □ □ □ □ □ CI/CD 도구의 품질에 만족합니다. □ □ □ □ □ 우리 팀의 코드베이스는 제가 쉽게 기여할 수 있습니다. □ □ □ □ □ 우리 팀의 기술 부채 규모는 목표에 따라 적절 합니다. □ □ □ □ □ 요구사항은 사용자 신호에 따라 지속적으로 재검토 되고 우선순위가 재조정됩니다. □ □ □ □ □ 개발자 경험을 개선할 수 있는 방법에 대한 추가 피드백을 공유해 주세요.
[텍스트 영역 열기]
정성적 지표와 정량적 지표를 함께 사용하기
정성적 지표와 정량적 지표는 개발자 생산성 을 측정하기 위한 상호 보완적인 접근 방식입니다. 설문조사에서 파생된 정성적 메트릭은 주관적 측정과 객관적 측정을 모두 포함하는 생산성에 대한 전체적인 관점을 제공합니다. 반면에 정량적 지표는 뚜렷한 장점을 제공합니다:
- 정확성. 사람은 CI/CD 빌드가 일반적으로 빠른지 느린지(즉, 소요 시간이 1분인지 1시간에 가까운지) 알 수 있지만 빌드 시간을 밀리초 단위까지 정확하게 보고할 수는 없습니다. 정량적 지표는 측정에 높은 수준의 정밀도가 필요할 때 필요합니다.
- 연속성. 일반적으로 조직에서 개발자를 설문조사할 수 있는 빈도는 분기당 최대 한두 번입니다. 더 자주 또는 지속적으로 지표를 수집하려면 조직은 데이터를 체계적으로 수집해야 합니다.
궁극적으로 조직은 정성적 지표와 정량적 지표를 결합한 혼합 방법 접근 방식을 통해 개발자의 생산성과 경험에 대한 가시성을 최대한 확보할 수 있습니다. 그렇다면 정성적 지표와 정량적 지표를 함께 사용하는 방법은 무엇일까요?
정성적 메트릭으로 시작하여 기준선을 설정하고 어디에 집중해야 할지 결정할 때 조직이 성공을 거두는 것을 보았습니다. 그런 다음 정량적 지표를 사용하여 특정 영역을 더 자세히 분석할 수 있습니다.
엔지니어링 리더들은 정성적 메트릭이 전체적인 관점과 맥락을 제공하여 잠재적인 기회를 폭넓게 이해할 수 있기 때문에 이 접근 방식이 효과적이라고 생각합니다. 반면에 정량적 지표는 일반적으로 소프트웨어 제공 프로세스의 좁은 범위에서만 사용할 수 있습니다.
이러한 이유로 Google은 엔지니어링 리더에게 로그 데이터를 보기 전에 설문조사 데이터를 먼저 살펴보라고 조언합니다. Google 엔지니어링 연구원 Ciera Jaspan은 다음과 같이 설명합니다: "로그 데이터만 보면 어떤 것이 좋은지 나쁜지 알 수 없으므로 리더에게 설문조사 데이터를 먼저 살펴보라고 권장합니다. 예를 들어, 변경에 걸리는 시간을 추적하는 메트릭이 있지만 그 자체로는 쓸모가 없습니다. 이것이 좋은 일인가요? 나쁜 건가요? 문제가 있는 건 아닐까?"라는 질문을 던져야 합니다.
혼합 방법 접근 방식을 사용하면 정성적 지표와 정량적 지표의 이점을 모두 활용하면서 개발자 생산성 을 완전히 이해할 수 있습니다:
- 정성적 데이터로 시작하여 최고의 기회 파악하기
- 개선해야 할 부분을 파악한 후에는 정량적 지표를 사용하여 더 자세히 파고드세요.
- 정성적 및 정량적 지표를 모두 사용하여 진행 상황을 추적하세요.
조직은 정성적, 정량적 데이터를 최대한 많이 결합해야만 개발자 생산성 에 대한 완전한 이해를 구축할 수 있습니다.
하지만 결국 조직은 로그 기반 메트릭으로는 파악할 수 없는 문제를 관찰하고 감지할 수 있는 우수한 인력에 많은 비용을 지출한다는 점을 기억해야 합니다. 개발자의 생각과 목소리를 활용함으로써 조직은 이전에는 불가능하다고 여겨졌던 인사이트를 얻을 수 있습니다.