[프로젝트 진행하기 #2] 서비스 기획

프로젝트 진행과정 2탄이다. 이번 포스팅에서는 1탄에서 선정한 베이스 아이디어를 바탕으로 서비스 기획을 하는 과정을 간단히 다뤄보고자 한다. 

 

🗨️시작하기전에

앞서 1탄에서 문서화를 위해 Notion을 사용한다고 언급했다. 문서화를 어디까지 해야될까?에 대해서는 추후 다룰 예정이다. 하지만, 다른건 몰라도 "기획"단계에서의 문서화는 반드시 진행해야한다.

 

문제 정의, 경쟁 서비스 분석, 회의록, 기능 정의 등 기획과 관련된 모든 것은 반드시 문서화 해야됨을 명심하자.

 

내 친구가 항상 입에 달고 사는 말이 있다. "기획이 8할이다."라고 그 친구가 항상 말한다. 나는 이 친구 말에 진짜 공감하는게 실제로 "오늘의 출근" 프로젝트와 "Reborn" 프로젝트를 진행하면서, 기획이 중요성을 많이 느꼈다. 기획이 완전하지 않으면 반드시 개발 단계에서 삐걱댈 것이다. 왜냐하면, 기획이 완전하지 않으면 A와 B가 서비스를 이해한 내용이 다르고, 다른 방향으로 개발할 가능성이 있다. 결국, 다시 맞춰서 개발해야될 가능성이 높아지고, 시간 소모가 커진다.

 

따라서, 100% 완전한 기획은 아니더라도 70~80%정도 완벽한 기획을 가지고 시작해야 한다. 기획을 문서화 하는 이유도 여기에 있다.

 

🩺 경쟁 서비스 분석

우리가 앞서 1탄 "아이디어 구상하기" 단계에서 베이스 아이디어를 브레인스토밍을 통해 정했을 것이다. 그렇다면, 우리 아이디어와 유사한 플랫폼을 조사해보자.

 

경쟁 플랫폼을 조사해야, 타 플랫폼들의 좋은점과 불편한 점을 파악하고, 문제 정의를 할 수 있으며, 고객의 요구사항 분석까지 이어질 수 있다.

 

예를 들어, "팀원 모집 플랫폼"을 만든다고 해보자. 그러면 경쟁 서비스로는 에브리타임, 캠퍼스픽, 프로그래머스, 커리어리, 비긴메이트 등이 있을 것이다. 그러면, 각 플랫폼의 특징, 좋은점, 불편한점, 사진 등을 문서로 정리해보자.

 

또한, 지구에는 70억명의 사람들이 살고 있고 따라서 우리가 생각한 아이디어는 분명 지구 어디선가 누군가 반드시 생각하고 서비스를 도전했을 것이다. 따라서, 우리와 유사한 경쟁 서비스는 최소 4~5개는 반드시 나올 것이다. 우리랑 결이 비슷한 여러 플랫폼들까지 직접 들어가서 이용해보며 반드시 경쟁 서비스를 분석하자.

⚠️ 문제 정의

이제 앞서 한 경쟁 서비스 분석을 통해 어느정도 문제 정의가 가능할 것이다.

 

예시로, 우리의 베이스 아이디어가 "공모전 등 팀원 모집 플랫폼"이라고 해보자. 그러면 아래와 같이 문제 정의를 할 수 있겠다. (사진은 확대해서 봐주십쇼... 양해부탁드립니다.)

"이음" 플랫폼의 문제정의 (1)

이음 플랫폼 문제정의 (2)

 

서비스라는 것이 유저들의 요구사항을 바탕으로 탄생하고 이루어지는 것이다. 만약, 유저들의 니즈를 전혀 파악하지 않고 서비스를 기획하면 좋은 서비스라고 할 수 없다. 따라서, 문제 정의를 통해 고객들의 요구사항을 어느정도 파악해보고 이를 바탕으로 기능 정의까지 확장해보자.

 

🏃 요구사항 분석

이제 앞서 한 경쟁 서비스 분석과 문제 정의를 바탕으로 실제 고객들의 요구사항을 추가로 파악해보고, 이를 바탕으로 기능 정의까지 확장해볼 것이다.

 

요구사항 분석은 나는 아래 단계로 진행했다. 무조건 이 단계로 진행할 필요는 없고 그냥 참고용으로만 봐주면 좋겠다.

 

1. 서비스 이용 대상 명확히 하기

 

우리 서비스 고객의 요구사항을 파악하려면 우선 고객이 누구인지부터 명확히 할 필요가 있다. 고객은 고등학생, 주부, 수험생, 회사원, 기업 등등 매우 다양할 것이다. 이때, 고객이 어떤 고객인지 자세한 수식언을 통해 설명할 필요가 있다.

 

예시로, 수능 공부 플래너를 개발한다고 해보자. 그러면 서비스 대상을 단지 "수험생"이라고 하지 말고, "공부 일정 관리에 어려움을 겪는 수험생들" 이런식으로 자세히 설명해라.

 

또 다른 예시로, 우리 "이음" 서비스는 "공모전, 개인 팀프로젝트, 졸업작품, 대회 등 같이 나갈 팀원을 구하는 모든 사람들" 이라고 서비스 대상을 명확히 했다.

 

이렇게 명확한 스코프의 이용 대상을 정하면 요구사항 분석을 하는데 큰 도움이 될 것이다.

 

2. 서비스 목표에 대해 명확히 하기

 

우리 서비스를 한줄로 정의하고, 궁극적인 목표를 잡으면 프로젝트 진행 방향을 잡기도 좋고, 프로젝트를 다른 사람에게 소개할 때도 우리가 어떤 서비스인지 설명하기 쉬워진다.

 

예시로, 토스 같은 경우는 "금융의 모든 것 토스에서 쉽고 간편하게"라는 슬로건을 가지고 있다. 그리고 토스는 "금융부터 바꾼다, 모든 것을 바꿀 때까지"라는 궁극적인 목표를 가지고 쉽고 빠른 금융을 추구하며 서비스하고 있다.

 

또한, 내가 진행하는 "이음" 서비스의 경우는 "학생들이 공모전 및 팀 프로젝트를 같이 할 인원들을 쉽게 구하도록 하여, 프로젝트 경험을 쌓아 미래에 도움이 될 수 있도록 하자!"라는 목표를 가지고 있다.

 

마지막으로, 내가 진행하는 "외국민" 서비스의 경우는 "외국인 유학생들이 국민대 유학 생활에 적응을 도와주도록 하자"라는 목표를 가지고 있다.

 

이렇듯, 우리 서비스가 추구할 궁극적인 목표를 세워보자. 그러면, 우리 서비스가 갈 방향이 명확해지고 요구사항 분석도 간단해진다.

 

3. 설문조사 또는 인터뷰

 

우리가 파악한 고객들의 요구사항과, 실제 고객의 요구사항은 다를 수 있다. 따라서, 우리 서비스를 이용할 고객들을 대상으로 설문조사 또는 인터뷰를 진행하는 것이 좋다. 요즘 구글폼이 잘 되어있어서 설문조사도 예전보다 쉽게 진행할 수 있다.

 

뿐만 아니라, 우리가 공모전이나 지원을 받는 프로젝트에 도전하는 것이라면, 해당 설문조사 또는 인터뷰가 신뢰성을 더해줄 것이다. 

 

아래는 내가 "이음" 플랫폼에서 무작위 대학생들을 대상으로 진행했던 설문조사 결과이다.

 

위 사진과 같이 고객들이 어떤 어려움을 겪고 있고, 어떤 기능을 원하는지 파악할 수 있게 된다.

 

또한, "외국민" 프로젝트에서도 교수님게 협조를 구하여 외국인 유학생들 몇명을 대상으로 인터뷰를 진행했다. 아래 사진은 인터뷰 내용 중 일부이다.

 

 

이렇듯, 설문조사 또는 인터뷰 등을 통해 실제 고객의 요구사항을 파악하고 비교하는 것도 중요하다.

 

4. 요구사항 분석

 

이제 어느정도 고객들의 요구사항이 윤곽이 잡혔을 것이다. 문제 정의 + 설문조사 + 인터뷰 등을 바탕으로 어떤 요구사항이 있는지 정리해보자. 그리고 이를 바탕으로 간단하게 예상 주요 기능을 정리해보자. 아직 세부 기능 사항까진 생각할 필요 없고, 우리 서비스의 주요 기능을 간단하게 적어보는 것이다.

 

5. 요구사항 분석을 바탕으로 필요 인력 탐색

 

이제 우리 서비스의 윤곽이 잡혔을 것이다. 서비스 규모가 어느 정도이며, 어떤 인력이 필요한지 대충 파악할 수 있을 것이다. 또한, 우리가 웹 or 앱 서비스인지, 어떤 기술 스택을 사용해야 적합할지 어느정도 인지하고 있을 것이다. 그럼 이를 바탕으로, 어떤 인력이 필요한지 탐색해봐야한다.

 

예를 들어, AI 팀원 추천 서비스 기능이 있는데 우리 팀에 AI가 없다? 그럼 AI 담당 팀원을 모집하면 된다. 웹 서비스인데 React를 다룰줄 아는 프론트엔드가 1명밖에 없다? 그럼 추가로 모집하면 된다. (이건 프로젝트 규모에 따라서... 보통 프론트 2명, 백엔드 2명은 기본으로 깔고가는 것을 추천한다.) 추가적으로, 우리가 웹/앱 서비스라면 디자이너는 무조건 영입하는 것을 추천한다. 디자이너가 있고 없고 결과물 차이가 크다. 디자이너가 없다면, 프론트 개발자가 Figma를 다루던가, 아니면 UI를 상상해서 개발해야 된다. 이는, 굉장히 효율이 떨어지고 어려운 작업이다. 또한, 디자이너가 보는 관점하고 우리 컴퓨터 공학과가 보는 관점은 분명히 다르다.

 

내가 개인적으로 추천하는 팀 구성은 이렇다.

• 프론트엔드 개발자 2명
• 백엔드 개발자 2명
• AI 개발자 1명
• 디자이너 1명

학생 레벨 프로젝트에서는 이정도가 딱 적합하다. 서비스 규모에 따라서는 각 분야별로 1명 정도 더 모집할 수 있다. 추가적으로 아래는 내가 진행했던 프로젝트들의 인원 규모이다. 참고용으로 봐주면 좋겠다.

 

이음 : 프론트 2명/백엔드 2명/AI 1명/디자이너 1명

외국민 : 프론트 2명/백엔드 2명/AI 2명

오늘의 출근 : 프론트 3명/백엔드 2명 (망함)

Card Clash : 프론트 2명/백엔드 2명

Reborn : 프론트 2명/백엔드 3명

 

각각 프로젝트가 어떤 프로젝트인지는 [프로젝트 진행하기 #0] 글에 자세히 나와있으니 참고바란다.

 

👧 정식 팀원 모집

이쯤에서 갑자기 이런 의문이 들 수 있다. "처음부터 같이 할 팀원을 모집하면 되는거 아니야?"라는 생각이 드는 것도 당연하다. 하지만, 내가 정식 팀원 모집을 이렇게 뒤로 뺀 몇가지 이유가 있다.

 

1. 우리가 어떤 프로젝트를 진행할지, 우리의 실력은 어느정도인지 전혀 모르는 상태에서 무엇을 믿고 우리 프로젝트에 지원하겠는가? 적어도, 어떤 프로젝트를 진행하고자하는지 정보가 필요하기 때문이다. 내가 들어가는 입장이었어도, 이 프로젝트가 무엇을 하는 프로젝트인지도 모르면, 제대로 되지 않은 팀이구나 생각이 들어서 지원하지 않을 것이다.

2. 어떤 기능을 추가할지 전혀 생각하지 않은 상태에서, 무작정 "AI, 백엔드, 프론트, 디자인 필요하겠지~"하고 모집했다가, 잉여 인력이 발생할 수 있다. 위의 과정을 거쳐야 우리 프로젝트 규모를 파악하고 알맞은 팀원을 추가로 모집할 수 있다.

3. 알맞은 기술 스택 인원을 모집할 수 있다. 기술 스택이 서로 맞지 않은 팀원을 데려온다면, Learning Curve가 발생할 것이고, 기량을 제대로 못낼 것이다. 실제로, Reborn 프로젝트를 진행할 때, 대회측에서 백엔드 3명을 Spring / Django / Express 쓸줄 아는 사람으로 배정해줬는데... 서로 다른 기술 스택 때문에 프로젝트가 결국 망했다. 이유는 해커톤 대회여서 각자 새로 기술 스택을 배우기는 어려운 상황이라 MSA 형태로 각자 개발하자고 했었는데, 가뜩이나 해커톤 같이 규모가 작은 서비스에서 MSA 형태로 쪼갤려고 하니깐 오히려 프로젝트의 복잡성만 더 늘어났다. 뿐만 아니라, 각각 프레임워크에 ORM이 있는데, 이게 서로 꼬이다보니깐 결국 망했다... 물론 이건 해커톤이라는 특수한 상황이라 그런거긴 한데, 애초에 소규모 프로젝트에서는 MSA를 추구할 이유가 없다. (채팅 서버 및 AI 서버 분리 정도는 할 수는 있는데...) 어쨋든, 개인들끼리 하는 소규모 사이드 프로젝트에서 MSA는 프로젝트의 복잡성만 늘릴뿐더러, 기술 스택을 통합해서 monolithic architecture로 구성하는 것이 더 좋다. 

 

이제 우리랑 프로젝트를 함께할 인원들을 모아보자. 나같은 경우는 같은 학교 사람들끼리만 진행할 수 있는 프로젝트였기 때문에, 에브리타임에서 팀원을 모집했다. 만약, 이런 상황이 아니라면 다른 곳에서 모집해도 무방하다. (링커리어나 캠퍼스픽 같은 곳...? 솔직히 잘 모르겠음) 또한, 팀원을 모집할 때 되도록이면 포트폴리오를 요구하자. 포트폴리오만큼 이 사람의 실력 및 열정을 알 수 있는 수단은 없다. 팀원이 중간에 도망간다면 대참사이기 때문에, 신중히 골라야한다.

 

아래는 내가 디자이너를 모집했던 공고 예시이다.

 

 

추가적으로, 에브리타임만으로는 우리 프로젝트 개요를 다 알리는 것은 힘들 것이다. 팀원들의 포트폴리오도 보고 싶고, 어떤 느낌인지 사진으로 전달하고 싶기도 하기 때문이다. 하지만, 에브리타임, 링커리어, 캠퍼스픽 플랫폼에서는 이를 전달하기 힘들다. 그래서, 되도록이면 노션 문서를 작성해두고, 공고 글에 추가로 링크를 첨부하는 식으로 진행하는 것을 추천한다. 아래 문서는 내가 디자이너 구인을 위해 작성했던 문서이다. 참고하면 좋을 것 같다.

 

디자이너 구인 | Notion

 

👩‍💻 팀 결성 완료후의 작업

 

이제 완전한 우리 프로젝트 팀을 구성했다! 그럼 마지막으로 2가지 작업을 하자. 안해도 되는 작업이긴 한데, 하는 것을 추천한다.

 

1. 팀원 신상정보 기록 문서 생성

 

우리가 지원금을 받으면서 하는 프로젝트나 학교 수업시간에 하는 프로젝트라면, 생각보다 팀원들의 신상정보가 필요한 경우가 굉장히 많을 것이다. 왜냐하면, 계획서나 보고서 등 팀원의 신상을 첨부해야되는 경우가 많기 때문이다.

 

그래서 간단하게 이름, 학번, 전화번호, 이메일, 학과 정도만 써둔 문서를 생성해두면 자주 사용할 것이다.

 

2. 팀내 역할 분배

 

이건 프로젝트 성격에 따라 다를 것이다. 만약에, 우리가 지원금을 받으면서 진행하는 프로젝트이다? 그러면 팀 내 예산을 담당할 회계 역할을 한명 정하는 것이 좋다. 팀장이 회계 업무까지 다 처리하긴 굉장히 힘들다. 팀장은 팀원 일정 조율, 팀 진행 상황 체크, 각종 서류 작업하는 것 만으로도 충분히 바쁘다.