💻 Backend
일 잘하는 개발자 - 소프트웨어 엔지니어링 생산성 돌아보기
date
Dec 10, 2023
slug
GDG-Songdo-Backend3
author
status
Public
tags
Conference
summary
[GDG-Songdo-Backend] 개발자가 일을 더 잘하는 방법(생산성을 높이는 법)
type
Post
thumbnail
category
💻 Backend
updatedAt
Dec 11, 2023 03:16 PM
배필주 / "일 잘하는 개발자" - 소프트웨어 엔지니어링 생산성 돌아보기 (General)개발 생산성을 정의할 수 있을까?생산성 프레임워크(체계적으로 접근하기)생산성에 영향을 미치는 요인생산성을 저해하는 요인6가지 유형내 생산성을 좀 더 향상시킬 수 있는 방법?행복한 개발자의 생산성이 더 높습니다.참고링크Comment
배필주 / "일 잘하는 개발자" - 소프트웨어 엔지니어링 생산성 돌아보기 (General)
⏰15:00 @veronikapj (linkedIn)
개발 생산성을 정의할 수 있을까?
- 측정 가능할까? 왜 측정하려고 할까?
- 일(work): 노동, 생산하는 것
일을 잘한다
는 건 뭘까?
기획자 : 일정 내에 ㅇㅇ기능 추가 또는 수정 가능할까요?
개발자 : 마감일 vs 코드 품질
- 개발에 걸린 시간이 길다고 더 코드 품질이 좋을까?
- 작업 시간과 실행 비용의 상관 관계
- 작업 시간과 실행 비용은 아무 관계가 없다 (그래프)
- 시간=생산력은 산업시대 때의 기준
- 한국은 근로시간 대비 노동생산성이 높지 않다. (GDP)
개발자에게 생산성이란?
개인 개발자 관점의 생산성
- 작성한 코드량(LOC: Lines of Code)이 기준이라면
코드 몇 줄 작성 했는 지로 소프트웨어 생산성을 측정하는 것은 비행기의 무게로 비행기에 대한 진척 정도를 측정하는 것과 같다. - 빌 게이츠
- 커밋 수가 기준이라면
- 깃허브 잔디
- 잔디 심기 조작이 연관 검색어 1위임
- 개발 완료된 작업 수가 기준이라면
- 버튼 색상 좀 바꿔주세요 / 복잡한 구조를 가진 신규 서비스를 개발해주세요 는 같은가?
- 개발이 아닌 신입사원 온보딩 교육, 각종 문의 메일 대응, 이런 저런 회의, 옆 동료 문제 같이 디버깅 해주기… 등의 작업들
생산성을 한 가지 지표로 바라보는 게 맞을까?
- 연관된 각 팀들과의 목표가 서로 다르기 때문에 한 가지 지표로 나타낼 수 없다.
생산성 프레임워크(체계적으로 접근하기)
Goal
소프트웨어를 이해하거나 개선하기 위한 목표를 개념화
Question
운용하기 위한 연구 질문
Metric
도구와 프로세스를 이해하거나 측정하기 위한 지표 생성
Taylor System
최소의 노동과 비용으로 최대의 생산성을 높이기 위한 것
시간 연구, 동작 연구 → 표준 작업량 설정 → 작업 관리
- 작업관리
- 최고의 작업 설정
- 공구 및 현장의 표준화
- 성공자에 대한 우대
- 실패자의 손실
- 회사에서는 높은 생산성, 정확한 예측이 가능하지만
- 개인에서는 사기저하, 품질 저하, 자기계발 기회없음, 소외감, 자부심 결여..
- 이유는 관리의 주체가 회사이기 때문이라고 생각함
생산성에 영향을 미치는 요인
팀 문화 체크해보기
- 동지애, 분명한 목표, 의사 소통, 심리적 안정감, 엘리트 의식, 혁신에 대한 지원, 팀 결속련, 팀 동질감, 이직률
생산성을 저해하는 요인
개입(Interruption)
- 개입으로부터 회복하는데 시간이 걸릴 수 있고, 실수로 이어질 수 있다.
- 개입이 길수록 더 방해된다.
- 작업을 너무 빨리 재개하는 것은 실수로 이어질 수 있다.
- 작업 전환 주기가 짧을수록 스스로 느끼는 생산성은 더 낮다.
우리가 생산성이 높다고 느끼는 상황은 어떤 경우가 있을까?
- 작업이 진척이 생길 때, 작업 전환이나 개입이 몇 번 일어나지 않을 때
- 생산성이 높다고 느꼈을 때 실제로 활동한 시간은?
- 한시간에 평균 13번의 전환, 작업에 6분정도 소비, 한 활동(코드 작성, 테스트 실행 등)에는 20초에서 2분 정도의 시간만 소비했음..
- 가장 생산적(이라고 느끼는)활동은?
- 개인마다 다르다
- 당연히 코딩 (진척이 있을 때/없을 때)
- 미팅???
- 협업할 때
6가지 유형
사회형
- 협업, 코드리뷰
개인형
- 개입 등 방해요소 제거
집중형
- 한번에 하나의 작업(효율성 중시)
균형형
- 방해에 영향 덜받음
주도형
- 미팅, 이메일이 편함. 스펙을 작성하거나 설계할 수 있을 때
목표지향형
- 작업을 완료하거나 작업에 진척이 있을 때
내 생산성을 좀 더 향상시킬 수 있는 방법?
어떤 지표를 목표로 삼으면 해당 지표는 더 이상 좋은 지표가 될 수 없다. 지표를 통해 평가하게 될 때, 실제적인 실력이나 품질을 올리기보다는 지표만 올리는데 주력하게 된다. - 굿하트(GoodHeart)의 법칙
- 개입을 줄이는 법
- FlowLight 언제 개입해도 될 지 알려주기 바쁘면 빨간불, 한가하면 초록불의 상태를 나타내는 등
- 내 ETA 좀 더 정확하게 예측하기 (Estimated Time of Arrival, 작업 예상 완료 기한)
- COSMIC Function Point(ISO 19761)
- 1 CFP = 1 COSMIC Function Point
- 측정 단위 = 하나의 데이터 그룹의 데이터 이동
기능적 사용자 (인간) >
읽기 + 1 CFP
쓰기 + 1 CFP
..
행복한 개발자의 생산성이 더 높습니다.
Action
- 나는 어떤 스타일의 개발자인가
- 스스로 나의 생산성을 측정해보기
- 내 생산성을 좀 더 향상 시켜보기
참고링크
Comment
항상 어렵고도 난해하던 영역이다.
과연 내(개발자)가 더 일을 잘하기 위해서는 어떻게 해야할까? 또한 그걸 어떻게 증명해야할까?
스타트업 개발자로써 살아오며 겪었던 경험은 Jira 티켓 수(해결한 업무의 수)와 주변 동료들의 평가로 결정되었었다. 주로 상사의 의견이 많이 반영되었던 것 같다. 불만이었지만, 뚜렷하게 나타낼 지표도 없거니와 어떤 게 맞는 방법인 지도 알 수 없었다.
이번 세션에서는 세션 타이틀 그대로 소프트웨어 엔지니어링 생산성을 돌아볼 수 있었다.
내가 어떠한 환경에서 일을 잘 한다고 생각하는 지, 어떻게 해야 더 그 환경을 만들 수 있을 지(생산성을 높일 지) 생각해봐야겠다.
한 가지 확실한건.. 6가지 유형을 듣자마자 알았다. 나는
목표지향형
이다. 🙂