GN⁺: 내가 아는 최악의 프로그래머 (2023)
(dannorth.net)- 이 글은 팀의 생산성을 측정하려는 시도가 어떻게 실패했는지 설명함
- 개인 평가 및 개발 목적으로 개인 성과 지표 도입을 결정
- 코드 라인 수나 버그 수는 조작 가능성이 높아 배제하고, 대신 스토리 포인트 또는 전달된 스토리 수로 성과를 측정하기로 함
Tim Mackinnon의 성과는 ‘0’
- 팀의 생산성 측정 도구(Jira 등)를 통해 모든 팀원의 성과를 측정
- Tim의 성과 점수는 0 → 스토리 포인트를 하나도 기록하지 않았기 때문
- 매니저는 Tim의 성과가 0이므로 Tim을 교체할 것을 요구
Tim Mackinnon이 성과를 내지 못한 이유
- Tim은 스토리를 직접 담당하지 않았음
- 대신 팀원들과 페어 프로그래밍에 집중
- 경험이 적은 개발자와 함께 작업하며 문제 해결을 유도
- 직접 해결하지 않고 질문을 통해 해결책 도출을 도와줌
- 시니어 개발자와는 문제를 함께 고민하고 해결책 개선
- Tim은 직접 코드를 작성하지 않았지만 팀의 전반적인 성과를 향상시킴
Tim Mackinnon의 진정한 기여
- Tim의 기여는 개인 성과 점수로 측정할 수 없음
- Tim 덕분에 팀 전체의 생산성 및 코드 품질이 향상됨
- Tim이 함께 작업하면 더 빠르고, 더 좋은 결과를 얻을 수 있었음
팀 생산성으로 평가 방식 변경
- 매니저에게 Tim의 기여도를 설명하고 관찰 기회를 제공
- 팀 전체의 성과가 향상됨을 확인한 후 개별 성과 측정 방식을 포기
- 개인 성과가 아닌 팀 성과 및 비즈니스 영향으로 평가 방식 전환
요약 (tl;dr)
- 생산성을 비즈니스 성과(예: 비용 절감, 수익 창출 등)로 측정해야 함
- 복잡한 시스템에서 개별 성과 측정은 의미 없음
- DORA Metrics 등은 시스템 성과를 측정하는 도구이지 개별 기여도 측정 도구가 아님
- Tim Mackinnon과 함께 일할 기회가 있다면 놓치지 말 것
테크 리드로 이러한 작업을 꽤 많이하고 있습니다. 스토리 포인트 기반 정량화를 시도하는 것도 비슷한데, 다행히 회사가 크지 않아서 임원을 비롯한 구성원들이 제가 어떤 역할을 하는지 인지를 해주고 계셔서 당장은 문제가 발생하지 않는 것 같네요.
조직이 커지면 정량화 방법도 고민을 해봐야겠네요.
어디서 본 이야기다 싶었는데..2023년 글이군요
2년전에 동일한 글이 올라왔었네요 https://news.hada.io/topic?id=10680
사실 시니어를 넘어서 스태프 엔지니어 쯤 가면, 점점 필드에 배포 되는 코드와는 점점 멀어지고.... 대신 시니어/주니어 대상으로 코칭을 더 많이 하게 되는 것 같습니다. 매니저들 하소연도 들어줘야 되고.... 문제 터지면 여기저기 불려가서 솔루션 제시해야 하고....
하는 일이 이런 식인데 지라 티겟과 점수도 정량화하는게 불가능하죠.
Hacker News 의견
-
개인 개발자의 생산성을 측정하는 것은 터무니없음. 코드 라인이나 스토리 포인트 측정은 생산성의 반대임. 개발자가 더 적은 코드로 더 많은 가치를 창출하는 것이 중요함
- 비즈니스 결과를 측정하는 것이 중요하지만 특정 개발자에게 귀속시키기 어려움
- 결국 주관적인 판단에 의존할 수밖에 없음을 인정하는 것이 더 나음
-
Tim의 이름을 티켓에 붙여 문제를 해결하는 방법을 발견함. 팀원들이 기꺼이 도와줄 것임
- 생산성 지표가 완전히 무가치한 것은 아님. 팀 내에서 PR과 Jira 티켓의 비율을 보면 팀 리더를 추측할 수 있음
-
Tim이 팀에 남아있고 프로세스를 올바른 방향으로 이끌어 기쁨. 경청하는 관리자가 필요함
- OKR로 인해 개발자들이 고립됨. 팀 기반이 아닌 개인 기반의 OKR은 문제를 초래함
- 문제 해결에 시간이 오래 걸림. OKR 때문에 도움을 받을 수 없었음
-
한 프로그래머가 개인 작업 없이 모든 도움을 주는 모델은 이상함
- Tim이 다른 사람들과 같이 스토리를 수행하고, 도움이 필요할 때 그룹에 요청하는 것이 더 건강한 상황임
- 팀이 매우 불균형하다면 Tim은 멘토 역할을 해야 함
-
Tim이 개인 작업을 하지 않는 것이 이상함. 팀 생산성을 극대화하려면 개인 기여와 팀 협업의 균형이 필요함
- Tim이 너무 인내심이 많아 시간을 낭비했을 수 있음
-
Tim이 팀에 기여하지 않으면 일을 시작하고 스토리를 전달하라고 할 것임. Tim이 다른 사람을 도와주는 것은 좋지만, 자신의 작업도 해야 함
-
모든 것이 그룹 활동이 될 필요는 없음. 평균적인 개발자가 Tim의 지속적인 도움 없이 기능을 제공할 수 없다면 팀에 문제가 있음
- 소프트웨어 개발은 개인 작업과 그룹 작업 모두에 시간이 필요함
-
최고의 팀은 항상 Tim과 같은 사람이 있음. Tim의 도움은 다른 사람들에게 전파되어 팀 전체가 성장함
- 개발자가 막히면 스스로 해결하려고 노력하고, 필요한 경우 도움을 요청함
-
스토리 포인트로 개발자 생산성을 측정하는 것은 좋지 않음. Zero라는 개발자는 스토리를 할당받지 않고 팀을 도왔음
- 관리자는 Zero의 중요성을 이해하고 있었음. Zero가 없을 때 중요한 릴리스를 미루기도 했음
-
지원의 가치를 정량화하는 것은 어려움. 하지만 지원은 필수적임. 리더들이 올바르게 판단할 수 있도록 신뢰해야 함