효율적인 업무 분배를 위한 Jira 태스크 관리

팀 프로젝트에서 결과물도 중요하지만 프로젝트 일정 관리와 업무 분배가 참 중요하다고 느끼는 요즘이다. 어쩌다 보니 팀 프로젝트 업무 분배를 내가 맡았기 때문인데, 나름 스타트업에서 프로젝트 관리를 경험해 본 적이 있었다는 이유였다.

 

업무를 어떻게 나눌까?

이전 경험에 의하면 프로젝트의 최종 목표를 모든 팀원이 공유하고, 최종 목표를 달성하기 위해 1주일 단위로 작은 목표를 세워서 스프린트 단위로 만들었다. 그리고 각 팀원 별로 OKR을 설정하고 태스크 단위로 쪼개어 업무를 분배했다. 이럴 경우 팀원 한명한명이 기억하고 짊어져야 할 목표가 많아지게 되는데 이것은 긍정적인 효과를 불러오더라. 목적의식을 부여하고 자발적인 기여를 기대하는 것이다.

 

수평적 지식 공유

목표 공유가 어떤 긍정적인 효과를 불러오는지 조금 더 자세히 말하자면 다음과 같은 키워드가 있다. 공감, 소속감 향상, 기여도 상승, 반복 업무 감소, 자율과 책임 고착. 다음과 같이 나열한 키워드가 사실 그리 와닿지 않을 것이다. 그렇기 때문에 내 경험을 토대로 한번 설명해 보겠다.

 

사회초년생 때 들어간 커머스 기업은 수많은 이벤트와 콜라보가 있었다. 문제는 이벤트 내용과 콜라보하는 업체와의 계약 정보는 팀장이나 과장급까지만 공유된다는 것인데, 이벤트 상세 내용을 작성하고 준비하는 실무자인 사원들은 팀장과 과장에게 끊임없이 질문하고 수정하기를 반복하며 업무를 진행해야 했다. 알고 보면 그리 중요한 사항이나 내용도 아닌데 말이다. 다만, 그때의 나는 이를 당연하게 받아들였었고, 책임소재가 적어 가벼운 마음으로 일할 수 있었다. 

 

그 후에 일하게 된 스타트업에서는 한 달에 한 번 꼴로 타운홀 미팅을 통해 전사 목표를 공유했다. 또 디자인, 개발, 기획, HR, 마케팅, MD 각 팀이 한 달 동안 어떤 목표를 이루었고 앞으로 어떤 프로젝트를 진행할지 공유했다. 그때 들었던 생각은 "아! 나도 이 회사가 성장하는데 한몫 거들고 있구나" 였는데, 우리 팀이 이룬 목표가 회사 목표에 닿았고 이를 모두에게 인정받았기 때문이 아닐까 싶다. 이후 내 업무에 자부심을 가지고 목표 달성을 위해 부단히 공부하고 노력했었다.

 

꽤 길어졌는데, 내 경험인 두 사례를 보자면 각각 장단점이 있지만 나는 후자를 더 지향한다. 이전 직장의 CEO는 지식 평준화? 평등화?라고 표현하기도 했는데 모든 팀원이 회사의 비전과 로드맵을 공유받고 송곳처럼 한 지점을 향해 나아가야 한다고 말했다. 물론, 팀원 입장에서 단순히 일을 지시받고 완수하는 수동적인 관계를 지향할 수도 있다. 하지만 관리자 입장에서는 팀원 각각이 목적의식을 가지고 자발적으로 업무하는 팀문화를 만들고 싶어하지 않겠는가. 그렇기 때문에 나는 이번 프로젝트에서 목표를 던져주는 것이 아니고 스스로가 목표를 가지고 자발적으로 참여할 수 있도록 함께 스프린트 목표를 세우고 OKR을 수립하기로 했다.

 

출철: 포보스

 

 

개발업무는 어떻게 나눠?

프론트엔드 개발 업무를 분배할 때는 고려할 사항이 생각보다 많았다. 각자 다른 페이지를 만드는 데 비슷한 기능이 있어 같은 작업이 반복될 수도 있고, 서로 개발 중인 스크립트가 겹쳐 conflict 날 수도 있다. 특히 라이브러리 설치 후 yarn.lock 설정에서 가장 많은 conflict가 있었고, 한 번에 많은 코드 추가나 수정이 있을 경우 머지 후 발생하는 에러 수정이 힘들었다. 그렇기 때문에 서로 연관성이 적은 태스크로 나누고 최대한 작은 단위의 태스크로 쪼개기 위해 고민했다. 

 

JIRA를 사용해볼까?

업무 협업 툴을 정하기 위해 몇 가지 사항을 고민했다. 위에 언급한 것을 토대로 내가 원하는 것은 세 가지였다.

 

1. 큰 목표에서 작은 목표로 가지치기 할 수 있어야 함

2. 서로의 업무를 한눈에 볼 수 있어야 함

3. 다양한 방식으로 필터링 되고 표현되었으면 좋겠음 (칸반 형식, 타임라인 형식, 스프린트로 보기, 태스크로 보기 등)

 

추가로 무료여야 한다!!

다양한 툴을 찾아보다가 좁혀진 후보는 3개 였다. 노션, 트렐로, 지라

 

노션

