Jira 도입 리뷰

회사 업무에 Jira를 도입한 지 반년이 돼가고 있어 도입하기 전과 도입 후를 비교하고자 합니다.

 

도입 전

기획을 누가 하는지에 대해서는 3가지로 나뉘었습니다.

• 타 팀 관리자 혹은 디자이너
• 개발자
• 기획자

타 팀에서 기획을 하는 경우 어떤 팀에서 하느냐에 따라 포맷이 제각각이고 같은 팀에서 유사한 페이지를 기획하더라도 누가 하느냐에 따라 기획서 퀄리티가 나뉩니다. 여기서 말하는 퀄리티는 소프트웨어 아키텍처 관점에서 봣을때 기능 명세나 프로세스가 명확한 수준을 말합니다.

 

꼭 그렇다는 건 아니지만 타 팀의 기획으로 업무를 할 경우 기획한 사람과 소통할 일이 잦습니다. 왜냐하면 그들은 개발에 대한 지식이 없고 디테일하게 명세해 주는 경우가 드물기 때문입니다. 팀에 PM이나 기획에 대한 전반적인 지식이 있는 사람이 없다면 개발자가 직접 커뮤니케이션해야 하기 때문에 개발에 온전히 집중하기 어렵습니다.

 

개발자가 직접 기획하는 경우는 보통 개발단의 개선 작업이나 데이터 이관 작업이 대부분일 것입니다. 보통 개발자들은 꼼꼼한 편이기 때문에 프로젝트 전체적인 관점에서 기획을 하는 경우가 많으며 기존 기능에 대한 이해가 높은 편입니다. 다만 본인이 파악하고 개선하고자 하는 부분을 타 팀에게 공유하지 않고 당연히 알거라 판단하고 기획하는 경우가 있는데 본인이 다 파악했더라도 그 기능을 쓰고 있는 타팀에게 검토를 요청하는 건 굉장히 중요합니다.

 

기획자가 하는 기획 기획은 당연히 기획자가 하는 게 맞는 것입니다. 기획자가 지켜줄 건 2가지입니다. 기능을 사용할 실무자와의 커뮤니케이션, 개발할 기능에 대해 개발자에게 기능 검토를 확실하게 받는 것입니다. 기획자는 항상 실무자와 개발자 중간에서 조율해야 하는 위치입니다. 본인이 한 기획에 대해 여러 피드백이 올 수도 있지만 그 피드백 중에서 옳고 그름을 판단하고 최선의 기획을 만들어 내는 걸 목적으로 해야 합니다.

 

가끔 기획서가 없는 기획이 생기는 경우가 있습니다. 

• 구두
• 메일
• DM

위에 적은 3가지 때문에 Jira를 도입하게 되었다고 봐도 문제없습니다. 실제로 현업에서 일의 중요도와 상관없이 기획서가 작성 안 되는 경우가 있습니다. 이럴 경우에 과거 히스토리 파악이 안되는 케이스가 계속 발생하고 역기획까지 고려하게 됩니다.

 

도입 후

Jira는 도입 후에 개발된 프로젝트 기능에 대한 기록과 업무 관리에 탁월한 역할을 해내었습니다.

 

특히 하나의 간단한 업무라도 Ticket으로 생성하여 기록으로 남긴다는 점은 이후 유지보수 차원에서도 도움이 될 것입니다.

현재 저희 팀에서는 이렇게 jira를 이용합니다.

 

2주 간격의 스프린트를 두고 스프린트 기간 동안 진행할 업무를 분배한 다음 각각의 티켓을 개발, QA후 배포하는 과정을 거칩니다. 어떤 업무는 2주의 스프린트 기간이 모자라는 경우도 있는데 이럴 경우 여러 번의 스프린트를 거쳐도 괜찮습니다.

 

티켓 생성은 기획자가 전담하며 업무 발의를 통해 들어온 업무 중 이번 스프린트나 다음 스프린트 때 진행해야 할 업무들을 jira ticket으로 생성해 백로그에 보관하며 현재 스프린트가 끝나기 전부터 기획에 들어가 기획이 완료되면 스프린트 칸반 보드에 추가합니다.

기능적인 에러가 발생한 경우 개발자가 직접 에러 티켓을 생성하여 작성합니다.

 

티켓 작성 시 누구나 알 수 있게끔 하며 글을 간결하게 작성하는 것보다는 최대한 자세하게 설명하는 게 중요합니다. 왜냐하면 jira ticket을 개발자가 작성할 경우 개발자만 아는 언어로 작성하는 경우가 있는데 jira ticket은 개발자만 보는 게 아니라 디자이너, 기획자, 마케터도 봐야 하는 하나의 문서이기 때문입니다.