원활한 협업을 위한 Notion의 프로덕트 관리 시스템

하룻밤 새 수백 건의 문의가 빗발치기 시작했을 때, 일이 생겨도 제대로 생겼다는 생각이 들었습니다. 엔지니어링 팀이 지원팀도 모르게 새로운 기능을 출시했고, 지칠 줄 모르고 밀려드는 고객 문의에 긴 밤을 꼬박 지새웠죠.

여기서 끝이 아니었습니다. 프로덕트 마케팅 팀은 론칭 몇 주 전부터 릴리스 노트 작성을 가지고 매주 10여 명의 엔지니어들을 들들 볶았고, 각 부서들은 동일한 프로덕트 론칭을 추적한답시고 팀별 캐치업 미팅을 제각각 진행하고 있었습니다. 우리는 서로 소통하기 위해 그야말로 엄청난 시간을 낭비하고 있었어요.

Notion은 한창 성장 중이었고 당시 다섯 개의 엔지니어링 팀이 수많은 프로젝트를 동시다발적으로 진행 중이었지만, 어떤 기능이 실제로 론칭되고 있는지, 왜 그런 기능을 개발했는지 완벽히 이해하고 있는 사람은 몇 없었습니다. Notion이 결국 효율적인 부서 간 협업을 달성하지 못했다면 아마 비즈니스 확장은 꿈도 꾸지 못했을 거예요.

모든 스타트업이 비슷한 고충을 토로합니다. Twitter, Oculus, Robinhood에서도 겪었던 일이고, Notion도 예외는 아니었죠. 그러다 보니 이러한 문제를 극복하기 위해 우리 팀이 어떠한 솔루션을 구축했는지 그 경험담을 공유하면 좋겠다는 생각이 들었습니다.

이 글에서는 Notion에서 구축한 여러 시스템과 프로세스를 소개해 드리려고 합니다. 저희가 어떻게 엔지니어링과 프로덕트 업무의 최신 정보를 실시간으로 공유하면서도 혼선은 줄였는지 설명해 드릴게요. 템플릿도 공유해 드리니 팀 니즈에 맞게 잘 활용하셨으면 좋겠습니다.

Notion에 입사한 뒤 제가 가장 먼저 한 일은 엔지니어와 디자이너들이 평소 어떻게 프로덕트를 개발하고 론칭하는지 파악하는 것이었습니다. 스프린트 때마다 개별 문서를 만드는 팀이 있는가 하면, 하나의 큰 공동 작업 문서에 모든 업데이트를 기록하는 팀도 있었죠.

많이 보던 광경이었습니다. 회사가 커지면서 각 팀의 업무 방식이 차차 굳어지게 되고, 결국은 팀 간의 유연한 협업이 어려워지곤 하죠. 물론, 모든 팀이 각자에게 맞는 최선의 방법을 찾는 것은 자연스러운 일입니다. 특히 원격 근무 환경이라면 더욱 그렇고요. 하지만 Notion은 팀 간의 업무 소통 방식을 표준화할 필요가 있었습니다.

그렇다면 모두가 제각각의 방식으로 일하는 상황에서 과연 무엇을 어떻게 표준화해야 하는 것일까요? 일단은 사람들이 비슷한 방식으로 사용하는 것들을 파악하고 이를 먼저 표준화해야 합니다.

Notion의 경우 엔지니어링 팀, 프로덕트 팀, 디자인 팀이 모두 '팀', '프로젝트', '작업'이라는 3가지 개념을 중심으로 업무를 진행하고 있었습니다(아래에 각 용어의 정의를 설명해 두었습니다). 저희는 우선 각 용어를 정의한 다음, 회사 전체 문서에 이를 기록해 모두가 동일한 방식으로 프로젝트를 이해할 수 있도록 했습니다.

표준화하면 안 되는 것을 정하는 것도 중요합니다. Notion의 경우 팀 회의 진행 방식이나, 팀에서 사용할 목업 툴 선택에 대해서는 온전히 팀의 판단에 맡겼습니다. 몇 가지 기본 규칙을 정한 후 그 외에는 직원들이 자유롭게 일할 수 있도록 한 것이죠.

이러한 구성 요소들을 제대로 파악해 표준화해놓으니 프로덕트 팀과 엔지니어링 팀의 모든 업무를 정리하는 데 큰 도움이 되었습니다. 하지만 이제 회사의 다른 팀들과도 그들이 이해할 수 있는 언어로, 일관성 있게 소통할 필요를 느꼈습니다.

저희는 이 작업을 보다 효율적으로 진행하기 위해 4가지 파트로 구성된 의사소통 시스템을 구축했습니다.

• 팀 — 프로젝트를 진행하기 위해 모인 사람들의 그룹

