프로덕트 매니저의 Jira 도입기
23.07.04 (화) Corca Product Manager
팀의 규모가 커지면서, Task 분배나 진행 상황을 보다 잘 파악하고 매니징하기 위해 올해 2월부터 Atlassian의 Jira를 도입하여 적극 활용하고 있다.
회사나 팀 별로 Jira를 활용하는 방법도 정말 제각각인데, 우리 회사에 적용한 것들 위주로 소개하니 참고 바람!
도입 배경
빠르게 성장하고 있는 스타트업이지만, Task 관리가 원활하게 이루어지지 않고 있었다.
기존에는 개발 현황을 파악하는 Tech Status Board와 도입이 필요한 기능들을 정리해두는 추가 기능 페이지를 Notion에서 각각 관리했다.
기존에 활용하고 있었던 노션 페이지하지만 노션으로 프로덕트의 task를 관리하는 것은 여러 문제점을 동반했다.
1. Task 생성의 문제점
PM 팀에서 task를 생성하더라도 Tech 팀에서 즉각적으로 진행 가능한 task로의 변환이 seamless 하지 않다는 문제점이 있었고,
그래서 Dev Lead 혹은 Tech Lead가 업무를 진행 가능한 단위로 분류하고 다시 담당자 분배 및 지정하는 과정에서 리소스가 많이 들고 있었다.
2. 진행 상황 팔로업의 어려움
PM도 해당 task가 어떻게 Tech 팀의 업무로 정리되어 있는지, 개발 진행 상황을 파악하기 어렵고 매번 직접 확인한 후에 Notion Status를 업데이트 해야한다는 문제점이 있었다.
3. Task간 위계의 불분명함
각 업무들의 relation을 작성할 수는 있으나 직관적으로 task의 위계를 구분하기 어려웠고,
노션의 task 목록과 깃헙이 연동되지 않는다는 문제점이 있었다.
활용 (1) 스프린트
우리 회사는 스프린트를 2주로 지정하여 관리하고 있다. 할 일을 쌓아두는 곳인 백로그에서 앞으로 2주 동안 진행해야 하는 task를 스프린트에 포함한다. task들이 모두 포함되면 스프린트를 시작한다. 스프린트가 진행되는 중에 백로그에 있던 일을 시작하게 되는 경우, 해당 스프린트에 자율적으로 포함할 수 있다.
스프린트가 끝나면 종료된 이슈들은 closed 처리 하고 (이후 Workflow에서 자세하게 다룰 예정!) 진행 중이거나 시작하지 못한 이슈들은 다음 스프린트로 이관한다.
스프린트 업데이트와 이슈 정리는 아래 사진처럼 PM 팀에서 관리하고 있다!
스프린트가 종료된 후 채널에 업로드한 업데이트 내용활용 (2) 보드
활성화 된 스프린트에서 진행 중인 task의 진행 현황은 보드에서 확인할 수 있다! 스프린트나 에픽, 레이블 별로 필터링 하여 볼 수 있어 활용도가 높다.
진행 중인 스프린트 현황을 파악할 수 있는 보드활용 (3) Workflow
지라를 통해 각 팀이 task를 진행하는 절차와 방법에 대해 커스터마이징 할 수 있는데, 우리는 처음 도입했을 당시에 TO DO → IN PROGRESS → DONE 이렇게 3단계로 아주 간단하게만 운영하고 있었다.
하지만 활용하다보니 지정할 수 있는 Status가 한정적이라 여러 문제점들이 발생하고 있음을 파악하였다.
1. Review 기능이 없어서 '정말로'해결이 된 이슈인지, 재작업이 필요한지 구분이 되지 않고 있음
2. 배포 여부와 개발 / 프로덕션 서버에 반영되었는지 확인이 어려움
3. Task가 생성되고 우선순위나 진행 필요 여부를 파악하는 과정이 포함되지 않음
이러한 문제점을 극복하기 위해 다른 기업들의 케이스나 Worlflow 템플릿을 참고하며 우리의 Worlflow를 만들었다!
A라는 task가 필요한 경우, 스토리/버그 중 종류를 선택하여 생성한다. A task를 등록한 사람은 보고자/Reporter로 저장된다.
담당자가 이미 있는 경우, 담당자를 지정한 후 task를 ‘OPEN’한다.
하지만 담당자가 아직 정해지지 않은 경우에는 공란으로 두었다가, 담당자가 정해지면 그때 task를 ‘OPEN’한다.
담당자가 task를 인지하는 시점에 ‘TO DO’로 상태를 변경하고, 시작하는 경우 ‘IN PROGRESS’로 업데이트 한다.
담당자가 task를 완료하면 ‘RESOLVED’ 상태로 변경하고, QA 테스터나 코드 리뷰어를 담당자로 지정한다.
담당자가 해당 task를 확인하면 ‘DONE’으로 업데이트 하고, 오류나 수정 필요한 사항이 발견되면 ‘REOPEN’으로 상태를 변경하고 원래 담당자로 다시 지정한다.
모든 task가 완료되고 배포되게 되면, Product Manager가 최종 상태인 ‘CLOSED’로 상태를 변경한다.
활용 (4) 기타
1. 개발 완료 여부 확인 알림
담당자가 task를 진행한 후, merge 되고 나면 QA 테스트가 가능한 링크가 자동으로 해당 이슈에 댓글로 등록된다.
그러면 담당자가 QA 테스트를 진행한 후, 해당 이슈를 ‘Done’ 상태로 변경하고, 이후 배포가 완료되면 담당 Product Manager가 이슈를 ‘Closed’ 상태로 변경한다.
QA 테스트 가능한 링크가 comment로 첨부된 사진2. 레이블 활용
여러 컴포넌트를 동시에 개발하다 보면, 페이지뷰나 기능 단에서도 task를 구분해야 하는 일들이 발생한다.
이럴 때에는 에픽이나 스토리/버그의 하위 이슈로 묶어서 관리하기 보다, ‘레이블' 기능을 활용하면 보다 직관적인 분류가 가능해진다.
아래 사진처럼 분류하면 레이블로 filter 하여 task를 조회할 수 있고, 관리하기도 훨씬 편리해진다.
레이블 선택 화면3. 댓글에서 적극적인 소통
Jira는 이슈 별로 comment를 달고, 팀원을 태그할 수 있는데 이 기능도 효과적인 협업에 도움이 많이 된다.
담당자와 참조자가 지정되어 있어 질문을 해야 하는 사람이 명확하고, 질문 내용에 대해 답변 및 확인 해야 하는 사람이 뚜렷하기 때문이다.
그리고 댓글에 사진이나 링크 첨부가 가능해서 자료 공유와 정확한 문제 확인도 가능해진다!
우리 팀원들은 task에 대한 논의를 기존에는 Notion 혹은 Slack에서 많이 진행했었는데, 시간이 지나면 관련 내용을 찾기 어렵고 업데이트 사항도 분산되어 있었는데, Jira의 댓글을 통해 더 정확한 커뮤니케이션을 진행하고 있다.
댓글로 활발히 소통 중인 팀원들처음에는 기초적인 기능만 간단하게 활용하다가 여러 시행 착오와 팀원들의 다양한 피드백을 수렴한 결과, 우리 회사와 팀원들에게 잘 맞는 Jira로 자리잡게 된 것 같다!
팀원들도 협업이 더 편리해지고 업무 효율성이 증대되었다는 의견을 전해주었다!
PM팀의 티쥬 님은 하위 이슈와 댓글, 담당자와 Status 기능이 특히 도움이 많이 되었다고 말씀해주셨다!
Dev 팀의 Back-end Engineer 물개, 표범, 아기상어 님은 각자 담당하는 task를 분배하고 공유하기 편하다는 의견을 공통으로 남겨주셨다!
Dev팀 Full-stack Engineer 플라밍고 님은 이전 직장에서의 경험과 지라 활용법을 많이 알려주신 분이. Workflow가 잘 정리된 것 같다고 코멘트 주셨다!
Dev Lead 도마뱀 님은 지라 도입의 필요성을 먼저 인지하시고 적극적으로 활용하고 계신 분인데, 지라를 통해 업무 생산성이 향상되고 팀 내 협업이 더 효율적으로 잘 이루어지고 있다고 말씀해주셨다!
나도 매주 레슨런을 꾸준하게 쓰는 편인데(나중에 레슨런 글도 적어봐야겠다!), Jira랑 관련된 글을 몇 개 적었던 게 기억이 나서 찾아보니 2월 넷째주 레슨런에서 커뮤니케이션이 더 잘되는 것 같다고 적었고, 3월 셋째주에는 Workflow 수정하면서 점점 자리가 잡히고 있다고 느꼈었다!
기존에 일하던 방식에서 새로운 툴은 도입하거나, 변경한다는 게 쉬운 일은 아니다.
하지만 팀에 꼭 필요한 것이라면 팀원들을 설득하고, 팀에 잘 녹아들 수 있도록 시행착오를 거치며 다듬어 나가는 과정도 모두 Product Manager의 역할이자 역량이라고 생각한다.
이 툴이 얼마나 우리 팀의 효율과 협업에 도움이 되었는지 증명한거니까! 어려움에 부딪혀보는 용기를 얻은 것 같다! 무엇보다 잘 활용하고 있는 팀원들을 보면 뿌~듯~^,^
