들어가는 글
괜찮은 프로젝트를 만들고 싶다.
그리고 좋은 사람들과 함께 그 꿈을 향해 가고 싶다.
좋은 사람이 모여 좋은 조직이 되고, 좋은 조직이 모여 좋은 회사가 된다.
전체는 항상 부분의 합보다 크다. 그렇기에 좋은 조직이 곧 좋은 회사의 필요충분조건이 아닐 수 있다.
하지만 그것은 좋은 회사라는 ‘이상향’을 좇는 방법이 단순히 사람만이 있다는 게 아님을 방증한다.
괜찮은 프로젝트는 좋은 사람, 그리고 그 외의 또다른 무언가로부터 온다.
필자는 그 ‘또다른 무언가’에 관해 고민한다.
어떻게 하면 좋은 사람, 좋은 조직을 가지고 괜찮은 프로젝트에 한발짝 더 다가갈 수 있을까.
그 한 발짝을 내딛기 위해, 더 고민할 수 있는 게 무엇일까.
협업.
회사일은 하나부터 열까지 사람과 사람 사이의 관계 속에서 일어나는 협업의 연속성으로 구성된다.
협업을 개선해보자.
협업을 개선하기 위해, ‘협업툴’이라는 우리 모두를 위한 소소한 ‘복지’에 시선을 돌려보자.
그렇게 시작된 협업 시리즈는 이제 세 번째 글로 이어진다.
이번 글의 주제는 협업툴 Asana를 도입하기까지의 과정과, 그동안 필자가 고민해 온 요소들을 소개하는 글이 되겠다.
필자는 에세이를 그다지 좋아하지 않는다. 이번 글은 필자의 고생담(?)으로 시작하지만, 어느 순간부터 Asana라는 협업툴을 잘 쓰기 위한 몇 가지 팁도 함께 소개할 것이다.
더 나은 내일, 더 나은 협업을 위해 고민하는 모든 분들을 위해.
우리 회사 프로젝트 관리의 현주소
트렐로 환경의 미래
필자가 입사한 새 회사에서는 협업툴로 ‘트렐로’를 썼다.
트렐로는 협업툴에 관해서는 Notion만큼 잘 알려진 대중적인 툴이다.
하지만 Notion처럼 그 한계 또한 명확한 툴이기도 하다.
아니나 다를까, 필자가 회사에서 처음 만난 ‘트렐로’의 첫인상은 좋게 말해 최악이었다.
협업을 하기 위해 고생해 온 구성원들의 노고를 감히 폄하하려는 게 아니다.
퇴사자의 작업이 최상단에 올라와 있거나, 간트 차트 기능을 쓸 수 없는 불편한 구조로 짜여 있었다.
앞으로 트렐로를 쓰며 동료들과 함께 일할 때 그려질 어지러운 ‘미래’가 훤히 그려졌다.
복잡해집니다.
가장 먼저 필자의 눈에 들어온 건 감당하기 어려울 정도로 빽빽하고 보기 불편한 UI/UX였다.
트렐로는 5인 이상 ~ 10인 미만의 규모에서 사용할 때는 크게 문제되지 않는다.
그 말은, 10명이 넘어가는 순간 트렐로는 우리 모두를 지옥으로 안내하기 쉽다는 말이기도 하다.
우리 회사는 작은 스타트업이지만, 트렐로는 고작 20명이 넘어가기만 했을 뿐인데도 마치 수십 마리의 거미가 서로 엉킨 거미줄마냥 엉기성기 얽혀 있었다.
물론 트렐로가 단점만 있는 건 아니다.
트렐로의 장점은 유연한 칸반 보드의 운용 가능성이다.
가독성이 우수한 보드 뷰를 바탕으로, 각 팀원의 일감을 빠르게 확인하고 진행상황을 각 열(column)으로 볼 수 있는 게 트렐로의 핵심 강점이다.
하지만 우리 회사에서는 칸반 보드가 아니라 각 팀별로 각 열(column)을 사용하고 있었다.
이 경우 각 진행상황이 열 단위로 추적되지 못하고, 모두 각 일감(task)으로 들어가야만 확인할 수 있게 된다.
이렇게 써도 ‘쓸 수는 있다’. 하지만 쓸 수 있다는 것과 잘 쓰는 건 다르다.
물을 마실 때 젓가락으로도 마실 수 있다. 다만 지나치게 비효율적이기에 누구도 그러지 않을 뿐이지만.
트렐로 환경의 약점
사실 필자의 직무는 내러티브 디자이너다.
PM이나 기타 일정 관리 직책이나 직무와는 무관한 사람이다.
내러티브 디자이너는 평소에 협업해야 할 상대방이 참 많다. 위로는 회사 대표나 PD부터, 수평적인 관계로는 게임 디자인부터 아트, 프로그래밍까지 아우르는 폭넓은 ‘인싸력’을 요구한다.
필자는 인싸는 아니지만, 그러한 환경을 감내해야하는 필드 위에 서 있는 이상 원활한 협업을 위해 고민하는 게 습관이 배었다.
중요한 건 화두를 던지는 사람, 즉 ‘총대’가 필요했다.
필자는 그 총대를 자처하기로 했다.
트렐로를 쓰는 미래가 문제가 될 거라는 문제인식이 구성원 내 공감대가 형성된다면, 트렐로를 사용하며 고통받을지도 모를 안타까운 미래를 사전에 예방할 수 있지 않을까하는 희망을 품었다.
총대는 결국 고통을 받게 된다. 입사하고 처음 만든 PT가 바로 ‘Asana’ 도입에 관한 제안서였다.
이 수십 페이지의 PT는 트렐로가 가져올 미래, 그리고 그것을 구원하기 위해 우리가 어떻게 해야하는가하는 방향성을 제시한다.
아래는 필자가 사내에 ‘트렐로 환경의 약점’이라는 내용으로 발표한 슬라이드의 일부이다.
무위계성
각 Task는 중요도, 작업기간, 담당자 등 모든 요소가 다르지만 모두 똑같은 ‘카드’로 묶입니다. 한 마일스톤의 풀스펙을 한 눈에 보기가 어렵습니다.
파편화
트렐로는 주요 정보가 어디에 있고, 어떤 정보가 최신인지 알려주지 않습니다. 정보가 파편화되기 쉬워 최신 기획안과 파일을 찾기 어렵습니다.
비연결성
각 Task는 서로 독립된 개체이며 서로간의 위계나 연결성을 갖지 않습니다. 재현 가능성이 있는 버그나 이슈의 히스토리 파악이 어렵습니다.
필자가 진단한 문제점은 크게 세 가지였다.
이러한 문제점은 당장은 큰 문제를 발생시키지는 않지만, 시간이 갈수록 조직을 갉아먹게 된다.
이미 필자가 입사했을 때부터 일감의 ‘블랙박스화’가 감지되고 있었다.
팀에 정치꾼이 있는 게 아니라면 모든 팀의 일감은 투명하게 관리되어야 한다.
하지만 정치꾼이 없어도 ‘블랙박스’가 생길 수 있다. 협업툴이 ‘복잡할 때’ 이런 문제가 발생한다.
트렐로가 복잡해지면 사람들은 트렐로를 쓰지 않게 된다. 왜냐면 어렵고 귀찮기 때문이다.
사람은 일에 치여 바빠지면 협업툴이나 어떠한 HR과 관련된 일을 뒷전으로 하게 된다. 그래서 협업툴은 언제나 접근 가능해야하고 쉬워야하며 사용필요성을 사용자 스스로가 느껴야 한다.
일감이 추가나 갱신되지 않으면 점차 프로젝트 진행상황이 블랙박스화 된다.
누가 어느 일을 하는지 점점 혼란에 빠져들게 되면, 회사에서는 크게 두 가지 판단을 할 수밖에 없다.
“일을 많이 시켜서” 무언가 일이 진행되는 느낌을 받게 하거나, 아니면 더욱 엄격한 프로세스를 구축하거나.
어느쪽이든 지금 일하는 사람들에게는 회사 생활이 더 불편해진다는 단점이 있다. 특히 필자는 그런 결말이 좋은 쪽으로 흘러가게 된 것을 본 적이 없었다.
필자는 크런치 모드를 막고 싶었다. 누구도 알아주지 않을 것이지만, 필자는 입사했을 때부터 그런 사명감의 칼날 위에 서 있었다.
대안 모색, 후보군 리스팅
니즈 정의
필자는 어떤 협업툴이 우리 프로젝트의 상황에 가장 도움이 될지 모색하기 시작했다.
먼저 해야 할 일은 우리 프로젝트에서 앞으로 뭐가 필요할지에 관한 ‘니즈 정의’였다.
게임 회사에서는 주로 ‘일감 관리’, ‘버그 추적’, 그리고 ‘위키 기능’이 필요하다.
대부분의 회사에서는 아틀라시안이라는 협업툴 회사에서 제공하는 Jira(지라)와 Confluence(컨플루언스)를 사용한다.
하지만 모든 회사가 위의 협업툴을 사용하는 건 아니다.
회사마다 다른데, 버그 관리를 Redmine(레드마인)이나 Notion, Onenote, Slack으로 처리하는 회사도 있다.
어떤 협업툴을 어떻게 활용하는가에 관해서는 감히 맞고 틀렸음을 판단하기는 조심스럽지만, 그것이 과연 효율적인 방법인가를 물었을 때는 다소 고개가 갸우뚱해진다.
굳이 클라우드 저장소인 구글 드라이브를 두고, 슬랙으로 파일 버전관리를 하는 건 무슨 생각인 걸까?
필자는 트렐로를 포기하는 상황에서, 적어도 트렐로보다는 ‘버그 관리’가 더 편하다는 점을 어필할 필요가 있다고 느꼈다.
어차피 게임 개발은 곧 버그를 만드는 일이 될 것이고, 그 버그를 ‘잘’ 관리하는 툴이 있으면 모두가 편해질 거라는 생각이었다.
이런 식으로 필자는 버그 추적을 포함해, 트렐로의 ‘상위 호환’이 될 수 있는 툴들을 찾기 시작했다.
ChatGPT 활용
다른 업무를 병행하면서 협업툴 하나하나를 비교하고 정리하는 건 쉽지 않았다.
필자가 기본적으로 맡은 다른 업무(주로 내러티브와 관련한 것들)가 있는데, 내러티브와 전혀 무관한 협업 관련한 일에 너무 많은 일정을 사용하게 된다면 그야말로 주객전도인 셈이었다.
필자는 ChatGPT를 업무에 적극 활용하는데, 사용자가 똑똑하게 질문할수록 제대로 된 답변을 줄 확률이 높아 사용자가 잘 다루기만 하면 업무에 큰 도움을 받을 수도 있기 때문이다.
그래서 필자는 ChatGPT가 똑똑한 답변을 할 수 있도록 내가 원하는 것을 아래와 같이 간단명료한 리스트로 정리했다.
- 한국어를 지원할 것.
- 버그를 추적 및 관리할 수 있다. (일종의 지라)
- 팀 별로 각 작업자가 어떤 업무를 진행중인지 알 수 있다. (일종의 일정 캘린더)
- 타임라인 뷰 등으로 이번 주, 이번 달, 이번 마일스톤 등에 어떤 업무를 진행해야할 지 알 수 있다.
- 개개인의 일정 관리가 가능하다.
- 단순 반복 작업이 아니라, 어느 정도 자동화된 규칙에 따라서 템플릿을 생성할 수 있다. (업무 자동화)
- 위키 기능을 사용할 수 있다. (일종의 컨플루언스)
중요도는 위에서부터 아래의 순이다.
업무 자동화나 위키 기능은 업무 시간을 줄여주고 원활한 협업을 돕는 데에는 필요하지만, 그것을 위해서 비용을 들이자는 제안을 하기에는 비용이 너무 커지는 게 우려가 되었다.
그래서 당장은 우선도를 낮게 책정했다.
그렇게 10개의 협업툴을 비교하고, 한국어 지원 여부부터 시작해서 나름의 기준으로 협업툴 후보군을 좁혔다.
마침내 필자는 트렐로의 대안이 될 수 있는 협업툴로 ‘노션(Notion)’과 ‘아사나(Asana)’로 좁힐 수 있었다.
노션은 소위 말해 ‘만능 협업툴’이라는 소리를 들을 정도로 폭넓은 기능을 지원하지만, 우리 회사가 필요로 하는 ‘타임라인’과 ‘간트차트’ 기능을 지원하지 못했다.
외부 프로그램(Add-on)을 이용하면 가능은 하겠지만 그런 것을 연구하고 적용할 정도로 노션이 매력적인 협업툴이지는 않았다.
그밖의 다른 강력한 후보군 툴을도 존재했지만, 대다수는 한국어 지원 여부에서 걸러졌다.
그렇게 우리 프로젝트의 새로운 프로젝트 매니징 협업툴은 ‘Asana’로 결정되었다.
필자는 위의 표를 기반으로 대표님과 이사님을 설득했고, 다행히 트렐로가 불편하다는 점을 이미 느끼던 분들이 Asana에 매력을 느끼시면서 새 협업툴을 써보기로 결정이 되었다.
필자를 중심으로 한 몇몇 사람들이 얼리어답터(초기사용자)로서 아사나 체험판을 시작했다.
Hello Asana!
게임 회사 중에서 Asana를 활용하는 기업도 물론 있다.
대표적인 회사가 바로 devCAT이다.
devCAT은 ‘마비노기’와 ‘마비노기 영웅전’ 등을 만든, Nexon의 대표적인 자회사다.
프로젝트의 성패와는 무관하게, 이러한 ‘좋은 회사’에서도 Asana를 사용한다는 점은 눈길이 갔다.
Asana 체험판을 시작하기까지 끌고 온 필자의 다음 과제는 프로젝트 구성원 전부가 Asana에 적응할 수 있게 ‘가이드 문서’를 만드는 일이었다.
필자는 과거 ‘century game korea’에 재직할 때도 이 협업툴을 1년 정도 사용해 본 적이 있다.
길다면 길고 짧다면 짧은 기간이지만 그 기간동안 사용해본 기억을 되살렸을 때 Confluence나 OneNote등 다른 협업툴보다 Asana가 훨씬 편리했던 기억이 났다.
프로젝트 내부에서 아무도 ‘Asana’를 사용해본 적이 없다는 말이 나오면서 다소 주춤했을 때, 필자는 이전 회사에서 써본 적이 있다고 했던 어필도 이 협업툴을 도입하는 데 든든한 뒷받침이 되어 주었다.
“Asana 왜 써야하나요?”라는 질문에 대한 답변 준비
방어 논리 1: + 알파 전략
새 협업툴을 도입하면서 필자에게 주어진 숙제는 바로 기존에 트렐로 환경에 익숙하던 사람들을 어떻게 새로운 체계에 잘 적응하게 만드느냐는 것이었다.
Asana는 트렐로처럼 ‘보드 뷰’를 지원하기 때문에 보드 뷰로 사용하면 트렐로와 별반 다를 게 없다는 점을 상기시킬 필요가 있었다.
한편으로는, 왜 ‘보드 뷰’를 똑같이 쓰는 와중에 굳이 번거롭게 트렐로에서 새로운 협업툴로 번거로운 마이그레이션을 해야하냐는 물음에 대해 미리 대답할 수 있어야 했다.
그래서 필자가 택한 전략은 투 트랙, 그 중에서도 ‘+ 알파’ 전략을 먼저 소개한다.
한 마디로 트렐로에서 지원하는 기능이 3이라면, Asana에서 지원하는 기능이 10이라는 점을 강조했다.
기존의 보드 뷰 외에도, 리스트 뷰나 타임라인 뷰, 간트차트 뷰나 캘린더 뷰가 가능하다는 점은 새 협업툴이 가져다 줄 수 있는 차별화된 강점이었다.
특히 간트차트 뷰나 타임라인 뷰는 PM님 처럼 모든 일정을 총괄하는 입장에서는 굉장히 환영하는 옵션이었다.
또한 보드 뷰를 기존처럼 ‘팀’ 위주로 컬럼을 분배하는 게 아니라 각 작업사항(To-do, Ing, Holding 등)으로 분류할 수 있게 되자, 기존에 칸반 보드를 구축하고 싶었지만 트렐로의 구조 때문에 하지 못했던 분들은 두 팔 들어 환영했다.
여전히 Asana를 도입하는 데에 관해 회의적인 입장인 사람들이 각 뷰를 모두 써야한다는 강박을 느끼지는 않게, 어디까지나 보드 뷰를 바탕으로 선택사항이라는 점을 덧붙였다.
이로써 트렐로가 할 수 있는 것보다 더 많은 것이 가능한 Asana를 통해 프로젝트 관리가 더 편해질 것이라는 전망을 보여주었다.
방어 논리 2: – 해소 전략
그렇다면 반대로, Asana를 쓰게 되면 트렐로에서 마이그레이션하는 과정에서 포기해야하는 건 없었을까?
아쉽게도 있었다.
바로 마이그레이션(데이터 이전)이다.
트렐로는 비겁하게도(?) 기존 트렐로에 있는 보드를 다른 협업툴 서비스로 마이그레이션 하는 기능이 굉장히 부실했다.
사실상 모든 일감을 일일히 가져오거나, 아니면 트렐로의 csv 익스포트를 통해 복잡하게 꼬인 데이터의 털실뭉치를 일일히 해체하는 수밖에 없었다.
그래서 필자는 자신의 팀(내러티브팀)의 일감은 모두 필자가 주도해서 수동으로 옮겨왔다.
하지만 다른 팀의 일감은 결국 팀 간의 R&R이 걸린 문제이기도 하고 필자는 트렐로의 모든 히스토리를 아는 게 아니기 때문에 그 팀의 팀장님에게 일감을 체크해달라고 요청해야만 했다.
트렐로의 불편한 마이그레이션 외에도 트렐로의 불편했던 점은 더 있었다.
가장 기억에 남았던 건 바로 ‘내 일감 보기’가 불편했던 점이다.
트렐로에서는 자신의 일감을 보려면 전체 뷰에서 자신의 이름을 선택해서 필터링을 걸어야만 자신의 일감이 보였다.
처음 트렐로에 들어가서 내가 오늘 해야하는 일을 확인하기까지, 꽤 많은 클릭을 해야만 했다.
반면 Asana에서는 ‘홈’이라는 이름으로 내가 오늘 할 일을 요약해주는 페이지가 있었다.
‘홈’에서는 내 작업 목록, 일정, 그리고 관련한 프로젝트(연관 부서), 그리고 관련하여 협업하고 있는 파트너 등을 한 눈에 확인할 수 있었다.
트렐로에서는 어쩔 수 없이 수 회의 클릭과 터치를 해야만하는 불편함이 이제는 접속만 해도 확인이 될 정도로 간소화된 셈이다.
우리가 앞으로 맞이할 미래는 ‘사용자가 생각하게 하지 마!’라는 UX 철학 측면에서도 알맞았다.
그렇게 Asana의 방어 논리 1: + 알파 전략과 방어 논리 2: – 해소전략을 양립한 설득 과정은 다행히 구성원들 내에 반발 없이 잘 정착하게 했다.
5분만에 알아보는 Asana 사용 방법
Asana가 복잡해보이지만, 사실 몇 가지 용어와 그 개념만 잘 안다면 이해하는 데 그다지 어렵지 않다.
지금부터 약 5분만 내어주신다면, 앞으로 Asana가 보여줄 ‘미래’에 관해서 보여드리도록 하겠다.
Asana 기본 용어 바로 알기
Asana에서 알아두어야 할 용어는 크게 다섯 가지다.
포트폴리오. 프로젝트. 섹션. 작업. 그리고 하위 작업이다.
예시를 통해 알아보자.
포트폴리오
포트폴리오는 일종의 ‘컨트롤 센터’다.
이름이 포트폴리오인 이유는 ‘프로젝트’가 전체적으로 잘 굴러가는지에 대한 성적표(포트폴리오)이기 때문에 그런 것으로 보인다.
포트폴리오를 체계적으로 활용하면 각 프로젝트의 진행 상황을 트래킹하기 용이하다는 장점과, 만약 프로젝트가 일정상 지연되고 있다면 그 부분을 바로 캐칭할 수 있다는 점에서 일정 리스크를 최소화할 수 있다는 장점이 있다.
프로젝트
프로젝트는 일종의 ‘대규모 작업’이다. 어떤 회사에서는 ‘마일스톤’이라고 기간과 결부해서 지정하거나, ‘기획팀’처럼 어떠한 부서 전체를 지칭할 수도 있다.
프로젝트는 아래와 같이 A타입과 B타입으로 구성할 수 있다.
- A타입 예시)
- M13 콘텐츠 팀
- : ‘콘텐츠 팀’이 주축이 되는 일종의 ‘채널’이다. 단, 마일스톤이 끝나면 아카이빙한다.
- B타입 예시)
- 콘텐츠 팀
- : ‘콘텐츠 팀’이 주축이 되는 채널이다. 마일스톤이 끝나도 아카이빙하지 않는다.
- C타입 예시)
- 버그 티켓
- : 프로젝트 전체 인원이 버그를 등록하고 추적하는 채널이다. 모든 버그는 이 버그 티켓에서 관리한다.
섹션
섹션은 특정 규칙에 의해 묶인 작업(task)의 집합이다.
일반적으로 한 프로젝트는 위의 Trello의 예시처럼 4개~5개 정도의 섹션으로 구성된다.
이렇게 To Do – In Progress – Review – Done으로 구분하는 방식을 ‘칸반 보드’라고 한다.
위 구분법은 왼쪽에 있는 작업이 ‘할 일’이고 오른쪽에 있는 작업이 ‘완료한 일’이 되므로 인간의 뇌의 직관(글을 읽을 때 문장을 왼쪽에서 오른쪽으로 본다든지)과 일치한다.
따라서 뇌가 구조적으로 이해하기 용이하다는 장점이 있다.
단, Asana에서는 칸반 보드 뷰를 기본값(default)로 세팅해두고있지 않다.
따라서 칸반 보드 뷰를 활용하기 위해서는 기존의 보드 뷰 설정을 칸반에 맞춰서 조정해 줄 필요성이 있다.
작업
Asana의 모든 일감은 하나의 작업(Task)으로부터 이루어진다.
하나의 작업을 어느 정도의 규모로 설정하는지는 사용자 마음이다.
만약 임의의 작업을 1개 생성한다면 그 작업의 크기와 제목은 아래 예시 정도가 된다.
- 예시 1) 교감 시스템 아웃게임 UI/UX 기획
- 예시 2) 교감 시스템 아웃게임 개발
- 예시 3) 교감 시스템 개발
예시 1에서 예시 3으로 갈수록 작업의 규모가 더 커지는 것이 보일 것이다.
예를 들어, 예시 1에서는 UI/UX에 집중한다면, 예시 3은 아예 전반적인 개발을 모두 하나의 작업으로 설정한 셈이다.
이처럼 ‘큰 작업’을 설정하는 게 잘못된 건가? 하면 그렇지는 않다.
다만, 이 정도 규모의 작업을 설정한다면 이 작업을 ‘마일스톤’으로 전환하거나, ‘하위 작업’을 추가해준다면 프로젝트 전체를 파악하는 사람들 입장에서는 작업의 크기를 파악하는 데 도움이 될 것이다.
하위 작업
Notion을 사용해 본 경험자라면 Notion의 각 페이지가 계속 하위 페이지를 만들(새끼를 칠) 수 있다는 걸 알 것이다.
Asana에서도 동일한 개념을 지원한다.
하나의 작업이 너무 규모가 크다면, 적절히 하위 작업을 만들어주면 작업 하나를 마치는 데까지 구체적으로 어떤 업무가 필요한 지 정리 및 파악하기 좋다.
정리
위에 나열한 다섯 가지 개념 중에서 가장 중요한 건 ‘작업’이다.
작업은 모든 작업의 기본 단위이기 때문이다.
위와 같은 구조가 머리속에 있으면 Asana에서 작업을 신규 생성하거나 작업끼리 연결할 때 더 구조가 명확하고 간결해진다.
이처럼 일정 섹션에 맞게 작업을 배치하고 섹션을 만들고 프로젝트를 만드는 식으로 ‘상향식’으로 포트폴리오를 짜 가면 어느새 짜임새 있는 구조가 만들어질 것이다.
칸반 보드 세팅하기
Asana 뷰 방식 바로알기
보드 뷰
각 섹션(열)에 주제를 할당하고, 그에 맞춰서 작업을 마치 ‘포스트잇’처럼 볼 수 있는 뷰.
각 섹션과 작업 간의 ‘관계’를 보고싶거나, 현재의 작업의 ‘진행상황’을 볼 때 편리하다.
리스트 뷰
리스트 뷰는 마치 스프레드시트를 보는 듯한 ‘표’ 형식의 뷰다.
각 카테고리에 맞게, 작업자는 누구인지, 마감일은 언제인지, 현재 진행도는 어떤지 한눈에 파악할 수 있다.
‘필터’ 기능을 사용하면 수십에서 수백 개에 해당하는 리스트를 원하는 대로 간소화해서 볼 수 있어 편리하다.
타임라인 뷰
타임라인 뷰에서는 오늘(하늘색 선)을 기준으로 누가 어떤 작업을 하고 있는지 시각화된 뷰다.
Asana 타임라인 뷰의 강력한 점은, 바로 전후 작업 간의 연결성이다.
위의 화살표처럼 각 작업이 연결된 것을 보며, 하나의 작업과 관련해서 파이프라인이 어떻게 되는지, 그리고 착수일과 예상 마감일이 언제인지 확인할 수 있다.
특히 작업자 중 누군가가 휴가를 가야할 때, 그 작업자와 연관 작업자가 일정상 어떤 영향을 받는지 알 수 있는 등 일정 확인하기가 용이해서 일정 관리에 빼놓을 수 없는 뷰 방식이다.
간트 차트는 타임라인의 또 다른 방식으로, 각 작업마다 소요일과 그 순서를 ‘계단식’으로 시각화해서 보여준다.
각 막대의 길이는 소요 시간을 나타내고, 각 막대의 위, 아래 위치는 보통 그 작업과 관련하여 진행 순서를 나타낸다.
간트 차트는 수십 일에 달하는 어떠한 ‘작업’을 체계적으로 구분하는 데 용이하다.
캘린더 뷰는 다른 캘린더 뷰와 비교했을 때 대단히 특출난 부분이 있는 건 아니나, 다른 뷰 타입과 혼용해서 사용하기 좋다.
아쉽게도 한국의 ‘공휴일’이 위의 캘린더 뷰에 반영이 안 된다는 점이 흠이다.
Asana 업무 자동화
Asana의 사용자 지정 탭은 Asana의 가장 강력한 기능인 ‘업무 자동화’를 위해 준비되어 있다.
이제 아래의 슬라이드를 보며 Asana의 ‘규칙’이라는 기능에 관해 간단하게 알아보도록 하자.
정리하는 글
결론 1: 아사나의 선명한 장점이 신규 고객을 유치하다
이렇게 Asana를 도입하기까지 우리 회사에서 어떤 설득의 과정이 있었는지, 그리고 필자가 프로젝트 구성원들을 설득하기 위해 어떤 고민들을 거쳤는지, 그리고 Asana를 사용하는 방법에 관해 요약해보았다.
원래 하나하나의 주제에 따라서 한 편의 글로 적어도 무방할 정도로 방대한 글을 풀어낼 수 있겠지만, 그렇게 긴 글이 만들어졌을 때 오히려 Asana를 부담스럽게 느낄 분도 계실 것 같아서 주로 글 보다는 이미지로 내용을 풀고자 노력했다.
필자는 Asana라는 툴을 좋아한다.
비싼 것을 제외하고는(한 달에 3만원이 넘는다!), Asana의 대부분의 기능은 필자가 정말로 필요로 했던 기능을 전부 담고 있다.
개인적으로는 Jira와 Confluence를 사용하는 구조보다도 Asana가 더 Lite하고 학습하기 쉬운 툴이라고 생각한다.
게임 업계에서 쓰이는 대부분의 협업툴보다도 Asana가 더 ‘배우기 쉽고 범용적이다’라는 말로 정리할 수 있겠다.
이 글은 도입부부터 줄곧 트렐로를 비판하는 스탠스를 취하기는 했지만, 트렐로 또한 협업을 위해서는 언제나 고려해볼 수 있는 좋은 툴임을 부정하지 않는다.
그저 필자의 기준에는 제대로 사용하기 위해서는 온갖 애드온을 붙여야하는 트렐로보다는 순정 그 자체가 강력한 Asana가 더 매력적이었다. 이 부분은 Notion도 비슷한 철학을 가진 셈이다.
필자의 의견이지만, 툴을 제대로 쓰기 위해서는 ‘애드온’을 붙여야만 원활한 협업이 되는 툴은 그만큼 기본기(basic)이 약한 툴임을 방증한다고 생각한다.
역시 모든 것을 어중간하게 호환하는 것보다는, 선명성 있게 내가 필요로 하는 기능에 집중하는 것이 더 강렬한 인상을 남기는 법이다.
결론 2: 하지만 Asana는 All-in-One이 아니다
필자가 앞서 니즈로 선정했던 부분들에 관해 기억하는가?
굳이 번거롭게 위로 다시 돌아갈 것 없이, 필자가 이곳에 그 내용을 옮겨붙여넣도록 하겠다.
- 한국어를 지원할 것.
- 버그를 추적 및 관리할 수 있다. (일종의 지라)
- 팀 별로 각 작업자가 어떤 업무를 진행중인지 알 수 있다. (일종의 일정 캘린더)
- 타임라인 뷰 등으로 이번 주, 이번 달, 이번 마일스톤 등에 어떤 업무를 진행해야할 지 알 수 있다.
- 개개인의 일정 관리가 가능하다.
- 단순 반복 작업이 아니라, 어느 정도 자동화된 규칙에 따라서 템플릿을 생성할 수 있다. (업무 자동화)
- 위키 기능을 사용할 수 있다. (일종의 컨플루언스)
여기서 필자가 다른 기능은 모두 만족하지만 단 하나, ‘위키 기능’이 없다는 점이 끝끝내 아쉬웠다.
Asana는 Notion이나 트렐로처럼 각 페이지의 단위가 곧 Task라고 보면 된다.
그런데 ‘위키피디아’나 ‘나무위키’ 등 제대로 된 위키는 각 페이지가 Task같은 단위로 ‘묶여서는’ 안 된다.
그렇게 되면 하나의 뎁스를 들어갈 때마다 오가는 게 굉장히 번거로워진다.
각주를 쓸 수 없다는 점도 대표적인 단점이다.
물론 Asana가 전문적인 위키를 만드는 툴이 아니라는 점에서 어쩔 수 없기는 하나, Asana가 위키 기능을 지원하지 않아서 위키 기능을 도입하기 위해 추가적으로 위키 특화 협업툴을 사달라고 회사에 조르는 것도 굉장히 부담스러운 일일 수밖에 없다.
그래서 필자는 위키를 쓸 수 있는 방법을 여러가지로 모색했고, 결국 하나의 결론에 다다랐다.
다음 글에서는 필자가 어떤 방법으로 ‘위키 기능’을 사용할 수 있게 되었는지 소개하도록 하겠다.
Appendix. Asana와 관련해서 알아두면 유용한 페이지 링크
Asana 공식 홈페이지
Asana 한국 파트너스 페이지
Asana 학습 페이지
답글 남기기