Hustle #1. 허슬 프로젝트 시작

UMC 동아리

안녕하세요. 다람쥐입니다.

올 해엔 UMC 동아리를 하고 있는데요, 방학을 맞아 팀 프로젝트를 시작했습니다.

PM 역할인 학생이 아이디어를 제출하고 디자이너와 개발 직군과 팀매칭을 거칩니다.

여러 차수를 거쳐 모든 동아리원이 매칭이 완료됩니다.

팀 매칭이 끝나면 바로 팀 프로젝트가 시작됩니다.

 

팀 프로젝트 고를 때 고려했던 점들

제가 팀 프로젝트를 고를 때 염두하던 점이 있었어요.

첫 번째로 배포가 빠른 플랫폼을 선택했습니다. iOS, Android, Web 플랫폼 중에서 그 중 Web 플랫폼을 선택했습니다.

결과물을 실시간으로 확인할 수 있다는 건 동기 부여가 잘 되는 장점이 있더라고요.

모바일 플랫폼도 테스트 플랫폼을 통해 빠르게 확인이 가능하지만, 운영 단계에선 여건상 스토어 체제에 따라야 하고 버전 문제가 발생할 수 있는 단점은 여전히 있습니다. 가벼운 프로젝트를 운영하는 만큼 그런 부담을 적게 가져가고 싶었습니다.

 

두 번째로 실제로 운영할 수 있는 가능성을 따졌습니다.

개발부터 운영까지 가는 요소를 여러 갈래로 생각을 해봤어요.

개발부터 쉽지 않은지, 운영하는 게 목표가 아니든지, 또는 운영 하고픈 마음은 굴뚝같지만 현실적으로 진입하기가 쉽지 않은지 따져봤어요.

운영 이후에 일어날 수 있는 이슈나, 팀원간 정치적 여건은 현 상황에선 판단할 수가 없기에, 순전히 아이디어 내용만 보고 따졌습니다.

 

개발이 복잡하다면 런칭까지 오랜 시간이 걸릴 수가 있습니다.

단기간에 진행해야하는 프로젝트인만큼 기능이 과도하다면 완성이 어려울 수 있습니다.

서비스를 소개하고 흐름도를 볼 때 정말 한 가지 목표에만 집중하고 있는지 위주로 확인을 했었습니다.

문어발처럼 서브 기능이 주요 기능만큼 복잡성이 있다면 개발하기 쉽지 않겠다라는 생각이 제일 먼저 들더라고요.

 

개발 난이도가 쉬워도 문제를 해결하는 솔루션을 서비스 차원으로 제공하지 않는 아이디어는 제외했습니다.

모든 프로젝트 아이디어는 문제 인식과 불편함을 해결하려는 차원에서 시작합니다.

다만, 불편함을 해결하려는 솔루션은 서비스에서 명확하게 제시를 해줘야 한다고 생각하는데요.

이게 곧 다른 서비스와의 차별점이 될 수도 있고 서비스만의 매력 포인트가 됩니다.

 

솔루션이 명확하지 않다는 건, 우리가 판을 만들어 놓으면 어떻게든 불편함이 해소될 거라는 막연한 믿음을 의미합니다.

주로 그런 아이디어는 커뮤니티 아이디어가 그럴 확률이 높습니다.

개발 난이도는 쉽지만 토이 프로젝트 수준에선 유저 유입을 성공시키기는 어려울 거라고 판단했습니다.

 

그래서 아이디어 구현만으로 끝나는 1회성 포트폴리오로만 끝나지는 않는지 생각을 해봤습니다.

제 상황으로는 개발 기술을 익히는 용도로 포트폴리오용 프로젝트를 하는 것도 괜찮았지만, 운영 경험을 해보는 게

더욱 중요한 경험으로 가중치를 두었습니다.

그래서 운영을 못하는 게 의도적이든, 의도치 않든 포트폴리오로만 끝날 것 같은 프로젝트만큼은 과감하게 배제를 했습니다.

 

운영이 가능한 프로젝트인지 확인하려고 타겟층이 확실한지 유저 수요층이 확보가 되어 있는지 위주로 확인했습니다.

