성공적인 사이드 프로젝트 만들기
DDD 5기 회고
어제 사이드 프로젝트가 끝났다. 3개월 조금 넘게 함께 했던 팀원들과 즐겁게 마무리 지었다.
배포는 아직이지만, 디자인 분야 1등, 팀 내 최다 MVP, 비핸스 업로드 그리고
가치를 매길 수 없는 좋은 팀원들과의 협업까지. 좋은 사람으로 좋은 결과를 얻었던 프로젝트였다.
성공의 기준을 정확히 정의하기는 어렵지만, 어느정도 성과를 얻은 프로젝트를 했다고 생각한다.
그래서 이 프로젝트를 진행하면서 깨달은 방법들을 공유하고자 한다.
1. 아이템은 신중하게, 그러나 모두가 인정할 수 있게
사업 아이템을 고르는 것만큼은 아니지만, 3개월 간 계속해서 끌고가야할 아이템을 정하는 일은 중요하다. 좋은 아이템을 선정하지 않으면, 아이디어 발전이 어렵거나 중간에 다시 아이디어를 짜는 상황이 벌어지기 때문이다.
우리 팀은 미로보드를 활용해서 아이디어를 공유했다.
https://miro.com/index/보드를 이용해 포스트잇으로 자유롭게 아이디어를 내고, 발전시켜나갔다.
대신 본인의 아이디어가 단순히 주관에 의해 평가받지 않도록 일정 기준을 정하고 작업을 시작했다.
- 기존에 얼마나 많은 비슷한 서비스가 있는가.
- 기존 서비스와 차별화를 둘 수 있는 서비스인가.
- 실제로 배포했을 때 어떤 유저가 사용할 것인가.
- 우리 모두가 니즈를 느끼고 있는 아이템인가.
4가지 기준 모두 중요했지만, 가장 중요한 건 4번이 아닌가 싶다. 우리 모두가 정말로 사용하고 싶고, 실제로 개발 필요성을 느껴야한다고 생각했다. 그래야 이 사이드 프로젝트를 계속 할 수 있는 동기부여가 될테니까 :)
모두가 인정하고, 공감하는 서비스인 아이디어 관련 앱을 런칭하기로 결정했다.
2. 기록과 공유는 생명이다.
사이드 프로젝트는 초기 스타트업과 거의 비슷하다. 사실 사이드 프로젝트를 진행하다가 괜찮은 아이디어로 투자받아 스타트업을 시작하는 경우도 많으니, 비슷하다고 봐도 괜찮을 거 같다.
사이드 프로젝트에서는 기록과 공유가 생명이다.
우선 무엇이든 참고할게 없다. 0에서 1을 만드는 중이기 때문이다. 서로가 논의한 사항이, 오늘 나눈 이야기의 결론이, 디자인레퍼런스가 곧 이 사이드 플젝의 히스토리가 된다. 따라서 회의록, 기획서, 화면설계서, 일정 관리 등 항상 기록하고 또 기록해야한다.
우리 팀은 아래 4가지 공유 서비스를 적극적으로 활용했다.
- 아이디어 선정 : 미로보드
- 프로젝트 기록 : 노션
- 화면설계서 : 구글 슬라이드
- 디자인 : 피그마. 제플린
노션 - 일정 기록/공유
자료와 일정, 회의록으로 구분해서 작성했다. 지금 생각해보면 일정이 곧 회의록이라서, 자료와 일정만으로 구분해도 좋을 것 같다.
자료 같은 경우는 위와 같이 디자인 iOS, Server, QA로 나누어 작성했다.
그리고 모두가 같이 공유해야하는 기능 우선순위와 같은 중요한 것들은 자료 메인 화면에 노출시켰다.
디자인은 내부에 to do list / 디자인 가이드 / 스케치 / 화면 설계서 / 참고자료 이렇게 나누어 작업을 진행했다.
그리고 프로젝트 일정도 노션에 적었다. 회의가 끝날 때마다 관련 부서, 논의 사항, 참고사항을 작성했다. 모든 내용은 합의가 완료되었을 때 작성했다. 나중에 헷갈리거나 같은 부분에서 의견이 엇갈릴 경우 다시 찾아 볼 수 있도록 작성했다.
구글 슬라이드 - 화면설계서 기록/공유
구글 슬라이드로는 화면설계서를 작성했다.
화면설계서란 말 그대로 화면을 설계하는 장표를 말한다. 스타트업에서는 디자이너가 쓰는 경우도 있지만 주로 PM, 또는 기획자 롤이 작성한다. 이 장표가 얼마나 중요한지, 이직하고나서 깨달았다.
회의에서 같은 말을 나눠도 서로 다른 생각을 하듯이, 다양한 해석이 늘 존재하기 때문에 문서로 정의하는 일은 중요하다. 특히 프로덕트를 구성하는 화면에서는 더 중요하다.
우리는 스크린 번호, 스크린명, 플로우, 화면 설명을 각 화면마다 작성했고, 개발자분들에게 다운로드 드리는 시간을 주기적으로 가졌다. 서로 다르게 생각하던 지점을 회의를 통해 하나하나 합의할 수 있었고, 결과적으로 개발하는데 크리티컬한 이슈를 피할 수 있었다.
이전에 첫 사이드 프로젝트에서 따로 화면 설계서 없이 구두로 진행했던 경험과 비교했을 때, 훨씬 더 효율적인 의사소통을 진행할 수 있었다.
피그마/제플린
피그마를 선택했던 점은 공유 작업이 가능하기 때문이었다. 디자이너 말고도 개발자들이 작업 현황을 한눈에 볼 수 있기 때문에 바로바로 이야기를 나눌 수 있었다. 뿐만 아니라 회의 중에 피그마 내용을 공유할 때에도 함께 접속해있으면 따로 공유할 필요없이 이야기를 나눌 수 있어서 효율적이었다.
제플린의 경우, 개발자분들과 코멘트로 주로 의사소통을 했다.
단순 수정의 경우 제플린 코멘트로 / 논의가 필요한 경우 단체 카톡방으로 이야기를 나눴다.
3. 매니저는 반드시 필요하다.
일을 할 때는 실무자와 관리자가 있듯이, 아무리 작은 프로젝트라도 관리자가 필요하다고 생각한다. 생각해보면 대학 교양수업에서 하는 팀플에서도 조장을 뽑았던 기억이 났다.
매니저는 말 그대로 프로젝트를 매니징 하는 사람이다. 일정을 관리하고, 의견을 정리하고, 진행 우선순위를 정해주는 역할. 아무리 작은 프로젝트라해도 관리하는 사람이 없으면 쉽게 쳐지고, 무너지고 또는 산으로 간다. 매니저가 없는 프로젝트라면 매니징을 할 사람을 뽑아서 어느정도 책임을 부여하는 일이 필요하다.
4. 정해진 마감은 일의 능률을 올린다.
내가 DDD를 신청한 이유이기도 하다.
기간이 길어지면 프로젝트의 완성도가 높아질거라고 생각하지만, 그 반대인 경우도 많다. 너무 긴 기간으로 인해 체력적으로 지치고, 정신적 소모가 크기 때문이다.
그래서 작은 프로젝트를 단기간 내에 배포할 수 있는 DDD를 선택했다.
3개월의 준비기간 중, 첫 1개월은 기획 및 디자인하는데 많은 시간을 쏟았다. 그리고 어느정도 화면이 나왔을 때 우리는 정기회의를 약속했다. 정기 회의 약속은 일정을 점검하는 동시에 작은 마감의 역할을 하기도 한다.
정기 회의 날짜가 다가오면 본인이 무엇을 했는지 이야기 하기 위해 약간의 압박을 가지고 작업을 한다.
지난 주의 내가 하기로 한 일을 이번주의 내가 해야한다는 생각이 들기 때문이다.
마지막. 사이드 프로젝트는 사이드 프로젝트다.
보통 사이드 프로젝트를 하다보면 자꾸 불만이 생긴다. 일정이 틀어지거나, 사소한 오해가 큰 문제가 된다.
근데 모든 사람의 마음이 100일 수는 없다. 사이드 프로젝트는 말그대로 '사이드'지, '본업'이 아니다. 다들 본업에 충실하게 살다가 사이드 프로젝트를 하러오는 것이기 때문이다.
그리고 네트워킹, 새로운 툴 써보기, 배포 등 각자가 다양한 목적을 가지고 참여하기 때문에 모두의 마음이 같을 수 없다. 그러니 마음을 조금만 내려놓고 작업하려고 노력하자. 내가 하고 싶어서 하는 사이드 프로젝트에서조차 스트레스를 받아가며 하는건 서로에게 전혀 도움이 되지 않는다.
DDD medium
https://medium.com/@dddstudy1
함께한 사람들 - 오레오팀
황재욱 https://woookdev.github.io/
최지연 https://www.behance.net/jiyns257176b6c
배인경 https://github.com/InKyeongBae
황기수 https://github.com/GisuHwang
디깅 서비스 비핸스
https://www.behance.net/gallery/120417383/digging-idea-APP-UI-UX-design