• 프로젝트 — 개별적이고 독립적으로 론칭 가능한 업무로, 프로젝트 아래에는 '작업'이라는 하위 개념이 포함

• 작업 — 개인에게 할당되는 업무 아이템

• 업데이트 — 각 프로젝트에 대한 간결하고 알아보기 쉬운 요약으로, 업데이트는 2주마다 기록

'프로젝트'나 '작업'의 개념에 대한 이해를 공유하면서 엔지니어링 팀이 다른 팀과 업무를 조율하기가 쉬워졌습니다. 또, '업데이트'를 통해서는 전사 차원에서 업무의 방향성을 이해하는데 도움을 받았죠. 각 파트는 마치 각각의 Notion 데이터베이스처럼 서로 연결되어 하나의 시스템을 만들어냅니다. 말하자면 모든 팀의 업무 파악과 수월한 협업을 위해, 4개의 층위로 구성된 회사 시스템을 구축한 것이죠.

물론, 여러 가지 다른 시스템이 있을 수 있습니다. 스프레드시트나 문서 폴더로 업무를 진행할 수도 있고, 스프린트나 마일스톤을 기준으로 업무를 정리할 수도 있겠죠. 하지만 어디에서 시작할지 고민하고 있다면, Notion의 방식을 템플릿에 전부 기록했으니 한번 확인해 보세요.

그럼 이 시스템의 각 파트와, 시스템이 어떻게 구성되었는지, 어떤 유저들이 사용하면 좋은지 조금 더 자세히 설명해 드릴게요.

프로젝트 정리의 기본은 담당자를 명확히 하는 것이지만 정확한 팀 목록을 만드는 것은 생각보다 쉽지 않습니다. 소프트웨어를 만드는 일의 특성상, 다양한 기능을 탑재하기 위해서는 엔지니어, 디자이너, 마케터, 심지어는 변호사까지, 여러 영역의 전문가들이 함께 일하기 때문입니다.

팀을 찾을 수 있는 좋은 방법은 프로젝트를 위해 사람들이 Slack에 만들어놓은 채널을 찾아보는 것입니다. Slack 채널에는 협업이 필요한 분야별로 사람들이 모여 있는 경우가 많거든요.

팀 정보를 구했다면 이제 명단을 만들 수 있는데, 심플하게 작성해도 좋고, 구체적으로 상세히 작성해도 좋습니다. Notion의 팀 정보 템플릿에는 팀 이름, 팀원, 역할에 대한 간단한 요약, 그리고 Slack 채널이나 기타 팀 관련 자료가 담겨있습니다.

팀 정보가 완성되었다면 이제 각 팀의 프로젝트 정보를 정리할 차례입니다. Notion에 있어서 프로젝트란 제품이나 기능 등 론칭이 가능한 업무로, 대부분의 직원들이 가장 중요하게 생각하는 것이기도 합니다.

또, 영업팀, 법무팀, 엔지니어링 부서의 하위 팀들도 프로젝트에 많은 신경을 씁니다. 직접 빌드를 하지는 않아도 각자의 업무를 효율적으로 진행하기 위해 프로젝트의 진행 상황을 파악하는 것이 중요하거든요. 특히, 아래와 같은 프로젝트 정보가 큰 도움이 됩니다.

• 프로젝트 목표 - 무슨 문제를 해결하는지

• 프로젝트 진행 상황

• 론칭일

• 디자인과 의사 결정에 대한 자세한 정보

Notion의 프로젝트 데이터베이스는 위의 정보를 담기에 최적화되어 있습니다. 프로젝트 이름과 설명, 상태, 론칭일 등을 기록하고 관련 문서도 첨부할 수 있죠. 진행 중인 프로젝트를 파악하고 원하는 정보를 찾기 쉽도록 표 형식의 데이터베이스를 사용하고 있습니다.

프로젝트 정보가 정리되고 나면 이제 엔지니어, 디자이너, 프로덕트 매니저가 각각의 프로젝트를 더 작은 단위의 작업으로 나눌 수 있습니다. 작업은 프로젝트 팀의 데일리 실무로, 실제 업무를 진행하는 사람이 이해하기 쉽게끔 구체적이고 자세해야 합니다. 실무자에게 초점을 맞추는 것이 아니라 누구나 이해할 수 있는 설명을 적으려고 하면 결국 모호하고 쓸모가 없어져 버려요.

Notion은 실무 담당자에게 자세한 작업 정보를 제공하기 위해 속성을 사용합니다. 우선순위, QA 진행상태, 담당 엔지니어, 관련 프로젝트 등을 속성으로 만들면 중요한 정보를 간편하게 표시할 수 있습니다. 속성은 원하는 대로 새로 만들 수 있어요.

