조직이 규모를 갖춰가는 시점에서 어떤 도구를 사용해야 할까요?
21.02.27 Update.
2년 전에 쓴 글이라 업데이트 시점인 현재는 약간의 변동 사항이 있습니다.
현재는 드랍박스 대신 구글 드라이브를, 스케치+제플린+앱스트랙트 보다는 피그마를 사용하여 별도의 기획서 없이 바로 소통합니다. LINGO는 폐기하고 Notion 으로 모든 컨텐츠와 위키 기록 및 공유용도로 활용합니다. JIRA 는 쓰지 않게 되었고, 작업 관리 모니터링 툴로서 Monday 먼데이를 훨신 강력하게 자주 사용하게 되었습니다. 먼데이에 대한 글은 나중에 자세히 한번 상세히 풀어내 보는 글을 써보겠습니다.
결론:
분화되어 있던 생산성 툴들이 bundling 의 과정을 통해 단순화 되어 가는 중입니다.
현 시점에서는 아래의 툴 도구들로만 활용하고 있습니다.
to-be : Google Suite + Slack + Monday + Figma + Notion
선수 간 터치가 많을수록 경기의 승률이 올라간다.
2010년 버클리대의 켈트너(Keltner) 교수팀은 2008∼2009 시즌 NBA 농구팀의 신체접촉을 분석했습니다.
연구팀은 NBA 농구팀의 신체접촉 가운데 하이파이브(high fives), 로파이브(low fives), 풀허그(full hugs), 가슴치기(chest punches), 주먹 마주치기(fist bumps) 등 12가지 터치를 분석한 결과 동료끼리 자주 터치한 팀이 개인뿐만 아니라 팀 성적도 좋았음을 확인하였습니다. 다른 변수를 통제한다 해도 팀 동료끼리 자주 터치하면 할수록 팀의 승률이 압도적으로 높아지는 결과를 데이터로 증명하였습니다.
투명성에 기반한 분업과 공유의 촉진
변화하는 스타트업 환경에서 협업 경쟁력은 더 이상 권장이 아닌 필수가 되고 있습니다.
반복적이고 예측 가능한 정형화된 업무와 달리 창의력과 순발력이 요구되는 비정형적인 업무가 점차 더 늘어나고 있습니다. 변동성이 높고 불확실한 상황에서 복잡한 요소들을 처리하기 위해서는 개인의 역량도 중요하지만 상호 간 협업이 얼마나 효과적으로 이루어지느냐가 매우 중요한 명제로 관리되어야 합니다. '투명성에 기반한 분업과 공유의 촉진'을 모토로 다양한 협업 툴을 사용 가능합니다. 지금부터 어떤 원칙과 목적으로 각 툴을 사용하고 있는지 설명드리도록 하겠습니다.
프로젝트 & 태스크 관리 툴 중에서는 가장 강력하고 손쉬운 툴입니다.
problem)
조직 내에서 중간 관리자 직군 이상이신 분들은 누구나 엑셀 문서를 통한 WBS(Work Breakdown Structure) 작성 경험이 있으실 겁니다. 이때의 문제점은 방대하게 작성된 개별 Task들이 timeline 이 지나감에 따라 Sync가 되지 않으며, Update의 번거로움. 그리고 잦은 계획 및 상황 변동에 따른 배보다 배꼽이 더 커지는 (작업에 투입하는 시간 대비 WBS에 Sync 반영하는 시간이 비슷할 거 같은...) 현상으로 인해 한번 작성 후 업데이트가 되지 않아 죽은 문서가 되는 이슈가 매번 높은 빈도로 발생하게 됩니다.
Solution)
먼데이의 경우는 기본적으로 엑셀과 동일한 종횡의 구조에서 개별 작업자들이 직접 자신의 Task를 sync update 작업을 진행하며, 변동사항에 대해 유관 인력들이 실시간으로 확인 가능하도록 강력한 Subscribe 기능을 제공합니다. 쉬운 말로 실무자들이 놓치는 항목 없이 빠져나갈 수 없는(?) 저인망 그물과 같은 기능들을 제공합니다.
Think)
관리 툴로서 유사한 서비스들 중 Meister task, Flow, asana, trello 등이 존재하고 있지만, 현재 저희 규모에서 가장 최적화된 툴은 먼데이였습니다. 각 서비스 부서와 팀 별 각기 다른 프로젝트들을 자신들에게 맞게 Customize 하여 쓰기에 가장 훌륭한 도구입니다.
먼데이를 쓰면서 겪게 된 가장 근원적인 변화는 작업을 진행하는 실무자가 자신에게 주어진 작업에 대하여 Bottom-UP Communication 이 전체 프로젝트 일정에 반영될 수 있다는 데에 있습니다. 구성원들의 Task에 대한 Ownership 은 이런 작은 부분에서부터 Build-UP 이 될 수 있습니다.
Background)
슬렉을 단순한 커뮤니케이션 툴로만 볼 수 없는 이유는, 실제로 100만 이상 되는 미국 대기업들 중 상당수가 Enterprise-Grid 패키지로 Slack을 이용 중에 있습니다. 현존하는 메이저 급의 써드파티 앱들 중 대다수는 Slack 내에 integration 기능으로 연동이 가능하며, 조직 내의 모든 커뮤니케이션의 중심에서 매우 중요한 투명함과 개방성을 제공해 주고 있습니다. 현재 실시간으로 프로덕트에 영향을 주는 작업들의 진행 상태를 즉시 채널에서 확인이 가능하도록 연동을 시켜 두었습니다.
Solution)
몇 가지 소개를 시켜 드리자면... 매 시간마다 매출을 확인할 수 있는 채널, 버그가 생겼을 때 바로 확인 가능한 봇-오류 채널, 디자인이 업데이트되었을 때 실물로 바로 확인 가능한 채널, 구성원들의 연차휴가 캘린더 업데이트 알림 등. 프로덕트 내외의 모든 진행 변동사항들을 어느 누구나 투명하게 접근할 수 있는 경로를 제공해 줍니다. 또한 사업 부문 별로 workspace 그룹을 각기 운영하며, 각 그룹 간의 공유 채널을 통해 소통할 수 있습니다. 스타트업 조직에서 가장 높은 가치인 민첩성(Agility)을 지향함에 있어 슬렉은 매우 높은 효율로 커뮤니케이션 허브로서의 역할로 사용 중에 있습니다.
Background)
조직 전체 구성원들은 파트 별로 맥과 윈도우를 병행하여 사용 중에 있습니다. IT 프로덕션 관련 조직은 맥의 비중이 높으며, 비 프로덕션 조직의 경우 대다수가 윈도우를 사용 중에 있습니다. 이 두 OS의 가교 역할을 google Suite 서비스들이 매우 효과적으로 이어주고 있습니다.
Solution)
모든 오프라인 문서들은 google 문서, 스프레드시트, 프레젠테이션 항목에서 변환하여 링크 형태로 발행되며, 해당 링크는 Slack을 통해 일괄 공유됩니다. 오프라인 문서의 직접 공유는 상호 지양하며, TASK 중심의 온라인 링크들로 상시 Sync, Update 되며 운영합니다. 이로 인해 Depth 가 있는 내용들은 링크를 통해 상시 관리되며, 문서들의 변동사항들을 Version History 별로 확인할 수 있습니다.
외부 채널과 상호 공유되어야 할 높은 용량을 차지하는 Raw Data 및 동영상 등의 저장공간으로 드롭박스를 활용하고 있습니다. 빠른 속도와 안정적인 환경을 제공해 주고 있기에 외부에 공유되어야 할 다수의 파일 또는 높은 용량의 데이터들은 모두 드롭박스에서 폴더 링크형태로 공유시키고 있습니다. 위의 google Office 툴과 마찬가지로 직접적인 오프라인 파일 전달을 지양하며, acceess 접근 권한 관리를 통해 보다 효율적인 데이터 관리를 진행하고 있습니다.
모든 개발 이슈들은 JIRA에서 관리되고 처리됩니다. 상시적인 모든 이슈들은 Monday 이슈 풀에서 모이며, 해당 풀에서 우선순위와 중요도에 따라 매주 개발팀에서 Scrum 이 진행됩니다. 주별 월별 처리되어야 할 문제들을 각기 선정하여 개발팀에서 소화 가능한 범위 내로 이슈 카드들로 확정 짓게 됩니다. 기획/디자인에서는 개발해야 할 기능들의 상세 내용들과 디자인 zeplin 링크들을 이슈 카드에 담아내어 발행합니다. 발행한 이슈 카드들은 Slack 채널에서 확인 가능하도록 연동되어 있습니다.
이슈 카드를 생성 시에는 가급적 개발자들의 언어로(?) 간결하며 직접적인 개발 구체 사항들이 기입되어야 하기에 이슈 카드를 발행하는 주체는 기획/디자인 PM 또는 개발 PM 들로 제한하고 있습니다. 지금까지 근 1여 년간 처리된 이슈 카드들이 대략 2000개가 넘는군요. 조직의 개발팀은 Jira를 통해 매우 빠른 스피드로 이슈들을 소화하고 있습니다.
모든 디자인 에셋들은 Lingo에서 공유되고 있습니다. 디자인 부서에서 생성한 튜달이 캐릭터들을 콘텐츠 파트나 마케팅 파트에서 자유롭게 활용 가능하게 만드는데 그 목적이 있습니다.
링고 도입 후 가장 큰 강점은 디자인팀이 첫 번째, 상시적으로 벌어지는 잡무에서 해방되었다는 것. 두 번째. 각 파트에서 단순 작업들의 경우에 보다 민첩하게 상황에 대응할 수 있게 되었다는 것. 예전 같았다면 디자인 팀에 해당 자료 요청하고 반나절을 기다려야 하는 상황도 종종 발생하였으나 지금은 발 빠르게 리소스들을 확인하여 각 파트 별로 자율적으로 리소스를 제한 범위 내에서 하게 되었습니다.(외부 대행사들에게도 공유해서 사용하고 있어요) 조직 전체의 민첩성(agility) 향상에 적재적소에 이런 도구들이 제 역할을 해주고 있습니다.
프로덕트의 복잡성이 증대될수록 기하급수적으로 디자인 산출물들의 관리가 어려워지게 됩니다. 디자인 파일의 용량이 점점 커지면서, 갑자기 파일이 삭제되거나 열리지 않는 경우. 너무 많은 파일들로 인해 파일이 어디에 위치하는지 알 수 없는 경우. 너무 많은 디자인 바리에이션으로 인해 최종 디자인 결과물이 무엇인지 알 수 없는 경우. 등 정말 다양한 경우로 혼선이 발생되게 됩니다.
커뮤니케이션 노드가 하나씩 증가할 때마다 혼선이 제곱으로 뛰듯이 다수의 디자이너들이 동시에 디자인 협업을 진행할 때 불필요한 많은 리소스가 허비되게 됩니다. 궁극적으로는 동일한 시간과 인력 가용범위 내에서 높은 효율을 보이기 위한 방법이 고민될 수밖에 없습니다. 이러한 상황에서 GitHub와 같은 디자인 버전 관리 도구의 탄생은 디자이너들에게 등불과 같은 희망을 안겨 줍니다. 앱스트랙트로 인하여 매우 높은 효율로 작업 산출물 관리를 진행할 수 있게 됩니다.
투명성에 기반한 분업과 공유의 촉진이라는 미션 하에
프로덕트 조직은 위의 7가지 툴을 사용 중에 있습니다.
각 툴들은 저마다의 목적성과 효과가 각기 다르며, 사용하는 부서도 저마다 조금씩 각기 다릅니다. 오로지 '해야 할 일을 중심으로 한 협업문화'를 위해 각 도구들은 존재합니다. 공방에서 아름다운 결과물들을 만들어내는 장인의 심정으로 쓰임새가 다른 도구들을 사용 중에 있습니다. 조직의 규모와 서비스의 상태에 따라 쓰는 도구들도 생명력 있게 변화될 것입니다.
기실, 각각의 툴마다 재밌는 이야기보따리를 풀어낼 수 있을 거 같습니다.
언급된 7개의 툴 중에서 궁금하신 점들이 있으신 경우,
댓글로 남겨 주시면 보다 상세한 내용들을 답글 달아드리도록 하겠습니다.
ps. 사용하며 느낀 후기 - 사용기도 대환영합니다.