Linear — 이슈 트래킹 시스템의 위계 구조는 어떻게 설계되어야 할까?
참여하고 있는 SaaS 디자인 스터디 그룹에서 이슈 트래킹 시스템(ITS; Issue Tracking System) 주제 하에 그룹 세션을 진행했다. 우리 팀의 경우 리니어를 프로덕트로 선정하여 다각도로 리서치하였는데, 그 중에서도 ‘리니어의 위계 구조 분석’을 중심으로 내용을 공유하고자 한다. 본 글은 Jiyu님의 포스트에 이은 후속 글로 작성되었습니다 :)
Table of Contents
1. 리니어(Linear)란?
2. 리니어의 위계 구조 분석
3. 리니어를 통해 느낀점
4. 마지막 스터디 회고
1. 리니어(Linear)란?
리니어는 디지털 프로덕트를 만드는 기업 혹은 그룹을 위한 이슈 트래킹 시스템(이하 ITS)이다. Jira, Asana, Azure Boards 등 많은 ITS가 시장에서 경쟁하고 있는데, 리니어의 차별점은 ‘철학’을 지니고 있다는 것이다.
대부분의 ITS는 ‘전략’을 사용한다. “심리스하게 일하세요”, “모든 구성원들을 트래킹 하세요”와 같은 구호들에서 볼 수 있듯이 이들의 궁극적인 목표는 유저의 스프린트 몰입이다. 하지만, 리니어에서는 스프린트 혹은 PI(Performance Indicator)를 찾아볼 수 없다.
Create momentum — don’t sprint
We should find a cadence and routine of working. In cycles, we decide priorities and assign responsibilities. Our goal is to maintain a healthy momentum with our teams, not rush towards the end.
- Principles of Linear Method
리니어는 유저들이 경주마처럼 업무에 돌진하기보다는, 이슈의 우선순위를 구별하여 효율적인 업무 사이클을 구축하기를 바라기 때문이다. 이는 소수의 관리자가 할 수 있는 일이 아니기 때문에 구성원 모두가 함께 사이클을 만들어 나가야 한다는 의미이기도 하다. 따라서 리니어는 프로덕트 매니저 중심의 이슈 분담 툴이 아닌, 모든 개별 크리에이터 기반의 이슈 트래킹 툴이라고도 할 수 있다.
그런데, 실제로 리니어를 사용해보면 이러한 철학을 온전히 체감하기 쉽지 않을 수 있다. 나와 우리 리서치 크루들의 반응도 그러했다.
리니어를 사용하면서 느낀 점은 — 1) 인터페이스가 깔끔하다 2) 그럼에도 뭔가 어렵다 — 두 가지였다. 평소 다른 리서치보다 온보딩이 어렵게 느껴졌고, 프로덕트의 위계 구조가 설계적으로나 시각적으로나 분명하지 않다는 생각이 들었다.
일주일 동안 사용한 뒤에 크루들과 의견을 나누었을 때 모두 비슷한 인상을 받았다는 사실을 발견했고, 개인 리서치 소주제를 ‘리니어의 위계 구조 분석’으로 설정하게 되었다.
첨언) 온보딩이 힘들었다고 표현했지만 사실 리니어는 온보딩을 착실하게 제공하고 있다.
- 요즘 단순히 툴팁 이상으로 제품의 특성을 살려서 매력적인 온보딩을 제공하는 프로덕트들이 늘어나고 있는데, 리니어 역시 ITS의 속성을 잘 활용했다. 10 개나 되는 온보딩 ‘이슈’를 계속 화면에 남기고 싶지 않다면, 빨리 읽고 이슈의 상태를 ‘Todo’에서 ‘Done’으로 바꿔야 한다.
2. 리니어의 위계 구조 분석
1) Workspaces, Teams, and Issues
기본 구조는 크게 ‘워크스페이스, 팀, 이슈’의 3가지 요소로 구성되어 있다. 일반적으로 SaaS에서 팀이나 이슈라는 워딩이 생각보다 많이 쓰이지 않아서 어색할 수도 있는데, 각각 채널, 태스크의 개념으로 해석하면 된다. 여기서 주목할 만한 점은 어느 팀에도 속하지 않게 이슈를 만드는 것은 불가능하다는 점이다.
2) Clustering issue
생성된 이슈는 여러 가지 클러스터로 묶이게 되는데, 이 클러스터에서 다양한 기능들이 파생되면서 최종적으로는 완성된 프로덕트의 형태를 띠게 된다. 결국 어떻게 클러스터링을 하느냐가 어떤 성격의 ITS를 만드는지, 얼마나 완성도 있는 프로덕트를 만드는지를 결정한다고 볼 수 있다.
3) Clustering methods
그렇다면 리니어는 어떤 기준으로 이슈를 클러스터링 하고 있을까? 우선 리니어의 모든 화면을 수집하고, 각각의 화면에서 사용되는 기능을 다시 나름대로 분류해 보았다.
✔ Properties of Issues; 이슈가 지닌 속성에 따라
- Status — backlog, todo, in progress, done, canceled
- Priority — urgent, high, medium, low
- People — assignee, creator, subscriber
- Labels — ex)feature, bug, reference…
- Date — created date, updated date, due date
✔ Views for Issues; 보는 방식에 따라
- List view
- Kanban board view
✔ Roadmap; 로드맵 길이나 형태에 따라
- Milestone — projects
- Project — archived, active, closed projects
- Cycle — archived, active, upcoming cycles
✔ Private; 사용자 개인의 공간에 따라
- Inbox
- Views
- My issues — assigned, created, subscribed issues
4) SNB(Side Navigation Bar)
책의 전반적인 내용을 파악하고 싶다면 목차를 읽듯, 프로덕트를 한눈에 파악하고 싶다면 네비게이션 바를 보면 된다. 네비게이션 바는 제품의 위계 구조를 가장 잘 보여주는 부분 중 하나이기 때문에, 리서치한 클러스터링 방식을 SNB에 적용하여 분석해 보았다. 먼저, SNB의 구성 요소는 다음과 같다.
워크스페이스 이동과 이슈 생성(CTA)가 가장 상단에 있고, 그 아래에 각 계정만의 Private zone이 위치한다. 팀은 가장 액션이 많이 일어나는 공간인데, 각각의 토글 버튼을 누르면 하위 메뉴가 등장한다. 마지막으로 멤버 소개, 가이드북, 플랜 업그레이드 등의 단일 기능이 하단에 위치한다. 단일 기능은 위계 구조와 큰 관련이 없기 때문에 분석에서는 Private zone과 Teams를 중점적으로 다루었다.
총 14 가지의 메뉴를 나열하고, 메뉴 각각이 어떤 클러스터링 방식에 해당하는지 살펴보았다. 이런 식으로 거꾸로 추적해보니 리니어를 처음 봤을 때의 직감적인 감상이 선명해졌고, 몇 가지 발견점을 정리할 수 있었다. 각 메뉴의 실제 화면 이미지를 함께 보는 것이 이해가 수월하지만 포스트가 너무 길어질 것을 우려하여 이미지 대신 각 메뉴에 대한 간단한 정의를 발견점 아래에 작성하였다.
[ 발견점 ]
- Inbox, My issues, Views 모두 나만의 체크리스트 또는 알림 창이라는 가벼운 느낌이 드는 한편, 바로 밑에 있는 Roadmap은 거대하고 무겁게 느껴진다. Roadmap에 있는 Milestone은 워크스페이스에서 가장 큰 단위의 기능이자 시간 길이이다.
- 같은 준위의 메뉴를 보았을 때 — 예를 들어, Backlog, All, Board — 동일한 클러스터링 방식을 사용하는 것이 아니라 다양한 방식이 혼재되어 있다.
- Issues, Backlog, All이라는 명칭이 기능의 모호함을 만든다. 리니어에서 Issues 메뉴는 해야 할 이슈와 진행 중인 이슈를 의미한다. Backlog는 미래에 진행하기로 미뤄둔 이슈, All에는 앞의 세 가지 이슈에 완료된 이슈와 취소된 이슈를 합한 모든 이슈가 포함된다.
- Board의 존재가 예외적이다. 보는 방식에 따라 분류한다면 Issues — list view, kanban board view의 구조가 적당하고, 혹은 이슈의 상태에 따라 분류하여 Issues, Backlog, All의 세 가지 구조를 띠는 것이 자연스럽다.
- Cycles는 Active, Upcoming 메뉴가 있는 반면, Projects의 Active/Closed 기능은 메뉴가 아닌 화면 내의 탭 바로 구현했다.
- Issues, Cycles, Projects, Archive가 상위 항목이고 Backlog, All, Board, Active, Upcoming이 하위 항목임에도 불구하고 시각적 구별이 부족하다.
[ 각 메뉴 추가 설명 ]
- Search : 이슈 검색 창
- Inbox : 내가 태그된 이슈 모음
- My issues : 나와 관련된(assigned, created, subscribed) 이슈 모음
- Views : 이슈 트래킹 필터를 커스텀 하여 구독
- Roadmap : 모든 팀의 프로젝트 타임라인
- Issues : Todo 이슈와 In progress 이슈
- Backlog : 백로그
- All : 모든 백로그와 이슈 보기
- Board : 모든 백로그와 이슈 칸반보드 뷰로 보기
- Cycles : 단기 타임라인 설정
- Active : 현재 사이클
- Upcoming : 예정된 사이클
- Projects : 해당 팀의 프로젝트 타임라인
- Archive : 이슈, 사이클, 프로젝트 보관
3. 리니어를 통해 느낀점
위계 구조 분석을 통해 발견점을 정리해 보았지만 실제로 얼마나 많은 유저들이 이 발견점을 진짜 패인 포인트로 느끼는지는 알 수 없다. 다만 개인적으로 느꼈던 불편했던 점의 근거를 발견해서 속 시원한 마음으로 리서치를 마칠 수 있었다.
이슈 트래킹 시스템에서는 이슈를 생성하는 기능도 중요하지만, 그렇게 쌓인 이슈들을 보여주는 방식이 결국 프로덕트의 성격과 완벽한 위계 구조를 결정한다고 언급했다. 결론적으로 리니어가 이슈를 보여주는 방식은 아쉽지만 그들의 철학을 온전히 제품에 반영하지 못했고, 구조적으로도 완벽하지 않았다. 하지만 이런 결과에도 불구하고 리니어를 응원하게 되는 것은 철학을 프로덕트에 담고자 하는 의지가 진심으로 느껴지기 때문이다.
The issue tracking tool you’ll enjoy using
리니어는 이슈를 정리하는 툴이 아닌 이슈를 해결하는 툴, 매니저로서가 아닌 크리에이터로서 사용하는 툴, 스프린트가 아닌 사이클을 구축하는 시스템을 만들고 있다. 어느 프로덕트보다 생산적이고 논리적인 SaaS의 세계에서 행복한 시스템을 꿈꾸는 모습이 인상적이고, SaaS에 대한 발상의 전환을 할 수 있었다.
혹시나 ITS 사용을 고민 중인 기업이나 그룹이 있다면 한 번쯤 다운로드해 보시길 추천드린다. 이 포스트에서 소개하지 못한 내용이 많은데, 다양한 기능 커스텀이 가능하고 디테일이 굉장히 많다.
4. 마지막 스터디 회고
스터디 크루들에게,
스터디하는 동안은 평어를 사용해서 이렇게 존댓말로 말하는 게 어색하지만… 우연한 기회로 페이스북 그룹에서 스터디 모집 글을 보고 조인했는데, 덕분에 알찬 봄, 여름을 보냈습니다. 다들 디자인 불모지에서 매일같이 열심히 일하고 공부하는 모습을 보면서 좋은 에너지를 많이 받았고, 저도 제가 가진 얕은 지식이나 경험이나마 공유할 수 있어서 뿌듯할 때도 있었어요. 계획했던 스터디는 이제 모두 마무리되었지만 앞으로도 종종 함께합시다 :)
