소프트웨어 개발자들의 생산성 인식

Software Developer’s Perceptions

원제: Software Developer’s Perceptions of Productivity

지인이 올린 논문 하나를 보고 요약해봐야겠다고 생각했다. 찾아보니 이전 논문이 딸려나왔다. 그래서 알게된 점. 논문은 총 두 편이고, 지인이 공유해준 논문은 2014년에 나온 연구의 후속 연구(2017)다.

1편은: 소프트웨어 개발자의 생산성 인식(https://www.zora.uzh.ch/id/eprint/98324/1/productivity.pdf)

2편은: 생산성 인식에 따른 소프트웨어 개발자 분류(https://www.zora.uzh.ch/id/eprint/141848/1/prodClusters-ESEM17.pdf)

1편  

제목: Software Developers’ Perceptions of Productivity

발행: 2014년

저자: Meyer, André; Fritz, Thomas; Murphy, Gail C; Zimmermann, Thomas

소프트웨어를 개발하는 커뮤니티는 소프트웨어를 만들게 되고, 요즘엔 그게 역전이 돼서 필요에 의해 소프트웨어를 만드는 시대가 됐다. 요즘 리서치 업계는 이 그룹을 유기적 생명체로서 어떻게 해석할 수 있는지가 관심사다. 특히 소프트웨어 개발자가 스스로 생산성을 높이기 위해 어떻게 생각하고, 접근하고, 행동하는지에 관심이 많다.

이들을 분석하기 위해 우리는 두 가지 실험을 기획했다. 하나는 379명의 소프트웨어 개발자들에게 `테마` (어떤 유형의 개발자가 있다)를 알려달라고 했고, 다른 하나는 11명의 전문 소프트웨어 개발자들에게 `테마`를 추려달라고 했다. 

양쪽 연구의 결과로, 그들은 많거나 큰 과업을 방해나 컨텍스트 스위치 없이 한 번에 끝낼 수 있을 때, 스스로 생산적이라고 느꼈다. 그러나 관측해 본 결과 우리는 참가자들이 중요한 일이나 활동을 하기 위해 행동을 전환 할 때도 여전히 그들이 생산적이라고 생각하는 것을 확인할 수 있었다. 우리는 이 외에도 관찰 결과를 분석해서 소프트웨어 개발자들이 더 나은 개발 환경에서 몰입할 수 있도록 하는 방법을 제안할 것이다.

논문 핵심 키워드

회고, 생산성, 목표 설정

알게 된 점

소프트웨어 개발을 충분히 몰입해서 할 수 없는 점은 꽤 오래전부터 논의된 바다. NATO는 1968년 처음으로 이 현상을 소프트웨어 위기(software crisis) 라는 용어로 정리했다.  1972년 다익스트라는 그의 저서에서 “프로그래밍은 점점 더 거대한 문제를 풀고 있다”고 했다. 1987년 보엠(Boehm)은 소프트웨어의 필요성이 커지고 있음을 이야기했고, 1996년 깁스는 만성적인 소프트웨어 위기를 꼬집었다. 2011년 안데르센은 소프트웨어가 세계를 먹고 있다고 말하면서, 소프트웨어의 필요성을 역설했다.

그럼에도 불구하고 소프트웨어 생산성에 대한 연구는 상당히 과소평가됐다. 이 논문에서는 소프트웨어 개발자들의 높은 생산성이 발생하는 환경에 대한 인식을 조사하고, 관찰하는 연구를 수행한 결과를 보고한다. 연구는 379명의 응답으로 이루어졌고, 이들은 평균 9.2, 편차 +- 7.3년의 소프트웨어 개발 경력이 있다.

이 논문은 크게 세 가지 컨트리뷰션이 있다.  

379명의 전문 소프트웨어 개발자들이 그들이 생각했을 때 ‘생산적인’ 업무 환경에 대하여 답했다.

11명의 전문 소프트웨어 개발자들을 직접 관찰하고 생산적인 환경, 업무란 빠른 컨텐스트 스위치 속에서도 발생할 수 있음을 확인했다

마지막으로 이 두 가지 관찰 결과를 결합하여 소프트웨어 개발자들이 더욱 생산적이도록 할 수 있는 방식을 제안한다.

연구 방식은 논문을 참고하도록 하고, 결과만 관찰해보자.

설문 결과 379명의 개발자들은 생산성을 다음과 같이 생각했다.

그리고 다른 문항으로 적힌 생산성 평가 설문은 아래와 같다.

이번에는 11명의 전문 소프트웨어 개발자를 관찰한 결과를 보자.

이들의 경력은 아래와 같다.

이들은 관찰 첫 날 다음과 같은 타임라인으로 컨텍스트 스위칭을 하면서 일했다.

그리고 전문 소프트웨어 개발자들의 업무 카테고리는 다음과 같았다.

앞서 개발자들이 빠른 컨텍스트 스위칭이 있어도 생산적임을 느끼기도 한다 했는데, 관찰 결과 다음과 같은 상황을 의미했다. 예를 들어,  

빌드 중에 짬이 생겨 이메일 응대를 하거나

코드 리뷰를 하면서 30초 정도 이메일에 답변을 한다

하는 일들 말이다. 실제론 하루에 이렇게 컨텍스트 스위칭으로 쓰는 시간이 두 시간 30분이나 됐지만 이것이 중요한 일들이 벌어지는 사이사이에 들어간다면 그들은 하루가 생산적이라고 생각했다.

결론

논문은 두 가지 요소를 강화함으로써 개발자들이 생산성을 높일 수 있다고 말한다. 첫 번째는 셀프 모니터링(또는 회고) 시간을 강화해야 한다고 주장한다. 이것이 개인의 행동을 변화시킬 수 있다고 말한다. 또는 그들이 함께 일하는 코워커의 피드백, 꿀팁(productivity information)이 도움이 된다고 말한다.

둘째는 컨텍스트 스위치를 줄이는 것이다. 몰입감을 느끼는 피험자들은 모두 컨텍스트 스위치가 적었고, 결과적으로 생산성을 높일 수 있었다고 주장한다. 우리 또한 컨텍스트 스위치 시간을 시각화함으로써 개발자들이 얼마나 생산적임을 느낄 수 있는지 확인할 수 있었다. 그러나 앞서 언급했듯 중요한 일들 중 짬짬이 발생하는 틈새 시간에 하는 컨텍스트 스위칭은 (개발자들이 스스로 생산성이 떨어졌음으로 의식하지 못하게) 괜찮은 요소였음을 알아냈다.

마지막으로 논문은 목표를 잘 정하는 것도 중요하다고 밝힌다. 이것이 개발자들의 동기와 변화를 자극한다고.

연구진들은 이 세 가지를 잘 할 수 있는 방법으로 좋은 툴로 서포트 해주라는 말을 남긴다. 트랙킹이 잘 되는 소프트웨어나 컨텍스트 변화가 적은 좋은 툴은 그들의 생산성을 높여줄 것이라고 정리한다.

2편  

제목: Characterizing Software Developers by Perceptions of Productivity

발행: 2017

저자: Meyer, André; Zimmermann, Thomas; Fritz, Thomas

연구진들은 클러스터링 분석을 통해 1편에 이어 연구를 수행했다. 과거보다 더 업그레이드 된 숫자와 전문성 집단을 섭외했다고 한다. 이번에는 413명의 마이크로소프트 전문 소프트웨어 개발진들로부터 설문을 얻어 연구를 수행했다. 그들은 이 논문의 결론으로 `생산적인` 개발자는 다음 여섯가지 카테고리 안에 있다고 밝힌다. 여섯 카테고리란  

사교적인

고독한

집중력있는

균형잡힌

리딩하는(leading)

목표 지향적인

개발자를 의미한다. 연구진은 이 결과를 기반으로 소프트웨어 개발자들의 생산성을 높일 수 있는 개인화 추천 방식을 제안하고 토론을 여는 것으로 논문을 마친다.

핵심 키워드

생산성, 인식, 소프트웨어 개발자

알게 된 점

1970년대부터 연구자들은 개발자들의 생산성을 측정하는 요소를 다각화했다고 한다. 왱거와 루흐(Wanger and Ruhe)의 카테고라이즈 모델에서는 기술적인 요소 뿐 아니라 프로그래밍 언어, 소프트웨어 툴, 소프트웨어 규모/복잡성, 그리고 제품 품질, 사교적 팩터, 경험과 스킬 그리고 근무환경 같은 것들이다. 요약문에선 서베이 디자인과 측정 방식에 대한 설명은 스킵하겠다. 연구 결과 개발자들은 보통 여섯 가지의 성향으로 드러나는데 이들 각각에 라벨을 붙이면 아래와 같다.  

C1(사교적인 개발자)          동료를 도울 때 생산적임을 느낀다      코드 리뷰할 때나 협업할 때 생산적임을 느낀다      이를 위해 그들은 일찍 출근하고 늦게 퇴근하며 하나의 일에 매달린다      

C2(고독한 개발자)          소음을 피해다닌다. 여기서 소음이란 이메일, 미팅, 코드 리뷰다      그들은 사교적 관계가 적고 문제에 깊게 몰입할 수록 생산적임을 느낀다      버그를 고치거나 피처를 만드는 코딩을 즐긴다.      

C3(집중하는 개발자)          이들은 `앉은 자리에서` 집중해서 하나의 일에 매달릴 때 생산적이라고 생각한다      이들은 하나의 일을 처리하는데 너무 많은 시간을 소모하면 비생산적이라고 생각한다. 왜냐면 이것은 그들 입장에서 막히거나 늦어진 일이기 때문이다.      

C4(균형잡힌 개발자)          이들은 방해에 덜 영향받는다      이들은 적당히 출근하고 적당히 퇴근하는 경향이 있다      (이들은 다른 그룹보다 더) 문제가 명확히 정의되지 않은 일이 비생산적이라고 느낀다.      또는 그들과 상관없거나 작업자 자신이 그 일에 적임자가 아니라고 느낄 때 비생산적임을 느끼는 경향이 강하다.      

C5(리드 개발자)          이들은 미팅이나 이메일 응대를 할 때 상대적으로 편안함을 느낀다.      그리고 이들은 앞서 언급한 내용보다 코딩을 할 때 덜 생산적이라고 생각한다.      이들은 오후에 훨씬 더 생산적이라고 생각하고, 이때 주로 설계를 한다      이들은 빌드가 깨지거나 업무가 갑작스럽게 마무리 되는 일이 비생산적이라고 생각한다.      

C6(목표 지향적 개발자)          이 그룹은 과업이 착착 진행되는 모습에 생산적임을 느낀다      멀티 태스크를 하거나 목표가 흐릿한 일이 비생산적이라고 생각한다      이들은 다른 그룹에 비해 미팅과 이메일에 열려있다. 이것이 그들의 목표를 명확히 해준다고 믿을때까진 말이다.      

팀 수준에서  

C2, C3 의 개발자들은 조용한 곳을 배치해주는게 좋고          이들은 ad-hoc(가설의 가설에 가설을 이야기하는, 속 뜬구름잡는) 미팅을 줄여주자      차라리 비동기 커뮤니케이션이 좋다      

C1은 오픈 오피스가 좋겠다

새 프로덕에 대한 열린 이야기(목표가 불명확함)는 C6, C2, C4에겐 좋지 않다.

개인 수준에서  

방해를 줄이는 툴은 C2에게 매우 효과적이다

C1에겐 별 효과가 없다. 이들에겐 차라리 코드리뷰나 빌드 경험 같은 상황이 좋다.

C3에겐 조용하고 방해받지 않는 개발 시간을 내어주는 것이 생산성에 좋다.

반대로 C4에게는 환기하는 시간(휴식 시간)을 허락하는 것이 생산성에 좋다.

C5는 C3에 비해 미팅이 많은 날 생산적임을 느낀다.

마지막은 C1-6을 구분하는 간략한 설문 요약이다. 자신이 어디에 속하는지 돌아보는데 참조해볼 수 있겠다.

세 줄 요약  

개발자들이 생산적이다고 느끼게 하려면 컨텍스트 스위칭이 거의 없게 하자

좋은 개발 툴과 피드백 수단(동료, 스스로 피드백 할 수 있는 툴)을 아끼지 말자

개발자들은 보통 6가지로 요약되며 적절한 방식으로 피드백 및 배치함으로써 팀 내 생산성을 올릴 수 있다(‘적절한 방식’ 이란 본문에 적었다)