마지막 파트는 프로젝트에 직접 참여하지 않는 이들을 위한 업데이트입니다. 여러 작업이 하나의 프로젝트를 만드는 것처럼, 여러 프로젝트의 진행 상황을 모아 업데이트를 진행해야 합니다. 업데이트에는 꼭 공유해야 하는 정보를 정리해 담아야 합니다. 모든 실무 작업의 세부 내용까지 알려주는 것이 목적이 아니니까요.

주간 업데이트는 회사 전체를 위한 것이기 때문에 누구나 이해하기 쉬운 언어로 작성하는 것이 좋습니다. 저는 엔지니어링 팀이 작성하는 개별 프로젝트 업데이트 콘텐츠를 가져와 전체 업데이트 페이지에 사용합니다. 이렇게 하면 이전 업데이트를 함께 찾아보고 검색하기에도 수월합니다. 업데이트는 이메일이나 문서 형식으로 작성해도 괜찮습니다.

저는 주간 업데이트에 세 가지 내용을 포함시킵니다.

• 프로덕트 론칭 — 해당 주에 외부 고객을 대상으로 론칭한 모든 프로젝트의 목록

• 공지 사항 — 현재 진행 중인 사안들에 대한 새로운 소식. 새로운 제품사양 설명서이나 프로젝트 지연 소식 등, 좋은 소식일 수도 있고 안좋은 소식일 수도 있습니다.

• 참고 사항 — 최근 알게된 것들이나 프로덕트 팀, 엔지니어링 팀 내 변경사항 등

업데이트에 포함할 내용은 회사의 우선순위에 따라 조절되어야 합니다. Notion에서는 새로운 기능 론칭을 중시하고 있었고, 따라서 모든 팀에 론칭 계획을 공유해야 했습니다. 만일 회사에서 중요하게 다루고 있는 다른 사안이 있다면, 해당 주제에 관련된 정보를 업데이트해주는 것이 좋습니다.

시스템을 실제로 사용하는 사람이 없다면 지금까지 이야기한 모든 것들이 결국 무용지물이 되겠죠. 저희는 사람들이 이 시스템을 실제로 사용하도록 하기 위해 시스템의 가치를 보여줘야만 했습니다.

저희의 목표는 모든 직원이 번거로운 추가 작업은 최소화하고, 협업은 원활하게 해낼 수 있도록 하는 것이었습니다. 미묘한 균형잡기가 아닐 수 없죠. 이를 위해 저희는 시스템의 여러 파트를 연결할 수 있는 방안들을 강구했는데, 이러한 연결성을 활용하면 한 파트가 강화되면서 다른 파트의 가치도 올라가고, 자연스럽게 사람들이 시스템 전반에 기여하는 순환 구조가 만들어집니다.

예를 들면, 저는 주간 업데이트 하단에 프로젝트 트래커를 임베드합니다. 프로젝트에 대한 세부 사항이 궁금한 사람이라면 누구든 정보를 찾아볼 수 있죠. 그러다 보니 엔지니어링 팀에서도 프로젝트 정보를 최신으로 유지하려고 노력하게 됩니다.

각 엔지니어링 팀에서도 프로젝트 문서 안의 작업 데이터베이스를 적극 활용합니다. 특히, 팀과 관련 있는 작업만 보기 위해 필터를 적용한 보기를 자주 확인하죠. 데이터베이스에서 프로젝트 페이지를 여는 사람은 누구나 프로젝트 안에 포함된 작업과, 각 작업의 진행 상태도 볼 수 있습니다.

다른 부서의 시스템과 연결성을 강화하는 것도 좋은 방법입니다. 프로덕트 마케팅 팀의 경우 프로젝트 트래커에서 론칭일을 확인하고 자신들의 페이지에서 론칭 캘린더를 생성합니다.

프로세스가 어느 정도 정립되고 나니 마침내 시스템이 완성되었습니다. 프로덕트 업무와 엔지니어링 업무를 한 곳에 모으고, 회사의 모든 사람들과 커뮤니케이션을 쉽게 하면서, 번거로운 추가 작업은 최소화하는 시스템이 되었죠. 여러분도 이 시스템을 회사의 프레임워크로 활용해 많은 도움을 받으셨으면 좋겠습니다.

하지만 스타트업은 모든 것이 빠르게 변화하고, 기업이 성장하면서 사용하는 시스템도 바뀌게 됩니다.

따라서 각 팀에 어떤 정보가 필요한지를 늘 파악하는 것이 무엇보다도 중요합니다. 프로덕트 하나를 구축하는 데는 온 마을이 필요합니다. 그리고 모두의 니즈를 이해하는 것이 회사의 성장 시기에도 투명한 커뮤니케이션을 유지한 Notion의 비결이고요.