우선 노션의 장점이 정말 많았다. 무료에다 하나의 데이터 베이스로 타임라인, 캘린더, 보드, 리스트 등 변화무쌍하며, 간단한 코드를 짜서 커스텀도 가능했다. 문제는 느리다는 것, 뭔가 잘못 누르면 휙휙 바뀐다는 것. 설정과 커스텀이 많은 것이 처음 사용하는 팀원들에겐 독이 될 듯했다. 

 

트렐로

다음으로 트렐로는 사용하기 정말 간편했다. 처음 접해도 누구나 익숙하게 사용할 수 있었다. 다만, 기능이 너무 한정적이고 UI가.. 뭔가 쓰기 싫은?

 

지라

마지막으로 지라였는데 큰 장점으로 UX가 정말 좋았다. 단순히 팀원의 프로필을 클릭하는 것만으로 빠르게 필터링 되고 스프린트 기능을 간편하게 쓸 수 있었고 백로그에 업무를 쌓아둘 수 있는 것도 좋았다. 단순한 UI 덕분에 팀원들이 모든 태스크를 한눈에 보고 백로그에 쌓인 업무를 자율적으로 택할 수 있었다. 아쉬운 건 타임라인와 캘린더 보기가 조금 구리다는 거? 그래도 깃허브에 연동하며 branch를 따거나 commit하는 순간 카드가 자동으로 progress나 complate로 넘어가기도 하고 장점이 너무 많았다. 그리고 10명이하라면 무료 이용이 가능했기 때문에 최종적으로는 지라를 택했다.

 

JIRA 어떻게 사용했어?

지라는 업무를 세 가지 단위로 나눌 수 있다. 가장 큰 단위인 Epic, 에픽을 달성하기 위한 작은 목표 단위인 Story, 실제로 팀원들이 작업할 Task 단위. 그 외에 Bug도 있었는데 일단 제외했다. 참고로 나는 Story를 Epic의 하위로만 설명했는데 Jira를 운영하는 회사인 ATLASSIAN에서는 Story를 다음과 같이 설정한다고 한다.

 

"iPhone 사용자는 모바일 앱을 사용할 때 실시간 피드의 세로 보기에 액세스해야 합니다."

"데스크톱 사용자는 비디오 플레이어의 오른쪽 하단에 “전체 화면 보기” 버튼이 있어야 합니다"

 

재밌는 방식인데, 유저가 요구한 내용을 유저 관점에서 이야기하듯이 정한다. 그래서 Story라고 부르나?

 

우리는 프로젝트 특성에 맞게 조금 변형했는데, Story 이슈를 생략하고 Epic을 일주일짜리 스프린트 목표로 설정했다. 아래와 같이 총 4개의 Epic으로 설정했다. 조금 의문이 들 수 있는 부분은 UI제작과 기능 개발을 나누었다는 점. 이유는 아토믹 패턴의 작은 단위인 button, Input, badge, textarea 부터 background, modal, loading 등을 미리 만들어두고 이후 페이지를 제작 때 기능과 함께 컴포넌트를 조합하는 방식을 채택했기 때문인데, 이 컴포넌트를 만드는 작업이 주요 작업이 될 것 같아서 Epic 단위로 설정했다.

 

 

그 밑으로 바로 태스크를 만들었다. 근데 우리가 태스크로 정한 것이지 카드는 Story 카드였다..; 

 

 

 

카드를 만들 때 이슈 유형을 정할 수 있었는데 개발, 디자인, 기타 3가지 유형으로 정했다. 

 

 

Story 카드에는 Story point estimate라는 칸이 있었는데 설명으로는

"Measurement of complexity and/or size of a requirement." = "요구사항의 복잡성 및/또는 크기 측정"

우리는 이곳에 업무 예상 시간을 기입하기로 했다. 이 예상 시간을 기준으로 서로의 할당량을 공평하게 분배할 수 있을 것 같았기 때문에.

story point를 설정하며 다음과 같이 요약해서 업무 예상시간을 볼 수 있다

 

개인 이슈는 아래와 같이 할 일, 진행 중, 완료 3단계로 나누었다. 초반에는 pending도 만들어서 관리했었는데 pending으로 넘어가는 태스크가 우선순위에 자꾸 밀려나면서 루즈해질 때가 많아 pending은 삭제했다. 진행 중에도 두 가지 이상의 태스크가 쌓이지 않도록 권유했다.

3단계로 이슈 상태로 관리

 

 

app을 사용한 외부 툴 연동

지라의 장점으로는 깃허브 연동인데 지라 내에서 app을 다운 받아 연동할 수 있다. 깃허브 연동 외에도 다양한 app이 있긴 했다.

 

여러 app 연동해서 쓸 수 있다.

 

 

JIRA로 프로젝트를 진행하며..

결과적으로 우리 팀은 비교적 널널하게 프로젝트를 완수했다. advance로 남겨뒀던 반응형도 만들고 랜딩페이지도 만들었으니. 각자 알맞게 맡은 업무가 있으니 개인 시간 관리도 잘 되었다. 팀원들은 맡은 태스크를 완료하지 못하면 주말에도, 밤을 새우면서까지 스프린트 내에 완수하려고 애썼다. 개발 업무 태스크 분배를 관리자 입장에서는 처음 해봤지만 나름 성공적으로 완수했다고 자체 평가한다!