기존 ‘크몽 개발팀 Jira 사용기’에 이어 ‘극대화 편’을 준비하였습니다. 이전 글을 아직 보지 못하신 분은 아래 링크를 참고해 주세요.
크몽 마켓은 다양한 분야의 프리랜서 재능을 만나 볼 수 있는 서비스로 누적 거래 완료 건수 304만 건, 누적 회원 수 217만 명 이상의 국내 №1 프리랜서 마켓입니다.
크몽의 조직 문화는 ‘Work Happy’의 비전을 가지고 행복하고 즐겁게 일하는 것이며, 회사의 규모가 커진다고 해서 프로세스와 정책을 늘리기보다는 역량이 뛰어난 직원 스스로가 결정하는 문화를 만들어 가고 있습니다.
또한, 개발 조직의 규모가 점점 커지면서 효율적으로 조직이 운영될 수 있도록 많은 변화와 시도를 하였습니다. 그 중의 하나가 2020년 Jira를 도입한 것인데요. 이후에도 개발 조직은 더 커졌고 앞으로 더 커질 것을 예상하여 좀 더 유연하게 업무를 수행할 수 있도록 Jira의 사용성을 개선하게 되었습니다.
Jira 사용성 개선 계획
기존에도 Jira를 잘 사용하고 있었지만 좀 더 잘 사용해보고자 하는 의견이 많았습니다. 그래서 간단하게 Task를 정리하여 계획을 작성하였습니다.
- 현재 Jira 사용 분석
- 이슈 유형/워크플로우/이슈 화면 정리
- 이슈 유형/워크플로우/이슈 화면 재정의
- 보드 구성(메트릭)
- 리뷰 및 피드백 반영
- 모니터링 및 개선 활동
첫 번째, 무엇인가를 개선하기 위해서는 분석 활동이 매우 중요합니다. 무엇이 잘 되고 있는지 혹은 무엇이 부족한지를 판단하는 중요한 근거 자료를 발견할 수 있기 때문입니다.
현재 Jira를 어떻게 사용하고 있는지 Admin 권한을 받아서 살펴보았고 Jira 활용도가 높은 구성원의 인터뷰를 통해 평소 불편한 점과 좀 더 잘해보고자 하는 부분을 듣고 정리하였습니다. 이와 더불어 어떻게 구성하는 것이 좋을지 제 생각과 지식 또한 정리하고 공유하였습니다.
두 번째, 기존 Admin 페이지에는 사용하지 않는 일명 쓰레깃값들이 관리되고 있지 않았습니다. 앞으로 체계적인 관리를 위해서는 불필요한 값들을 선 정리하는 작업이 필요했습니다.
Jira의 강점 중의 하나는 삭제 시 유효성이 동작한다는 점으로 매우 논리적으로 구성되어 있기 때문에 그냥 삭제할 수 있는 데이터는 아무도 사용하지 않는다는 의미이기도 합니다.
세 번째, 인터뷰를 통해 얻은 결과물을 통해 이슈 유형/워크플로우/이슈 화면을 재정의합니다. 사용성 개선 활동의 가장 핵심적인 부분입니다.
네 번째, Jira를 사용하기 위한 속성값이 모두 정의되면 보드를 구성합니다. 보드 구성은 업무의 효율성을 극대화할 수 있도록 구성해야 합니다. Jira에서는 효율성을 최대화하기 위해 다양한 보드를 지원하는 것이 이런 연유에서입니다.
마지막으로 적용된 영역에 대해서 기존 구성원들에게 공유하고, 리뷰합니다. 그리고 피드백을 받아서 추가로 개선하거나 정해진 부분을 프리징합니다. 바로 모든 것을 포용할 수 없기 때문에 지속해서 모니터링하는 것도 개선 활동의 매우 중요한 부분입니다.
현재 Jira 사용 분석
#1 크몽팀의 조직 구성
크몽팀의 조직 구성은 이외에도 다른 부서가 있지만 현재 크몽 마켓을 개발하고 운영하는 부서의 모습입니다. 특이한 점은 목적 조직(Team)과 기능 조직(Chapter)으로 구분되어 있으면서 유연한 업무를 수행하기 위해 메트릭의 구조로 되어 있는 것인데요.
이번에 Jira 사용성을 높이고 더욱 유연하게 업무를 수행할 수 있도록 Jira 보드 구성에 크몽팀의 메트릭을 구성해 보았습니다.
#2 마인드맵 활용
Team과 Chapter 사이의 유기적인 관계를 이해하기 위해서 항상 마인드맵을 활용하였습니다. 평소 알마인드만 사용하다가 이번에 처음 검색해서 GitMind라는 걸 사용해 보았는데 테마도 많고 좋았습니다. 필요하시면 한 번 사용해 보시길 바랍니다.
가장 고민을 많이 했던 부분은 스크럼 보드와 칸반 보드의 구분입니다. 기존 사용하던 보드를 참고해서 스프린트 관리 여부를 확인 했습니다. Team은 스프린트 보드를 매우 잘 활용하고 있기 때문에 스크럼 보드로 구성하고, 좀 더 유연하게 업무를 수행하는 Chapter는 칸반 보드로 구성하기로 결정하였습니다.
마인드맵에서 추가적으로 확인 가능한 정보는 Operation Team에서 생성하는 VOC 이슈에 대한 각 Team 별, Chapter 별 업무에 대한 Co-work 노드를 확인할 수 있습니다.
#3 인터뷰
Jira 개선을 위해서 많은 분들이 다양한 의견을 주셨습니다. 이런 의견을 바탕으로 개선 방향성을 세우고, 세워진 방향성을 기준으로 Jira를 구성하게 됩니다.
이와 추가적으로 Jira의 사용성 개선을 위해 평소 알고 있던 지식과 고민하던 부분을 공유하여 인터뷰 시에 도움이 되는 정보를 정리하였습니다.
이슈 유형/워크플로우/이슈 화면 정리
기존에 Admin은 생성하고 삭제나 변경에 대한 관리가 되지 않았습니다. 새로운 이슈 유형이나 워크플로우, 그리고 이슈 화면을 생성하고 사용하기에는 매우 복잡한 상태였습니다.
대부분 Jira를 사용하는 기업의 Admin은 비슷할 거라 생각합니다. 생성과 변경만 하고 사용자 익명화와 같은 정리 작업을 하지 않기 때문입니다.
그래서 기존 사용하던 이슈 유형, 워크플로우, 이슈 화면을 Old Scheme로 구성하여 한 곳에 모아두는 작업을 하였습니다. 이렇게 작업할 때 좋은 점은 사용자들은 바뀐 것도 모르고 업무를 수행하는 데 아무런 영향이 없으면서 정리가 가능한 방법입니다.
사용하지 않거나 불필요한 항목을 삭제해야 하는 경우는 삭제 가능 여부를 판단하기 위해서 해당 이슈 유형이나 워크플로우를 직접 사용하는 구성원에게 개별 문의를 해야만 했습니다. 자칫 잘못 삭제하게 되면 현재 업무에 영향을 줄 수 있기 때문에 삭제 작업을 할 때는 꼭 현재 사용 중인지 미사용 중인지를 확인하고 삭제하시기 바랍니다.
이슈 유형/워크플로우/이슈 화면 재정의
#1 이슈 유형 재정의
이슈의 유형은 업무의 방식에 따라 직관적으로 확인할 수 있도록 재정의하였고, 이슈 유형만 보더라도 어떤 업무인지 알 수 있도록 하였습니다.
#2 워크플로우 재정의
이슈의 유형에 따라 워크플로우를 재정의하였고, 비슷한 워크플로우는 통합하여 사용할 수 있게 Scheme 작업을 하였습니다.
워크플로우 구성 시 하나 더 고민했던 점은 이슈를 Resolved 할 때(상태가 변경될 때) 필수 입력받도록 팝업을 띄우는 것이었습니다. 그래서 주요 스테이터스가 변경되는 시점에는 상태 변경에 대한 트리거(팝업)를 삽입하여 필수 입력을 받을 수 있도록 구성하였습니다.
필수 입력에 대한 선택은 내부적으로 꼭 입력되어야 하는 약속된 값이고, 향후 Jira Report나 Dashboard에서 의미 있는 데이터로 활용하기 위함입니다.
#3 이슈 화면 재정의
이슈 화면 재정의는 선택 사항입니다. 해도 좋고 안 해도 되지만 사용성을 높이기 위한 목적이라면 반드시 해야 합니다. 이슈 유형에 따라 보이는 카테고리를 조사하고 이슈 등록 시 필요한 카테고리만 보일 수 있도록 구성하는 것입니다.
그리고 입력 카테고리는 기본 입력과 옵션으로 구분하는 것이 좋습니다. 필수 입력에 대한 기본 입력만 설정하면 향후 이슈 수정 시 카테고리가 안 보일 수 있기 때문에 옵션에는 반드시 카테고리가 있어야 합니다. 이슈 등록 시에는 탭으로 보이게 구분할 수 있습니다.
보드 구성(메트릭)
‘프로젝트의 보드를 어떻게 구성해야 메트릭 형태로 구성할 수 있을까?’
이슈 유형을 재정의하고 워크플로우도 재정의하면서 보드 구성에 대한 고민을 지속해서 했습니다. 왜냐하면 크몽팀의 조직 구성이 메트릭 구조이기 때문에 프로젝트를 이동하지 않으면 나의 할 일(Backlog)이나 Co-work 티켓을 확인할 수 없기 때문인데요.
하지만 아주 간단한 방법으로 문제를 해결할 수 있었는데 그것은 바로 Jira 프로젝트 내의 보드 추가 기능을 통해서입니다.
먼저, 분석에서 확인된 보드의 유형에 따라 프로젝트를 생성합니다. 크몽팀은 스크럼 프로젝트 6개(Team), 칸반 프로젝트 6개(Chapter)를 생성하였습니다. 메트릭의 구조상 12개의 프로젝트 내에서 유연하게 업무를 수행할 수 있도록 구성할 방법이 필요했습니다.
그래서 Team 스크럼 프로젝트 내에 Chapter 칸반 보드를 추가하였습니다. 예를 들어 A Team 보드에는 6개의 Chapter 보드를 볼 수 있도록 추가하고, B Team 보드에도 6개의 Chapter 보드를 볼 수 있도록 추가한 것입니다.
이렇게 구성하기 위해서는 보드 내의 필터를 약간 수정 해야 합니다. 특히, 키 값과 같은 역할의 구분자를 사용해야 하는데 크몽팀의 경우 Team 명과 Chapter 명을 구분자로 사용하였습니다.
구분자를 해당 Team이나 Chapter의 구성원으로 해도 되지 않느냐? 는 질문을 받은 적이 있습니다. 물론 상관없습니다. 충분히 가능합니다. 하지만 사용자의 경우 들어오고 나가고의 변수가 작용하기 때문에 향후 관리에 대한 문제가 발생할 수 있는 점은 참고 바랍니다.
결과적으로 모든 Team 프로젝트에서는 Chapter 보드의 업무를 볼 수 있게 되었고, Chapter 보드에서는 Team 업무(Team의 구분 없이 자신이 해야 할 일)를 볼 수 있게 되었습니다. 별도의 프로젝트를 이동하지 않아도 유연하게 서로의 업무의 상태를 공유할 수 있게 되었습니다.
리뷰와 피드백을 받은 내용은 따로 언급하지 않겠습니다.
현재도 진행 중이고 앞으로도 많은 부분이 개선될 것이기 때문인데요. Jira를 메트릭 형태로 구성하는 것은 저에게도 큰 도전이었고, 잘 될지 안 될지 모르는 상황이었지만 믿고 적극적으로 피드백 주신 크몽팀이 있었기에 좋은 결과물이 나올 수 있던 것 같습니다.
추가로 현재 버전 관리에 대한 문제점이 발견되었습니다. 이는 Jira의 정책상 모순되는 부분이라 Admin 내에서 해결할 수 없습니다. 메트릭 구조상 Product Team에서 버전을 관리하는 것이 맞는다고 생각했는데 업무를 수행하다 보니 실질적으로 Chapter 내에서 빌드/배포를 수행하고 있었기 때문입니다.
그래서 이 부분은 현재 Jira Work Automation으로 문제를 해결한 상태이고 테스트를 진행하고 있습니다. 문제 해결에 대한 자세한 내용과 추가로 개선된 내용은 ‘응용 편’에서 찾아뵙도록 하겠습니다.
긴 글 읽어 주셔서 감사합니다.😊
