업무 프로세스 병목 파악
만들어진 문화와 프로세스에 문제를 파악하기
업무 프로세스: 협업을 포함한 일을 하는 상황에서 일이 진행되는 흐름
팀 내에서 업무의 경우 변경/개선의 작업이 상대적으로 쉬움
업무 프로세스는 팀 내 뿐만 아니라 상위 조직, 협업 조직간의 모든 부분을 일컫는다.
조직의 구조
목적조직, 기능조직 등 조직의 특성은 여러가지 존재
목적과 기능이 섞인 조직도 존재
현재 협업 조직 구성에 따라 업무 프로세스는 많은 차이가 있다.
협업 프로세스 차이 이해하기
인바운드 업무 프로세스 (업무 요청에 따른 워터폴 방식의 프로세스)
주도적인 업무 프로세스 (애자일 방식을 기반한 업무)
협업 프로세스 비교하기
업무 방식에 따라 이뤄지는 형태가 다르기 때문에 방식에 따라 다르게 만들어야한다.
팀의 업무 방식이 애자일로 동작하는데 워터폴을 적용하면 맞을수가 없고, 워터폴인데 애자일을 장착할 수도 없다.
현재 업무 방식에 따라 협업할 수 있는 방법을 선택해야 한다.
애자일의 경우
보통 애자일의 경우, 협업 프로세스 상 비효율이 일어날 경우의 수가 적음
모든 직군이 한데모여 작업을 논하기 때문에 비효율이 일어나면 팀이 많아서 공유하는데 시간이 오래걸리는 경우들이 대부분
이 경우, 기능 단위로 조직을 쪼개어 기능의 리더들만 모여서 중대사를 논의하고, 전파하는 등의 프로세스가 필요
워터폴의 경우
워터폴 자체가 비효율
이 경우 워터폴을 비틀어서 강제로 애자일에 비슷하게 만들 필요가 있음
보통 중~대규모 조직이 워터폴인 경우가 잦음
병목 지점 파악
업무의 대다수는 공유에서 부하가 걸린다.
병목 개선 #1 - 데일리 공유 시간 최적화
불필요한 공유의 시간으로 시간을 쓰는 문제 해결하기
서로간 업무를 공유하는 여러 방법
데일리 스크럼: 프로세스의 일부, 일일 회의를 말함 = 스탠드업 미팅
메신저를 이용한 공유: 원격 근무 시 쓰레드나 허들을 통한 공유
문서 기반의 공유: 문서를 통해 하루의 할 일을 공유
인원이 많을수록 물리적인 모임을 통한 공유는 부적절하다.
인원이 많아질수록 문서기반의 공유 등 비동기적으로 일어나는 이벤트로 변경해야 한다.
인원이 많다면 조직을 분리하여 데일리 스크럼으로 각 조직이 동작하도록 하는 것이 유효할 수 있다.
병목 개선 #2 - 타 팀간 공유 시간 최적화
다른 팀간 과제를 협업한다면 다음과 같은 조직 구조일 수 있다.
TF: Task Force로 엮인 임시 조직
기능 조직: 기능 단위로 분리된 조직끼리의 협업
WG: Working Group, 긴밀하기보단 느슨하게 업무를 진행하는 구조
느슨할수록 비동기적인 문서를 사용하며, 빠르게 증명해야하는 과제의 경우 스크럼 기반의 빠른 스프린트로 개발하는게 좋다.
지라 등 업무의 협력 부서가 진행상황을 알 수 있는 도구를 사용
이러한 부분이 자동화가 되어있지 않으면 커뮤니케이션 비용이 많이들게됨
병목 개선 #3 - 담당자 배정에서의 시간 최적화
담당자 배정: 현재 작업자의 일감에 따라 매니저가 업무에 적합한 인원을 선출하는 과정
보통 선출 혹은 칸반 보드를 통해 스프린트에서 본인이 할 일을 주도적으로 가진다.
담당자의 리소스 양은 본인만 알 수 있도록 하는게 아닌, 모두가 볼 수 있도록 해야한다.
스토리 포인트와 번다운 차트
스토리 포인트: 업무를 점수로 매기고, 한 과제를 진행할 때 구성원이 어느 점수만큼의 업무를 하는지 판단하는 방식
번다운 차트: 현재 팀의 상태를 스토리 포인트 기반으로 확인할 수 있도록 하는 차트
스토리 포인트, 번다운 차트를 이용해 현재 팀 내의 리소스 산정 상황을 확인한다.
유관부서도 리소스 투여 상황을 확인할 수 있도록 제공하면 담당자 선정 단계에서 시간을 최적화 할 수 있다.
병목 개선 #4 - API 공유 과정에서의 시간 최적화
API는 보통 스웨거 등으로 공유됨
이 때 모든 스웨거의 변경사항을 알기는 쉽지 않고, 서버의 스펙에 따라 지속적으로 변경해줘야 하는 이슈 존재
API를 즉각적으로 변경하는 것은 쉽지 않은 일 (리소스 많이 듦)
첫 번째: API 배포될 시 배포마다 버저닝을 지원한다. - 초기 구축에 서버 리소스 많이 듦, 오히려 RPC가 나을 수도
두 번쨰: 스웨거 API를 후킹하여 변경사항을 자동으로 프론트로 마운트한다. -BFF가 있으면 용이
세 번쨰: RPC를 구축
협업 부서가 많고, 중복 API를 많이 쓰는 경우 이러한 자동화는 필수적으로 운영되어야 한다.
병목 개선 #5 - 코드리뷰 과정에서의 최적화
코드 리뷰 또한 반복적으로 작업하다보면 중복 과정이 발생
첫 번쨰: 코드리뷰어 배정의 자동화 - 가중치나 도메인 담당자 지정을 통해 자동화된 MR에 대한 코드리뷰어를 지정한다.
두 번쨰: 코드리뷰어 및 approval 일정 갯수 이상일 때 자동으로 merge가 되도록 하는 자동화를 진행한다.
세 번쨰: 자동화된 코드를 배포를 하여 테스팅 등의 CI/CD 자동화를 진행
네 번쨰: CI/CD 등의 과정에서 문제가 생기는 경우 자동으로 에러를 공유하는 파이프라인을 개발
다섯 번째: 배포 자동화를 통해 개발서버, 베타서버 등에서 확인할 수 있도록 제공하며, 공지채널을 통해 유관부서가 배포됨을 알 수 있도록 제공
마지막: 해당 과제의 담당자를 위한 DM 혹은 공지 채널에 자동멘션을 진행하는 등의 작업을 한다. (이를 위해 MR의 번호에 지라 티켓등을 추가하여 assignee를 연동하고 메시지를 전달)
협업간 부서 내외에서 커뮤니케이션 문제 해결하기
협업은 여러 방향으로 진행되며, 여러 방향의 사이에서 비효율을 자동화시켜야 한다.
협업 조직을 알아보기 전, 우리 팀에 대한 이해가 필요
팀은 여러 조직과 협업을 하는가?
기획/디자인/앱/서버/QA등 다양한 조직과 협업 진행
업무 요청 조직이 여러 조직일 가능성이 높으며, 업무 요청을 한 군데에서 받을 수 있도록 하는 등의 작업 필요
하나의 조직과 협업을 하는 경우 (축복받은 경우)
하나의 조직과 협업을 하는 경우는 이러한 커뮤니케이션의 문제가 중요하지 않을 수 있음
커뮤니케이션 문제가 중요한게 아닌 개개인이 업무를 더 잘하기 위한 고민을 해야 한다.
업무를 받으면 해당 업무를 정리해주는 PM/PO가 있을 확률이 높으며, 본인의 업무에 더 초점을 맞춰 진행
여러 조직과 협업
프론트 개발팀은 하나의 단독 기능 조직으로 만들어 지는 경우가 많다.
e.g) 프론트 1팀, 2팀, ~~~ 프론트팀
프론트라는 영역 자체가 백엔드 개발자처럼 인원이 많지 않다.
화면을 그리는데 전문성이 필요한 영역, UI/UX 관점에서의 영역이기 때문에 서비스 운영 인원이 백엔드 보다 적다.
직군이 다름에 따라 업무가 다른 것처럼, 서버 안정성 등과 같은 부분보다 더 빠르게 업무를 하기 위한 생산성이 조금 더 중요
보통의 조직은 하나의 프론트 팀을 만들고, 여러 목적 조직이 프론트 하나의 팀에 업무 요청을 하는 등의 프로세스가 구축됨
이러한 업무 프로세스로 인해 업무 자동화가 많은 효율성을 나타내는 팀이 되기도 함
프론트는 인프라 서버 지식이 있는 개발자일수록 더 효율적인 조직을 쉽게 만들 수 있다.
여러 조직과 협업을 하기 위한 자동화
Git Branch Auto Make?? WiKI Auto Make??
궁극적으로 협업을 위한 리소스는 줄이고, 자동화를 통해 일관적인 프로세스로 운영되도록 설계한다.
업무를 진행할 때 개발자와 업무 요청자의 사이에는 수동 프로세스가 있을수록 업무 능률이 떨어지게 된다.
협업 비용 자동화를 통해 최대한 최적화를 목표로 한다.
슬랙 API, GItHub/Lab API, WiKI/Jira API, Notion API 등 대다수의 툴은 API를 제공하며 사용하기 쉽게 되어있음
자동화 툴은 실제 개발 비용이 크게 들지 않는다. 또한 운영에서도 대다수의 경우 동작하며, 활용되었을 때 생산성이 매우 크다.
이러한 작업을 Productivity Engineering 이라고 표현한다.
팀 내에서 생산성을 올리기 위해 팀원들에게 많이 강조하는 것 또한 중요하다.
조직 리더의 커뮤니케이션 역할
커지는 조직에서 리더의 역할은 점진적으로 달라진다.
인원이 늘어감에 따라 업무를 효율적으로 할 수 있도록
특정 도메인 단위로 파트장을 선출하여 파트장과 긴밀한 커뮤니케이션 진행
파트장은 팀원의 업무를 배정하고 실제 카운터 파트와 협업을 진행
팀장은 파트장과 커뮤니케이션을 통해 리소스 현황과 업무 과중도를 체크하고 장기적인 플랜에서 업무를 설계한다.
예시
팀 조직이 리더를 제외한 5명 정도 개발 인원일 때
팀장이 팀원들에게 하나하나씩 매니지먼트를 하고, 어떤 것들에 대해서 쉽게 제어를 할 수 있는 상태
팀 인원이 10명 일 때
파트장을 세워 파트장을 컨트롤하고 나머지 4명을 컨트롤 하는 등
팀 인원이 16명일 때
팀장은 파트장만 매니지먼트
남은 인원들은 따로 컨트롤하지 않음
일반적으로 일을 잘한다고 하는 애자일 스크럼 프로세스
팀장은 파트의 문화를 존중하되, 시작과 끝에만 공유를 받고 정리한다.
가장 중요한 것: 파트 단위로 팀이 유지가 된다면 팀장은 커다란 과제를 진행하는데 우선순위를 상위 리더들과 조율한다.
과제의 크기를 정해서 매년 핵심 과제를 지정하고 해당 과제를 제외한 작은 과제는 파트 단위로 조정
효율적인 업무를 위해서 해야할 일
효율적인 업무는 먼저 비효율을 측정하는 일부터 시작함
업무의 비효율은 단순히 그런것 같다~로 해결하는게 아닌, 정확한 측정을 통해 진행
조직 내에서 효율적인 프로세스에 대해서 충분한 고민을 통해 리소스를 효율적인 프로세스를 구축하는데 배정한다.
비즈니스, 안정적인 프로덕트 관점에서만 고민하는게 아닌, 무언가를 결정할 때 팀원 개인의 성장 또한 고려한다.
업무 프로세스에서 비효율이 존재하는 경우를 찾고, 자동화에 리소스를 할애하면 조금의 효과로 많은 생산성을 챙길 수 있다.
팀의 업무 흐름 뿐만 아니라 협업하는 조직의 프로세스를 알아보고, 그 과정에서 함께 최적화를 할 수 있는 형태를 고민한다.
현재 조직의 협업 상황에 따라 업무 요청부터 개발 완료까지의 프로세스를 체크하고 자동화를 진행할 수 있다.
현재 조직의 규모에 따라 조직 리더의 역할은 달라지며, 많을 수록 파트로 구분하여 운영하는 것이 적절하다.
Last updated
