거기는 업무 관리를 어떻게 하나요?

작년 GDSC 에서 진행을 한 잡페어에서 , 다른 서비스 팀들의 기술에 관한 질문 보다는 어떻게 팀 또는 스쿼드를 구성하는지 , 회의는 얼만큼 하는지 ,스프린트는 어느 주기로 하는지 등을 주로 물어보고 다녔고 그중 가능하면 항상 기술부채를 어떻게 처리를 하는지 많이 물어 보았다. 

기술 부채라는 것의 정의가 팀마다 다르긴 한데 당시 속해 있던 리브위드 팀의 기술 부채의 정의란 다음 3개 의 항목으로 정의 할 수 있다.

 

1. 지금 당장의 지식으로는 해결 할 수 없는, 서비스 운영의 1~2 주 안으로 추가 하지 않아도 되는 기능

2. 미래의 개발을 해야할 아직 명확한 기획안이 나오지 않은 기능.

3. 컨번션 미 준수 사항 수정 및 리펙토링

 

당시에는  팀원들이 해야할 작업들을 매주 화요일 개발팀 회의를 통하여 정하였다.

 

작업의 우선 순위는 다음과 같은 기준들로 정했다.

 

0. 현 서비스 중인 기능의 사용자가 느끼는 오류 및 에러 처리

1.  1~2일 안으로 처리 가능한 작업

2. 사용자 대학생 사장님들이 사용하는 서비스의 추가 기능

3. 팀내의 기획자 팀 개발자들의 작업의 효율을 높이는 작업

4. 사용자의 서비스 경험을 증가 시키는 기능

5. 타 서비스와는 차별성을 줄 수 있는 서비스가 나아가고자 하는 추가 기능

 

5번이 서비스 런칭 전에는 우선시 되었지만, 정식 런칭 이후에는 여러 비용을 고려하는 상황에서 우선순위 중 마지막에 놓였다.

 그러나, 0~5 번의 우선순위의 차이가 거의 없을 정도로 빠르게 개발을 진행 하였다.

 

 

회의 흐름의 설명에 앞서 팀의 업무 룰은 다음과 같다.

 

공통 룰 : 문서의 내용이 사전 협의 된것과 다르다면 , 내용과 관련된 팀원과  개발팀 슬랙 채널에서 상의후 최초 발견자가 수정한다.

 

1. 매일 아침  업무 관리 노션 페이지에서 남아있는 업무들의 기간을 꼭 확인 한다. + 회고 페이지의 본인의 피드백,팀원이 해준 피드백을 확인한다.

 

2. wait confirm 의 자신의 이름이 있는지 확인을 하고 , confirm 을 하는 사람은 체크와 함께 커멘트가 없으면 complete 의 영역으로 작업 카드를 옮긴다.

 

3.작업 재요청의 자신의 완료되었던 작업 또는 waitConfirm이었던 작업이 있는지 확인한다.

 

 

개발보드에는 다음과 같은 요소들이 있다.

not start : 작업을 시작하기 전 개발 사항들을 정리해 두며, 가급적이면 시작 날짜를 적는다.

in progress : 현 작업중인 업무 개발을 두며 기간은 2주를 넘지 않는다.

wait confirm : 작업이 완료되면 , 승인 할 사람을 언급과 함께 카드를 둔다.

작업 재요청 : 완료된 작업의 , 작업 재요청을 거는 색션이다.

complete : 작업이 완료되면 각 팀의 팀장의 확인 후 본인이 직접 옮기거나 파트별 팀장이 옮긴다.

longTerm :  2 주가 넘는 작업을 기입 한다.

drop : 개발 중 중단할 사항들을 모아 둔다. 작업 카드를 삭제 하지 않고 모아둠으로 이전의 어떤 작업을 하다 실패 또는 변경했는지 조회를 가능하게 한다. 

 

 

각 작업 카드에는 필수 요소가 있다.

 

1. Confirm : 이름 

자신이 작업하는 것을 승인해줄 사람을 어노테이션과 함께 건다.

2. test :  로컬 테스트 는 필수 이며, 서버파트의 경우 테스트 환경에서의 사용 데이터 및 결과 스크린샷 첨부가 필수 이다.

 

 

회의의 흐름은 다음과 같았다.

 

- 이전 주차의 회의 내용 리마인드

 

- 개발 팀장의 공지 (새로 생긴 요구사항 , 이슈 , 기술 안내 등)

- 각 팀별 현제 진행중인 업무 및 개발 의 상황 , 작업 진행도 및 이슈를 공유 

- 해야할 업무들의 리스트화 후 팀원들과 상의를 통하여 일정 산출 및 우선순위를 정하기

- 다음 회의 까지 해야할 것들 우선순위 산정

- 업무 카드 정리 

- 회고 : 팀원들끼리의 피드백 + 자신의 샐프 피드백 

 

해야할 업무들의 리스트화를 하기전에 , 따로 기술 부채들을 모아두는 페이지들을 2 주에 한번  다같이 확인을 하여 없에는 것을 목표로 진행을 하였고 , 2달간의 서비스 개발 이후 1달간의 리팩토링 작업 및 기술 부채 해결 과 같은 큰 2개의 사이클을 돌렸다.

 

매달 서비스 개발을 진행을 하기에는 팀원들의 사기가 많이 떨어 지는것을 느껴 , 2달간의 스프린트 이후에는 1달간 기술 부채를 해결하는 것을 목표로 팀원들이 신기술 들을 공부를 하고 자신들이 작성한 코드의 구조를 고민하는 시간을 가졌다.

 

 

회의를 통해 앞으로 만들 예정인 기능들 ,기술 부채들을 정의 해두는 페이지

 

 

 

소규모로 구성이 되어있는 대학생 스타트업에서 개발을 총괄하는 입장에서  , 미래 변경사항에 대응하기 위해서는 팀원들의 성장이 지속적으로 이루어져 , 여러 업무를 처리할 수 있도록 만드는것도 하나의 중요한 목표였던것 같다.

 

 

+ 지라를 사용한 업무 프로세스는 개발팀 4인 중 2명이 반대를 하여 사용하지 않았으며, 반대 사유로는 유연하지 못한 인터페이스 및

4인으로 구성된 개발팀의 사이즈에 맞지 않아서 이다.