발표 주제
모바일 웹 브라우저
안드로이드 개발
바나나 브라우저라는 사이드 프로젝트를 개발하면서 있었던 경험 공유
만든 이유
개인이 제품에 영향력을 발휘하기 쉽지 않았다
회사 주도의 오픈소스에 기여했었다
아쉬운 마음에 사이프 프로젝트를 시작하게 되었다.
사이드 프로젝트로 브라우저를 선택한 이유
관심있는 도메인이었다
사용자 확보가 쉬울 것 같았다.
메이저 브라우저가 아쉬웠다
사이드 프로젝트 초기
실행 없이 아이디어 회의만 무한 루프 돌아서 아쉬웠다
빠른 제품 출시 먼저 해보자는 의견이 나왔고 그렇게 했다
크로미움의 오픈소스를 아이콘만 바꿔서 출시했다
> 빠르게 실행하는 것이 중요하다 판단
이전에 진행했던 사이드 프로젝트는 지나친 장인정신으로 출시되지 못하고 흐지부지 된 적이 많다
아이콘 바꾸는 과정을 통해 기본적인 구조 설계를 할 수 있었다.
첫 출시 목표
크로미움계열의 브라우저의 0.01%인 25만 확보하자!
MVP 기능
사용자들이 가장 원할 것 같은 기능 몇 가지를 잡아 기능 개발
크로미움 기반
광고 차단
개인보안 강화
데이터 절약
첫 출시 과정을 통해 얻은 것
처음 부터 끝까지를 직접 경험할수 있었다.
개발 외에도 다른 직군을 경험해볼 수 있었다.
끝없이 논의 하는 것 보다 빠른 출시가 더 큰 도움이 되었다
첫 출시 이후
출시만 하면 많은 사람이 쓸 줄 알았는데
일주일까지는 몇백명까지 다운 받았다
일주일 지난 이후 급격히 줄어들었다
마케팅이 중요하구나!
첫 방법 - 카페 홍보, 커뮤니티에 홍보
다음 방법 - 앱 검색 최적화
제목/부제목 : 스토어에서 검색하는 경우 노출 될 수 있는 키워드를 중심으로 설정
상세 설명 : 구글 검색엔진을 통해 노출 될 수 있으니 핵심 키워드 중심으로 작성했다
앱 아이콘 및 스크린샷 : 경쟁 제품 대비 눈에 잘띄고 직관적인 디자인으로 첨부했다
> 검색을 통해 앱이 발견이 되게 하고 발견이 되었을 때 다운로드로 이어질 수 있도록 노력했다.
1만 디운로드 달성 이후 - 구글 애즈를 이용해보기도 함
> 광고 플랫폼을 활용하니 효과가 좋았다
마케팅 이후 알게된 것
아무리 좋은 제품도 홍보를 하지 않으면 사람이 알 수 없다
앱 검색 최적화(ASO)는 정말 중요하다
앱 출시 후 한달은 상위랭크로 갈 수 있는 좋은 기회였다.
절대 지켜지지 않는 데드라인
줄어드는 열정
제품을 꾸준하게 만들고 성장했다.
열정은 점점 줄어들었다
1만 다운로드는 기뻤지만 5만,10만때의 감정이 달랐다.
왜?
본업과 사이드 프로젝트 사이에서 시간관리의 어려움
사이드 프로젝트도 재밌지만 그것보다 재밌는 일들이 너무 많았다.
열정 극복하기
1. 벌금내기..
아주 큰 벌금을 줬더니 효과는 좋았다..
2. 선물로 동기부여 하기
팀원들이 선물을 원하지 않아서 실패
3. 모각코
모여서 하니까 성과는 나오는 데 잘 안 모이게 되더라
4. 가스라이팅(?)
발표자 본인이 했던 방법이 나중에 가스라이팅이었다는 걸 깨닫게 되었는데 좋은 방법이 아니어서 아쉬웠다
5. 감정에 호소하기
팀원에게 효과가 없었음
> 효과 없는 극복 방법들.. 해체위기였다
뭐가 문제 였을까
프로젝트에 참여하는 모두가 같은 마음일 수 없다
태스크를 관리하는 매니저 역할의 부재
무리한 목표 설정으로 인해 낮은 성취, 죄책감이 반복되었다
해결방안
주도적일 것이라는 환상에서 벗어나기
처음에는 팀원 모두가 주도적으로 프로젝트를 하기를 기대했다
> 모두가 주도적으로 할 수 없다는 것을 인정
본인의 역할은 기술적인 부분에서 리딩하는 것으로 한정했다
> 본인의 역할이 팀원의 주도성과 무관하게 팀원들이 평균 이상의 실력과 성과를 낼 수 있도록 돕는 것 이라는 생각을 하고 바꿨다
적절한 커뮤니케이션 동기화
스크럼 보드 적극 활용
슬랙으로 자주 진행상황 공유하기
일주일에 최소 한번은 미팅하기
팀원들에게 작은 성공 제공
- 태스크를 잘게 쪼개기
- 패치 사이즈 줄이기 - 작업물과 코드리뷰 효율을 높이기 위해 패치 사이즈 100줄 이하로 제한
- 패딩 일정 도입 - 목표일정과는 별개로 일정이 지연되는 것을 방지하기 위해 패딩 일정 도입
작은 패치들을 길지 않은 시간 내에 넣어 성공하는 경험을 쌓게 했다
회고 횟수를 줄여 죄책감 유발 상황 개선
원치 않은 상황으로 사이드프로젝트에 많이 기여하지 못했을 때 오는 죄책감을 막기 위해 노력했다
아키텍처 개선해서 작업 의존성을 줄였다
퍼블릭 api만을 참조하게 해서 효과적인 협업이 가능했다
적절하게 기술 부채를 활용할 수 있었다
실패하더라도 죄책감이 낮아졌다
코드 리뷰 및 테스트 완화
코드 리뷰와 테스트가 빡빡해서 패치 하나가 한달을 기다릴 때도 있었다
퍼블릭 api는 여전히 빡빡했지만 나머지 영역에는 팀원역량에 기대기로 했다
1:1 면담
잘한 일을 칭찬해주고 팀원의 상황을 파악하는 데 도움이 되었다
이 모든 과정을 통해 얻은 것
시스템적으로 서로가 신뢰할 수 있는 환경을 만드는 것이 중요
다들 좋다고 말하는 기술과 방법론도 지금 상황과 팀에 맞지 않으면 독이 될 수 있음
사이드 프로젝트에서는 제품보다도 팀이 중요
그밖에 시도해본 것
제품 비전 보드 작성
새로운 멤버 영입을 통한 분위기 전환
외부로 영향력 확장하기
느낀 점
사이드프로젝트에서 의견만 나오고 액션이 취해지지 않으면 의견이 흐지부지 되기 쉽다.
매번 사이드 프로젝트를 할 때마다 문제가 되었던 것이 그거였다
의견 공유할 때만 반짝하고 처음부터 큰 것을 바라보니 시작이 쉽지 않았다
빠른 제품 출시가 빠른 시장 선점, 그리고 팀원의 의욕을 부르기도 좋다
