하나라도 해당되면, 재밌게 읽을 수 있어요!
- 생산성을 항상 고민한다.
- 린 프로세스 이론은 아는데, 실전에서 써먹어 본 적이 없다.
- 린하게 일하는 걸 매우매우 좋아한다.
프로젝트 관리에 최적인 툴, 노션
개인 사이드 프로젝트를 진행할 때마다 워크스페이스로 노션을 사용한다. 많고 많은 툴 중에서 노션을 쓰는 이유는 크게 2가지인데, 바로 ‘템플릿’과 ‘관계형 DB’다.
템플릿 = 재생산
템플릿을 만들면 언제든지 재생산함으로써 초기 시스템 구축에 필요한 리소스를 크게 단축할 수 있다. 내 경우 린 모델에 기반한 워크스페이스를 템플릿화했고, 프로젝트를 진행할 때마다 바로 사용한다. ‘린 모델‘은 빌드(Build)-측정(Measure)-린(Learn) 과정을 반복(iteration)하는 제품 개발 방법론이다. 빌드부터 린까지 이 하나의 반복을 스프린트라 부르는데, 이 스프린트도 템플릿화했다. 덕분에 획일화된 프레임으로 스프린트를 운영 및 관리할 수 있다.
관계형 DB = 체계적 관리
노션에선 서로 다른 DB끼리 연동이 가능하다. A와 B DB를 서로 연동하면, A에서 B의 특정 필드 데이터를 불러올 수 있고, 그 반대도 가능하다. 또한 실시간 연동이라서 A에서 데이터가 바뀌어도 연동된 B에서 바로 적용된다. 이렇게 불러온 데이터에 함수를 적용하면 더 많은 것이 가능하다. 이처럼 DB 사이의 연동은 워크 스페이스를 더 체계적으로 관리할 수 있다.
린하게 나 홀로 사이드 프로젝트 해보기
나 홀로 사이드 프로젝트로 대학교 친구들끼리 오프라인에서 만나서 책을 교환하는 서비스를 구현하고, 린 모델을 베이스로 프로젝트를 몇 달간 진행했다. 처음에 핵심 기능만 구현한 MVP 모델 제작 및 배포했고, 이후에 스프린트마다 데이터를 기반으로 기능을 조금씩 개선했다.
평소처럼 노션으로 프로젝트를 관리했고, 템플릿 기능 덕분에 모든 스프린트를 체계적이고 획일화된 방식으로 운영할 수 있었다. 스프린트는 크게 5가지 단계로 이루어진다. 1) 스프린트가 시작되면 어떤 문제에 집중할지 생각한다. 2) 선택한 문제의 이면에 숨은 진짜 원인을 파악하고, 3) 이 원인을 해결하기 위한 액션을 진행한다. 4) 액션을 통해 수집한 데이터로 가설을 검증하고 학습한다. 5) 회고를 끝으로 이번 스프린트를 종료한다.
- 해결해야 할 문제 현상 찾기
- 문제 현상 이면에 숨겨진 진짜 원인 찾기
- 목표를 세우고, 원인을 해결할 액션 집행하기
- 액션으로 검증하고, 학습하기
- 스프린트 회고하기
1. 해결해야 할 문제 현상 찾기
스프린트를 시작할 때 가장 먼저 어떤 문제에 집중할지 생각한다. 이때 주로 OKR을 마일스톤으로 사용한다. 이를 위해 프로젝트 초기에 MVP를 만드는 과정에서 OKR을 함께 생각한다. 오브젝티브(Objective)로 ‘신촌 인근 대학생이 한 번쯤 들어봤을 법한 서비스를 만든다’로 설정했고, 이 목표의 달성 여부를 정량적으로 판단할 KR로 ‘WAU 150명’, ‘일주일 기준, 회원가입 전환율 40%’, ‘등록된 책 50권’을 설정했다. 어차피 신촌 인근 대학교를 타겟으로만 홍보할 예정이라, KR에 ‘신촌 인근 대학생’을 별도로 표기하지는 않았다.
이제 OKR을 마일스톤으로 삼고, 스프린트를 운영한다. 매 스프린트를 시작할 때, OKR 트래커를 통해 KR 현황을 빠르게 파악한다. 목표 대비 현재 수치가 가장 낮은 KR을 이번 스프린트에서 해결할 문제 현상으로 잡는다. 저번 스프린트에서 KR2(일주일 기준, 회원가입 전환율)의 목표 달성도(=KR 현재 수치/KR 목표 수치)가 10%로, 다른 KR에 비해 매우 낮음을 볼 수 있다. 따라서 ‘저조한 회원가입 전환율’이 이번 스프린트에서 집중할 문제 현상이다.
2. 문제에 숨겨진 진짜 원인 찾기
OKR 트래커를 통해 발견한 문제는 ‘현상’이지 ‘원인’이 아니다. ‘현상’은 문제가 겉으로 보인 것이고, ‘원인’은 그 문제를 일으킨 본질이자 시작점이다. 즉 이 문제가 왜 일어났는지 알려주는 ‘원인’을 찾아야 하는데, 주로 5 whys 모델을 이용한다. 현재 집중한 문제 현상은 ‘초기 유저가 회원가입을 하지 않는다’이다. 이 현상이 왜 일어나는지 알기 위해 계속 ‘왜?’를 던졌고, ‘처음 접속했을 때, 마음에 드는 책이 바로 보이지 않는다’를 원인으로 설정했다.
3. 목표를 세우고, 원인을 해결할 액션 집행하기
문제의 진짜 원인을 찾았으니, 이제 액션을 할 차례다. 액션을 생각하기 전에 앞서서 액션의 마일스톤이 될 수 있는 ‘목표’를 설정한다. 이 목표는 액션을 스케치할 때 최우선 판단 기준이 된다. 목표로 ‘유저가 홈 맨 최상단을 봤을 때, 자신의 마음에 드는 책이 있음을 느끼게 해준다.’로 설정했고, 이와 얼라인 되지 않는 프로덕트의 기능은 모두 배제했다.
상황에 따라서 ‘목표’ 외에 ‘액션 방향 및 원칙’을 추가로 설정하는데, ‘액션 방향 및 원칙’은 액션의 제약으로 작용한다. 절대 불가능한 일, 하지 말아야 할 일, 액션의 필수 전제 등을 모두 적어놓고, 액션 아이디이에션을 할 때마다 항상 염두에 둔다.
‘목표’와 ‘액션의 방향 및 원칙’을 설정했다면, 액션 방향이 대략적으로 잡혔다고 볼 수 있다. 이제 스프린트에서 어떤 액션을 할지 생각하고, 태스크 보드에 할 일(=태스크)을 기록한다. 유저가 홈 맨 최상단을 봤을 때, 자신이 마음에 드는 책이 있음을 보여주기 위한 방법으로, 책 추천 기능을 상단에 구현하기로 했다.
4. 액션으로 검증하고, 학습하기
주목한 문제 원인이 진짜 원인인지, 액션이 실제로 문제 원인을 해결했는지 검증하기 전까지 모른다. 따라서 액션을 시작하기에 앞서 가설을 먼저 세운다. 처음에 유저가 어떤 반응을 보일지를 대변하는 ‘시장 호응 가설’을 먼저 적고, 이를 정량적으로 보여주는 ‘수치 가설’로 변환한다.
시장 호응 가설을 먼저 쓴 후 수치 가설로 변환하는 이유는 크게 2가지다. 정량적으로만 가설을 다루면, 자칫 스프린트의 핵심(=문제 원인, 액션 목표 등)을 놓칠 수 있다. 반대로, 숫자 없이 가설을 다루면, 가설의 참/거짓을 객관적으로 평가하기 어렵다.
가설 설정이 완료되면 데이터를 수집할 기간을 설정하고 액션을 진행한다. 이 기간, 가설을 검증할 수 있는 실험 데이터가 수집된다. 설정한 수집 기간은 아예 사이드 프로젝트에 신경 쓰지 않고 내 일상에 집중한다. 실험이 끝나는 날 ‘수치 가설’에서 명시된 지표를 기준으로 가설의 참, 거짓을 판단한다. 그리고 학습한 바를 정리한다.
동시에 KR이 어떻게 변했는지를 트래킹한다. 저번 스프린트까지 KR 2의 목표 달성도가 10%이었지만, 이번 스프린트를 통해 30%까지 끌어올렸음을 볼 수 있다. 이제 이렇게 변한 OKR 트래커는 다음 스프린트에서 문제를 찾을 때, 사용된다.
5. 스프린트 회고하기
회고를 마지막으로 스프린트를 종료한다. 이번 스프린트에서 내가 잘한 부분, 학습한 부분, 부족한 부분을 돌아보고 점수를 매긴다. 특히, 부족한 부분은 다음 스프린트에서 보완할 수 있도록 신경 쓴다.
노션 템플릿으로 스마트하게!
노션 템플릿을 잘 활용한다면 업무 효율을 크게 늘릴 수 있다. 특히, 나만의 업무 프로세스를 반영한 템플릿을 만든다면, 새로운 프로젝트나 팀에 합류할 때마다 바로 재생산하면 끝이다. OKR, 애자일, 스프린트를 결합한 ‘나’만의 워크 스페이스를 만들고, 이를 템플릿화해서 매 프로젝트나 팀을 리드할 때마다 사용한다. 또 경험과 개인 공부를 통해 새롭게 배운 부분이 있으면, 기존 템플릿에 이 부분을 추가해 ‘나’만의 업무 프로세스를 계속 발전시킨다.
원문: FameLee의 브런치
함께 보면 좋은 글
