[SOPT APPJAM] 우리가 만드는 문장 큐레이션 플랫폼, 몽글(5) - 협업을 위한 팀 툴의 세팅과 사용(Notion)

    수많은 방식의 협업을 해봤지만, 모든 협업의 시작은 협업을 할 때 사용할 툴을 정하는 것이다.

    협업 툴은 팀의 소통을 원활하게 하기 위헤 쓰이고 그 역할에 따라 다양하게 존재하고 있는데, 내 기준으로 나눠보자면

     

    일정관리

     

    업무기록 및 공유

     

    파일 및 자료공유

     

    대화/소통

     

    주로 이런 일들을 해결하기 위해 사용된다.

    위의 네 가지 일을 처리하는데 아무런 문제와 불편함이 없다? 굳이 더이상의 효율을 바라지 않는다?

    그렇다면 툴을 사용하지 않아도 되는 팀. 하지만 세상에 그런 팀이 존재할까? 아니 존재하더라도 살아남을 수 있을까...

     

    툴을 결정할 때 가장 중요하게 기억해야 할 것.

    툴은 소통의 효율과 업무의 효율을 위해 사용하는 것이다.

    따라서 툴의 사용이 이 둘을 오히려 방해한다면, 과연 팀 툴을 사용하는 것이 우리 팀에 맞는 것인지 생각해봐야 한다.

     

    그리고 가끔 이런 이야기를 하는 사람들이 있다!

    "팀에서 쓰라고 팀 툴 채널(혹은 페이지 등)을 만들어 놨는데, 다들 처음에만 쓰다가 결국엔 안 쓰게 되더라고."

    내가 생각하기에 이 문제는,

     

    1. 그 팀에는 이미 그 툴이 없어도 소통이 원활하게 잘 되고, 작업 공유가 잘 되고 있거나
    2. 제대로 쓰는 방법을 몰라서이거나다.

     

    웬만하면 툴은 쓰면 무조건 효율적이다. 그러라고 만들어 놓은 것이기 때문이다.

    따라서 24시간 내내 붙어서 작업을 하면서 그때그때 편하게 필요한걸 요구할 수 있는 팀이면 1이 이유가 될 수 있겠으나,

    대부분은 그렇지 않기 때문에 보통은 2의 이유였던 적이 많다.

     

    따라서 이번 글에서는 내가 협업할 때 가장 자주 사용하고 좋아하는 두가지 툴들을 소개하면서,

    몽글에선 어떻게 관리하고 사용했는지 설명을 해보고자 한다!

    (실제로도 앱잼을 시작하니 몽글의 노션을 참고하면서 쓰려는 기획자분들이 많았기 때문에^^,,,)

     

     


    노션(Notion)

    내가 정말 애정하는 툴이 아닐수가 없다!

    자유도가 굉장히 높아, 아는 만큼 더 잘 쓸 수 있고, 쓰는 만큼 더 편해지는 툴이다.

    나는 팀 업무를 할 때 뿐만 아니라 개인 프로젝트나 작업, 포트폴리오를 만들 때도 이용하고는 한다.

     

    우리 팀은 노션을 다음 목적으로 이용했다.

     

    1. 회의안 및 회의록 작성
    2. 기획 이슈 정리 및 공유
    3. 디자인팀과 개발팀의 업무 공유를 위한 칸반보드
    4. 앱잼 일정 공유
    5. (기타) MVP 운영

     


     

    0. 몽글팀 노션 대문

    [공지사항]

    • 가장 잘 보이는 맨 위 공간에 팀원들이 모두 확인할 수 있는 "공지사항" 란을 만들었다.

    • 해당 공지는 전달이 완료된 후에 BOARD란의 공지사항으로 이동시켰다.

    • 하지만 카카오톡의 접근성을 무시할 수 없어서, 이후에는 카카오톡 공지방으로만 공지가 전달하는 일이 잦았다.

     

     

    [BOARD] 게시판

    • [한 문장 창고] 기획팀이 서비스를 개발하면서 쌓아두는 DB와 더미데이터를 위한 게시판

    • [공지사항] 공지가 완료된 이전의 모든 공지사항 들

    • [몽글이 몽글몽글] 개발팀이 들어오기 전에 기획팀과 디자이너들이 함께 썼던 업무 일지 겸 일기

    • [레퍼런스 창고] 아는게 많았던 Ti가 알려주고 싶었던 정보들, 혹은 디자이너들을 위한 디자인 레퍼런스.

     

     

    [DB List] 팀 모두가 해야 할 일들을 기록하고 쌓아두는 곳

    인데 이 부분은 이후에는 회의록 빼고 잘 안쓰게 되었다.

    프로젝트 만큼 큰 업무가 잘 없고 뒤로 갈수록 짜잘한 이슈 해결 등의 업무가 많이 생겨서 그랬던 것 같다.

    회의록은 아래에서 좀 더 자세히 보자!

     

     

     

    [Work Hard] 일하는 곳. 기획팀, 디자인팀, 개발팀의 팀별 업무 정리를 위한 팀별 페이지

    각 팀별로 페이지를 만들기만 했고, 이후는 자유롭게 쓰게 맡겼다.

    우리팀은 되게 노션을 잘 썼던 팀에 속해서 기획팀을 제외한 페이지들을 잠깐 구경해 보자면,

     

    디자인팀은 디자이너들 답게 예쁘고 열심히 꾸몄다.

     

    리드 개발자였던 주혁이가 그래도 노션을 만질 줄 알아서, 팀원 소개도 그렇고 꽤 예쁘게 꾸며놓았다.

     

    안드는 특이하게 업무 관리를 칸반보드가 아니라 이렇게 뷰별로 체크박스를 만들어 공유했다.

     

    서버도 해리언니가 노션을 잘 만져서 꽤 잘 썼던 것 같다.

     

     

     

    [Play Hard] 일만 할 순 없으니까.

     

    • [몽그리들이 부시고 싶은 합정맛집] 작업공간이 합정역이어서, 가고싶은 식당이 있으면 생각날 때마다 적고 다같이 갔다.

    • [금요일날 시간 어때요?] 리프래시데이였던 금요일에 뭘 할까 적어놓은 것들이 있는 페이지.

    • [몽그리들아 엠티가자!] 앱잼이 끝나고 나서 엠티를 가기 위해 계획해놓은 것들이 있는 페이지.


    1. 회의안 및 회의록 작성

    회의록은 언젠가는 반드시 다시 찾게된다.

    모든 내용을 다 기억할 수 없고, 모든 사람이 회의에 항상 참여할 수 있는 것은 아니기 때문이다.

    그래서 우리 팀은 항상 회의록을 열심히 적었다. 누구나, 언제든지 와서 팔로업하기 쉽게!

     

    내려도 내려도 끝이 없는 3주간 한 회의의 양...

     

    사람마다 다를 순 있지만,

    전체회의처럼 업무가 생기는 회의의 경우 우리는 회의록에 모든 회의의 흐름이 그대로 드러나게 적었다.

    요약하거나 정리하지 않았다. 회의에 참여하지 않은 제 3자가 와서 읽어도 이해가 갈 만큼 적었다.

     

    단, 회의가 끝난 이후 기획팀에서 할일 DB로 회의에서 정해진 할일을 옮기거나, 회의록 아래에 요약을 해 두고 담당자를 태그한다.

    혹은 각 업무 담당자들이 본인의 파트 페이지에 바로바로 기록하고 기억할 수 있게 한다.

    서기는 기획팀이 돌아가면서 했는데, PM인 나는 주로 회의 진행을 해야 했으므로 대부분을 티아이들이 수고해주었다!

     

    다만 뒤로 갈수록 데일리 스탠드업 미팅이나 파트별 회의가 많아지고 전체 회의는 줄어들면서,

    할일 DB로 할일을 따로 옮겨놓는 일은 자연스럽게 줄어들었다.

     

    전체 회의 회의록

     

    반면 데일리 스탠드업 미팅의 경우에는 파트별 소통과 업무공유가 목적이었으므로,

    간단하게 오늘 한 일과 오늘 할 일만 서로 공유했다.

    뒤로 갈 수록 시간이 없어지면서 파트별로 미리 이 회의록을 적어두고,

    회의 시간엔 이슈만 공유하는 식으로 가볍게 진행하기도 했다.

     

    팀 업무에서, 파트별 업무 공유는 아주아주 중요하다! 매일 진행되었던 스탠드업 미팅 회의록. (오늘 한 일과, 할 일 공유)

     

    참고로 회의 템플릿은 이렇게 미리 만들어 두고 사용하는 것이 굉장히 편리하다!

     


     

    2. 기획 이슈 정리 및 공유

    앱잼 뿐만 아니라 어떤 팀 작업이든 하다보면, 이제 모든 팀에서 기획팀을 애타게 찾게 된다...

     

    "인기순의 정렬 기준은 무엇인가요?"

    "인기순은 리프래시가 되나요? 리프래시 시간 기준은 어떻게 할까요?"

    "이 버튼 누르면 어디로 가나요? 무슨 창이 뜨나요?"

    "좋아요는 본인도 누를 수 있나요? 북마크는요?"

     

    아무리 기획팀에서 꼼꼼하게 기획했다고 한들,

    디자이너와 개발자들은 (특히 개발자들) 뷰의 처음부터 끝까지를 만들고 이어 붙이고 예외를 처리해야 하기 때문에,

    생각치도 못했던 부분에서 기획의 빈틈이 나오기 마련이다.

     

    정말 많다.

    새로 정하고 고치고 바꿔야 할 것이 계속해서 생긴다.

    회사가 아니라 팀프로젝트이기 때문에 일만 할 수도 없다. 밥도 하고 회계도 써야 하고 청소도 해야 한다.

    바쁘다. 당장 기획 업무 처리하기도 바쁜데 계속 물어보는 사람이 생길 것이다.

     

    그래서 우리 팀은 이슈보드를 만들었다.

    개발자와 디자이너가 말하기 전에, 생길 수 있는 최대한 모든 사소(하지만 개발에선 아주 중요한)한 이슈들을 세미 QA 하듯이 잡아내고, 해결하기 위한 보드였다.

     

    아래 캡쳐부터는 클릭하여 확대해서 보는 것을 추천한다!

     

    ㅋㅋㅋㅋㅋ미쳐 해결 못한 이슈들이 가득^^

    그것이 이 페이지이다. 이 페이지는 이렇게 사용한다.

     

    1. 기획자, 개발자, 디자이너 누구 할 것 없이 이슈를 발견한다.
    2. 사소하든 사소하지 않든 일단 이곳에 전부 기록한다.
      • 무슨 이슈인지?
      • 이슈를 해결할 기획팀은 누구인지? (역할 배정)
      • 이 이슈와 관련된 키워드는? (나중에 찾기 쉽게 태그로 만들어 분류했음)
      • 이 이슈의 해결 우선순위는? (0순위, 1순위, 2순위로 분류)

    3. 해결이 완료된 이슈는 체크박스에 체크한다.

    4. 누군가 어떤 이슈에 대해 질문한다.

    5. "기획팀 이슈 페이지에 있어!" 라고 대답한다.
      그러면 나중에는 먼저 이 페이지에서 찾아보고, 없으면 기획팀에게 오게 된다!

     

    우리는 기획팀에 바쁜 사람들이 많았기 때문에, 이 페이지를 굉장히 유용하게 사용했다.

     

    예를들면 이런 내용이다. 

    이슈의 내용을 보통 제목에 적고, 결론을 내리기까지 기획팀의 논리와 과정을 적고, 마지막에 결론을 적어둔다.

    그리고 담당자나 리드 개발자들을 댓글에 태그하고, 파트별로 전달 부탁 & 확인했는지 체크한다.

    해결이 된 이슈들은,  전달이 잘 완료되었는지, 또 궁금한 건 없는지 확인하기 위해 데일리 스탠드업 미팅 때 다시 리마인드를 해 줘야 한다.

     

     

    가끔은 이렇게 내용이 매우 길어지기도 한다. (무조건 A로 결정됐습니다. 하는 것 보단 모두가 이해하고 납득하게 기획하다 보니...)

     

     

    또 가끔은 이렇게 기획자들의 리얼한 피드백과 대화도 엿볼 수 있다. (왼쪽 싸우는거 아님ㅋㅋ)

     


     

    3. 디자인팀과 개발팀의 업무 공유를 위한 칸반보드

    나는 업무 공유를 굉장히 중요하게 생각하는 사람이다.

    소통이나 공유 없이 알아서 처리하다 보면, 반드시 문제가 터지기 마련이다.

    그래서 스탠드업 미팅도 매일 진행하여 소통이 원활하게 했다. 이렇게 하다보면 상대의 업무에 대한 이해도도 높아진다. (예컨대 디자이너는 서버의 업무를 사실 잘 모르지만, 앉아서 매일 듣다보면 어느정도 이해가 되고 소통도 되기 시작한다.)

    그리고 일부러, 개발자들이나 디자이너들에게는 최대한 쉬운 말을 사용하여 회의 때 업무를 공유해달라고 했다.

     

    스탠드업 미팅 때 뿐만 아니라 평소에도 파트별로 무엇을 진행하고 있고, 얼마나 진행되었는지 계속 확인할 수 있게 노션에 칸반보드를 써달라고 했다. 가끔 합숙하는 팀들은 숙소 벽에다 아날로그식으로 포스트잇을 붙여서 하기도 한다. 

     

     

     

    노션의 칸반보드 툴을 이용해도 좋고, 툴이 어색하다면 체크박스로 진행상황을 알아보고 쉽게 표시해도 좋다.

     

     

    이건 릴리즈를 위한 기획과 디자이너들의 칸반보드.

     

    관이 되지 않으면 어색하고 귀찮을 수 있는 일이지만,

    한번 익숙해지면 소통도 잘되고 팀워크나 업무 효율이 아주 좋아진다!

    또한 기획 입장에서, 굳이 물어보지 않아도 지금 누가 어떤 업무를 얼마나 처리하고 있는지 알 수 있기 때문에

    소통하기도 편하고 일정을 조정하기도 좋다.

     

     

    4. 앱잼 일정 공유

    앱잼을 위해 달리고 있다면, 마감이 굉장히 중요할 것이다.

    그래서 이렇게 미리 마감 일정, 파트, 제출해야 할 과제, 팀원 등을 태그해서 리마인드해 두었다.

    노션 리마인드 기능을 설정해두면 마감기한 전에 알림이 온다!

     

     

    5. 기타

    우리 팀은 MVP도 노션으로 운영했다.

    뿅.

     

    개발자 팀빌딩 이전에는 이런 페이지도 운영했다.

    개발자들이 가장 궁금해 할 기능들과, 구현의 우선순위. 개발 팀빌딩을 위한 작전회의.

     

    개발자들에게 어필하기 위한 몽글팀의 일기.

     


     

     

    우리 팀이 어떻게 노션을 썼는지 대략적인 틀만 가져와봤다.

    사실 더 많다. 정말 많다. 기획팀 페이지에는 하위 페이지가 몇개나 있는지 모른다...

     

    중요한 것은,

    우리 팀에게 이 툴이 정말로 필요한가?

    필요하다면 어떤 목표와, 목적을 위해?

    그 목표를 달성하기 위해 과연 노션이란 툴이 적합할까?

    적합하다면, 그 목적을 달성하기 위해 어떻게 효율적으로 페이지를 만들 수 있을까?

     

    이런 것들을 꼭 고려해보아야 한다는 것!!

     

    팀 툴은 정말 잘 쓰면 득이 되지만, 잘못 쓰면 시간은 없는데 이것도 써야 한다는 부담감에 독이 될 수도 있다.

    노션을 메인 협업 툴로 쓰기로 결정했다면,

    기획팀에서 아주 체계적으로 노션 관리를 잘 하고, 적극적으로 먼저 잘 쓰고 공유를 하는 것이 베스트인 것 같다.

    기획팀이 쓰지 않는 노션은... 팀원 모두가 쓰지 않는다.

     

    모쪼록... 툴을 위한 협업이 아니라 협업을 위한 툴이 되었으면 좋겠다!

    댓글