죽이 되든 밥이 되든,
사이드 프로젝트 여정기
기왕이면 밥이 돼주세요.
제발 밥이 되거라..사이드 프로젝트를 하는 이유는 다양하다.
담당하는 제품이 여러 협업 과정에서 주요 사항이 제외되서 제품 퀄리티가 눈에 차지 않을 경우, 이렇다~ 할만한 포트폴리오가 없다 싶을 경우, UXUI를 한다고 하는데 도통 무슨 업무를 하는지 방향을 잃은 경우, 광고로 부가수입을 창출하고 싶은데 앱을 나 혼자 만들기는 어렵고 등등등
현재 만족스러운 제품을 만들 수 있는 환경이 아니기 때문에 혹은 실무 협업을 직/간접적으로 채우기 위해
혹은 이직을 위해 현재 상태에서 다양하고 더 나은 결과물을 내기 위한 나와 우리의 니즈는 다양하다.
이런 다양한 목표를 가지고 온 사람들이 하나의 제품을 만들기까지의 경험을 기록하며 회고해보려 한다.
1. 동기부여
지은이는 몸담고 있는 회사에서 마의 3년 근속을 지나면서 전후로 크게 당시 찾아온 공황과 함께 동기가 떨어졌었다. 일단 주어진 업무는 처내고 있긴 했으나 업무니까, 해야하니까, 목적없이 속절없이 무조건적인 시간을 표류하며 에너지를 잃고 능률은 떨어지고 자신감도 잃은 악순환의 연속이었다.
정신 차려보니 목적지와 한참 떨어진 지점에서 동 떨어진 나를 스스로 더이상 봐줄 수 가 없었다.
내 직군에 대한 목적과 목표의식을 되찾기 위해 사이드 프로젝트를 선택했다.
2. 목표합의
얼굴 생판 모르는 개발자, 디자이너들이 모여 어색한 첫만남을 시작한다. 하지만 어색함 뻘쭘함보다 더 중요한 의사결정이 필요하니 그것이 무엇이냐 바로 목표합의이다 약 4개월이라는 짧지 않는 프로젝트를 끌고 가는 것이라 서비스는 어떻게 제공할건지 어디까지 구현할것인지 배포까지가 목표인지 스펙과 초반 목표 합의를 흐려지지 않게 끝까지 유지하는것이 가장 중요하다고 느낀다. 중간중간 목표가 흐려지는 경우가 응당 생기기 마련인데 PL이든 프로젝트 리딩 담당자가 리마인드 해주는것이 중요하다. (이렇게 해도 막상 발표 후에 늘어지는게 사람이다) 나의 경우, 마켓에 한달이라도 올라가 있는것이 만들어 놓고 배포 못했어요와 마켓에 올라갔었고 사용자가 적어 내렸다 와는 확연히 다른 경험이라 생각한다. 마켓에 올리기 위해서 OS 가이드가 어떤것이 있는지 파악해야 하고 필수로 들어가야 하는 기능도 초기 기획시 검토해야 하기 때문이다. 어디까지 목표로 삼을건지 팀원 모두가 한 방향을 바라보는것이 중요하다.
3. 진행과정
첫번째, 팀원들 모두가 공감할 수 있는 서비스가
뭐가 있을지 고민했다. 내가 속한 팀은 20대 중후반
부터 30대 초반까지 나름 다양한 멤버들로 구성되
어 있어 구성원들의 교집합된 관심사를 서치했다.
(tmi : 나는 나이를 끝까지 밝히지 않았다.)
그 결과,
모두 여행이라는 키워드를 가져갈 수 있었다. 여행
을 준비하면서 가장 설레일때가 언제인가 바로 여행
일정을 짤때 아닌가, 친구와 함께 일정을 공유하고
같이 짤 수 있는 서비스를 만들어 보자!로 결과가 도출됐다.
그리고 기록은 무조건 촘촘히 ⭐️
촘촘한 기록은 나중에는 탄탄한 재산이 된다.
서비스 구체화를 위한 유저 시나리오를 작성했다.
우리의 페르소나는 여성 1명, 남성 1명, 성별과 무관한 1명 자웅동체 등 평소 성향을 고려하여 잡았다.
사용자의 기대목표를 따라가다 보니 초기 스펙과 다
르게 다른 유저의 일정까지 서로 공유하는 기능
도 추가되었다. 일정도 실시간 반영이 가능해야 하
고 작성 중 먼저 수정이 진행될 경우 어떻게 노티할
건지에 대한 경우의 수도 촘촘히 좁아졌다.
앞서 말한 기능들을 다 포함하자는 아니고 우리가
가지고 있는 리소스와 일정 대비 서비스의 완성도를
고려하여 필수 기능, 비필수 기능, 없으면 섭섭한 기
능으로 분류되기 시작했다.
세번째, 서비스 컨셉을 위해 네이밍 프로듀스 101
을 만들었다. 연련대별로 성별별로 다양한 의견
이 나왔고 기록하다(write) + 여행 (trip)을 합쳐
라트립 Ratrip 이라는 서비스명이 탄생했다
필자가 의견으로 낸 네이밍이 뽑혔다 (훗✌�)
의견중에 모두의 여행 줄여서 모여도 좋은 아이디어
였고, 나보다 젊은 사람들의 생각도 들어보고 요즘
트렌드는 어떤지 어떤 앱 서비스가 가장 사용이 높
은지 왜 높은지 어떤 점이 와우포인트인지 다양한
아이디어를 나눠 볼수 있는 시간이었다.
4. 작업
위 세번의 과정들을 지나고 나면 본격적인 작업을 시작하게된다. 이때 업무를 분장하고 일정을 나눈다.
서로의 능력과 일정에 맞게 롤을 정하는 것이 중요하고 협업을 위해 같은 직군의 동료와 같이 작업할 툴이나 컴포넌트 규칙도 정해두는 것을 추천한다.
어쩌면 회사에서 사용해보지 못한 툴을 경험할 수 있고, 회사에서는 업무로 마주치지 않는 직무와 커뮤니케이션 할수 있는 기회도 많아진다.
컴하다보면 같은 제품을 바라보는 다른 직무끼리의 의견이 얼마나 다른지 어떻게 파악할 수 있는데 필자의 경우 백엔드 개발자와 프론트 개발자의 시선을 좀더 이해하게 됐는데 회사에서는 과정보다 결과로 마주하는 경우가 거의이 다보니 어떻게 왜 이런 결정이 나는지 이럴 수 밖에 없는 환경은 무엇인지 자세히 알기 어렵다.
상대방의 입장과 환경을 알다보면 왜 보수적인 스텐스인지, 이 의견까지 도달하기 위한 배경을 무엇이었을지 이해하게 되고 좀 더 스무스한 커뮤니케 이션을 할 수 있게 된다. 그렇다고 무조건 양보를 하라는건 아니다. (누구나 의견 조율에서 어 리틀 빗 답답함은 있을 수 있다 잘 포용해보자)
지속적인 커뮤니케이션을 위해서는 중간중간 리뷰와 밋업을 통해 지속적인 피드백과 개선이 이루어져야 한다.우리의 경우는 주 1회 온라인 밋업과 주2회 오프라인 밋업을 가졌다. 연말연시가 껴있는 일정이라 다같이 한번에 모이기는 쉽지 않았지만 온라인 밋업은 평일 퇴근 시간 이후로 모이기로 한 약속의 미팅이었기 때문에 모두 한번에 결석 없이 잘 참석해주었다.
.
.
.
이어서 2탄에서
