효율적인 업무
Last updated
Last updated
현재 조직의 인원, 상황에 맞는 효율적인 업무 방법은 항상 고민되어야 한다.
조직의 관점: 현재 팀에서 업무를 진행하는데 있어 효율성 없는 요소를 체크하고 효율화를 진행
업무 프로세스 관점: 업무가 진행되는데 있어 효율성 없는 요소를 체크하고 효율화를 진행
타 부서 협업 관점: 타 부서와 협업의 상황에서 커뮤니케이션의 문제가 생기는 상황을 체크하고 효율화를 진행
어딘가에 완벽한 조직은 있겠으나, 지금 우리팀은 아닐 확률이 높다.
팀에서 일어나는 다양한 문제를 소요시간에 빗대어 체크: 소요시간 대비 현재 업무가 적합한가?
팀 내의 업무를 처리하는 기준을 어느정도 베이스를 만들어서 제공하고, 데이터를 검증한다.
가장 먼저 팀에서 어떤 형태로 업무를 진행하는지 확인
업무의 흐름을 간단하게 그리고 어느 부분에서 업무가 가장 많은 시간이 소요되는지 확인한다.
어떤 업무가 해당 단계에서 진행되는지 정리/조사 한다.
자세히 어떤 업무가 어느정도의 코스트가 들었는지 기록 필요
해당 퍼센테이지에서 없거나 많이 차지하는 작업이 왜 그러한 코스트가 들었는지 전수조사 필요
실제 업무를 진행하는 진행자와 참관자를 나누어 현재 업무가 어떻게 진행되는지를 체크한다.
오버헤드가 일어나는 원인을 찾고, 진행되는 시간과 어느 문제가 일어나는지 체크한다.
체크하기 전 "평균 진행되는 시간 대비 왜 더 많아졌는지 체크"한다.
문제가 생긴 영역에 대해서 전체 프로세스 과정에 필요하지 않은 부분을 체크
진행되는 상황에서 실제 문제 기록을 확인하고 해당 병목을 해결할 수 있는 방법 모색, 회의 진행
다음 업무 등에 적용 혹은 기술 고도화 todo를 추가, 해당 과제가 전방위적으로 어떻게 비효율적으로 돌아가는지 확인하기
현재 조직에서 중요한 부분이 어떻게 이뤄지고 있는지 알아야 한다.
아래의 내용을 본인 조직에 질문하여, 답변을 해보자!
기술 적용과 논의 과정이 어떤 프로세스로 진행되는가?
장애 탐지 및 대응 과정이 어떤 프로세스로 진행되는가?
업무의 담당자를 지정하는 과정이 어떤 프로세스로 진행되는가?
팀 내에서 정보 공유의 과정이 어떤 프로세스로 진행되는가?
테스트를 어떤 기준으로 작성하고 실제 배포까지 어떤 QA 및 TC들이 동작하는가?
코드 리팩토링은 어느때 동작하고 주로 담당하거나 발의하는 사람이 누군가?
코드 리뷰는 진행되고, 어느 수준으로 깊이 있게 진행되는가?
개발환경, 운영환경은 어떻게 구분되어있고, 각 환경 별 동작하는 CI와 브랜치 전략은 자동화가 잘 되어있는가?
궁극적으로 자동으로 굴러가는 조직을 만들어야 한다.
중요 목표: 개선이 일어나면 팀/개인이 성장할 수 있는 조직을 만들기
개선할 점을 누구든지/언제나 발의할 수 있는 커뮤니케이션 환경
누구든 해결하고 성과를 가져갈 수 있고, 리스펙트 받을 수 있는 환경(고생한 만큼 성과 및 인정)
가장 가까운 곳부터: 모든 팀원이 서로를 인정하고 배울점이 많다는 자세로 만드는 것
개발자는 성장을 한다는 것이 느껴져야 팀에 소속하여 업무의 성과를 추가적으로 발생시킨다.
최종 목표는 리더가 최소한으로 개입하여 최대의 성과를 내는 것이 목표
이를 우리는 "개발 문화"라고 표현한다.
단순히 어떤 기술을 쓰고 어떤 전략을 쓰는지는 개발 문화가 아니다.
개발 문화는 장기적으로 더 안정적으로 서비스를 제공하고 언제든 발전을 시킬 수 있는 전략을 구상해야 한다.
크게 비즈니스 대응 / 안정적인 프로덕트 운영 / 개인의 성장 세가지로 고민해 볼 수 있다.
e.g)
우리 팀에 가장 잘 맞는 프론트엔드 프레임워크는 무엇일까?
현재 비즈니스가 빠르게 동작하고 있는 상황에서 무언가를 변경하면 안정적인 프로덕트 운영이 깨진다.
개인의 성장 관점에서 지금 동작하는 프레임워크를 유지하는것이 올바른 선택일까?
우선순위: 비즈니스 대응 > 안정적인 프로덕트 운영 > 개인의 성장
비즈니스 대응, 안정적인 프로덕트 운영은 성과에서 중요하지만, 개인의 성장은 퇴사율에 영향을 미친다.
뒤에서 이야기 할 내용: 개인의 성장 관점에서 문화적으로 어떻게 제공할 수 있는지 이야기
어떤 시스템을 제작하거나 변경하지 않고 성장을 챙길 수 있을까?
개발자의 성장은 개발 리더로써 개인마다 효율적으로 성장할 수 있도록 고민해야 한다.
제안과 프로세스를 만들긴 하지만 성장하는건 본인이기 때문에 환경을 구축하는 것 까지가 리더의 역할
개발자의 성장은 크게 몇 가지로 나눈다.
도메인: 전문화된 도메인 지식, 회사의 업무를 진행하면서 쌓을 수 있는 역량
리더십: 기술적으로 혹은 과제 단위로 여러 인원을 리드하면서 쌓을 수 있는 역량 (주도성과도 연관)
코드: 실제 어떤 것을 구현해내는 역량, 실제 현업에서 개발 기간, 인사이트 등이 여기에 포함된다.
커뮤니케이션: 현업 부서와 업무를 진행하는데 필요한 역량
도메인, 리더십, 커뮤니케이션 역량은 가시적으로 잘 보이지 않고, 본인이 어느정도 성장했는지 빠르게 알기 어렵다.
본인 성장의 방향, 위치 등을 알 수있는 문화를 만들자.
문화는 한번에 만들어지지 않는다.
우리가 하나의 여러 문제를 해결할 떄 중복된 문제가 발생하고 해결하기 위한 라이브러리를 구축한다 하였을 때 여러 영역에서 공통적인 문제가 발생한 것을 체크하고, 해결 방안을 제시하고, 공통 업무 프로세스를 적용하여 장기적인 운영을 해보아야 한다.
여러 방면으로 방안을 제시하고 업무 프로세스 적용하고 장기 프로세스 운영하는데에 본인이 할 수 있는 영역에서 해결해주어야 한다.
위 흐름이 장기간 반복되면 문화로 자리잡히게 됨
코드 리뷰는 가장 만들기 쉽지만 유지하기 어려움, 그럼에도 성장을 빠르게 확인할 수 있는 문화
비즈니스가 빠르다는 이유로 코드 리뷰가 안되는 조직은 흔하다.
간단한 코드 리뷰 만으로 빠른 비즈니스에서 코드 안정성은 매우 올라간다.
비즈니스 대응/ 안정적인 프로덕트 운영 / 개인의 성장 세 가지 관점에서 코드리뷰는 모두 유효하다.
코드리뷰가 업무의 프로세스로 안착되려면
주도하는 리더가 초기에는 많은 시간을 들여서 리뷰를 진행해야 한다.
배포 및 코드 합병 권한을 모두 회수하고 강제성을 부여
강제 코드 리뷰어 1명을 항시 랜덤으로 배치하거나 의미를 두어 배치한다.
리뷰어의 승인이 없다면 배포가 안되도록 제공
문화가 이뤄지려면 타당함을 지속적으로 공유하여 모두가 이해할 수 있도록 전파한다.
코드 리뷰의 사례
코드 리뷰로 인해 어떤 효과가 있었는지 이야기한다.
e.g) 코드리뷰로 비교기간 대비 장애가 어느정도 사라졌는지
e.g) 코드리뷰가 진행된 코드와 아닌 코드의 차이 확인
e.g) 가장 훌륭했던 코드리뷰, 논의가 가장 많았던 코드리뷰 선정
e.g) 가장 많은 코드리뷰를 진행한 사람
친숙해지기 위한 여러 이벤트를 통해 지속적으로 참여할 수 있도록 제공한다.
진행하면서 여러 난관 (코드리뷰가 방치되거나 시간이 오래걸리는 등)이 존재하는데, 이 또한 지속적으로 공유한다.
일하는 방법은 계속 변경되어야하고 진화해야 한다.
문화는 언제든 바뀔 수 있다.
좋은 문화라면 긴 시간동안 유지되면서 계속 보수가 되어 더 좋게 변경될 것
좋은 문화인지 잘 모르겠는 것은 짧은 기간 테스트 기간을 만들어 진행해보고 파기한다.
문화는 너무 많아선 안된다.
리추얼 (Ritual)한 업무는 최소화: 출근 시/ 퇴근 시 / 점심시간 등 모든 사람들이 일반적으로 갖는 루틴에 한 두가지만 만든다.
Event는 되도록 크게: 하나의 업무를 할 때 작게 반복적으로 시간을 갖는 것보다 길게, 한번에 하도록 유도한다.
기계의 힘으로 자동화: 모든 업무는 초기에 수기로 진행되지만, 지속적으로 자동화하여 리소스를 감소시키게 한다.