아이디어 의도는 좋지만 현실적으로 유저 유입부터 쉽지 않은 아이디어는 배제했습니다.

유저층이 시작 단계에서 적더라도 확보가 되어있는 아이디어가 눈에 들어왔어요.

 

관심이 갔던 아이디어들

다 따졌을 때 관심이 가는 아이디어가 두 개가 있었습니다.

허슬과 다른 아이디어였는데요!

둘 다 대회를 열고 진행할 수 있다는 공통점이 있었어요.

다른 아이디어는 스프링 파트를 뽑지 않아서 아쉬웠었어요.

나중에 활성화가 된다면 꼭 기여를 해보고 싶은 아이디어였어요!

허슬은 스프링 파트를 뽑고 있어서 PM 님께 운영까지 해보고 싶다고 어필하여 참여하게 됐습니다.

 

Hustle(허슬) 소개

허슬 서비스는 농구, 축구 등의 스포츠 교류전 또는 대회를 대학 동아리 차원에서 진행할 수 있도록 하는 플랫폼 서비스예요.

대회 현황을 조회하고 대회를 개설하거나 직접 참여를 할 수 있습니다.

부가 기능으론 동아리를 등록하여 온라인으로 관리하고 스포츠별 커뮤니티가 있으며, 친선 교류전 구인도 할 수 있스빈다.

허슬 서비스에서 열린 대회로 랭킹을 확인할 수 있고 개인의 스포츠 데이터를 분석하여 보여줍니다.

 

MVP 기능이 확실히 있고 PM 님의 능력으로 유저층을 확보할 수 있으며,

실제로 운영하고픈 마음도 강렬히 있어서 인상 깊었어요.

 

매칭 성공

모든 동아리 인원이 프로젝트에 매칭됐습니다.

저희 허슬팀은 PM 리더 1분, 디자이너 1분, 프론트(웹) 4분, 서버(스프링) 4분 으로 됐습니다.

PM 님도 서버(스프링) 파트지만 아이디어를 직접 기획해서 PM 으로 되셨는데요.

서버 파트로 활동중이기에, 같이 서버 회의나 개발에도 약간 참여하고 싶다고 하셨습니다.

 

첫 회의

첫 회의는 간단하게 서비스 소개와 현재 디자이너분과 어디까지 진행됐는지 소개하는 자리였어요.

개인적으로 아무래도 다들 처음이고 어색하다보니 인사 하고 친해지는(?) 자리일 줄 알았는데,

그냥 바로 일부터 이야기해서 당황스러웠네요. 🤣🤣

일정 또한 공격적이었어서 그만큼 프로젝트에 열정적이라는 거겠죠?

또 해커톤을 하고 있어서 그런지 처리해야할 것들 먼저 처리한 게 아닐까 싶네요.

 

도메인도 정하고 데모 데이 일정과 개발 일정, 회의 일정을 정했고 디자인에서 정해야할 로고나 여러 상황을 정하기도 했습니다.

끝나고 팀별로 모여 다음 회의까지 뭘 하고 올지 이야기를 했습니다.

PM 님께서도 같이 참여하셔서, 아이디어에 올라왔던 와이어프레임과, 진행된 디자인 피그마를 같이 보면서

궁금했던 점들을 이야기 하는 시간을 가졌었습니다.

 

서버에서 DB 설계를 먼저 하려고 해서 모호했던 부분을 잡을 필요가 있어보이더라고요.

아직 디자인 화면이 다 나온게 아니라서, 금주 중으로 디자인 화면이 확정되면

서버팀은 다음 회의까지 ERD 다이어그램을 짜와서 이야기 해보는 걸로 약속했습니다.

 

그 외 서버 관련 이야기로 깃헙 레포 정책이나 아키텍처, 언어 및 프레임워크와 DB 종류 버전을 정했어요.

아직 개발 들어가는 단계는 아니라서 세부적인 이야기는 다음에 하지 않을까 싶네요!

 

포스팅 계획

포스팅은 프로젝트를 진행할 때 마다 정리해서 올리려고 합니다.

구현을 어떻게 했는지 왜 그런 결정을 했는지 그 때 그 때 정리해두려고요!

많은 기대 부탁드립니다. :)