프로젝트 동아리가 처음인 PM에게 보내는 헌사 (feat. 전 이렇게 했어요)

Team Vi.NO·2024년 2월 25일

Nclouder PM ncloud 네이버클라우드 사이드 프로젝트

Vi.NO 제작기

목록 보기

1/8

축하합니다

먼저 이 글을 만나신 것 축하합니다. 혹시 PM이 처음이신가요? 그렇다면 잘 오셨습니다.
이 글은 PM이 처음인 한 사람의 고군분투기입니다.

이 글을 다 읽고 나시면

서비스 기획안 짜는 법부터 화면 정책집 짜는 법

디자이너와 소통하는 법

개발자와 소통하는 법

일정관리와 기획자의 역할

(에 대해 얘는 이런 생각을 했구나.. ㅋㅋ) 를 알게 되실 겁니다.  

저도 동아리에서 11명이라는 사람들을 이끌면서 2달간 서비스의 초반 기획부터 배포까지.. PM으로 총괄한 것이 처음인데요. 생각보다 사이드 프로젝트에서 PM이 어떻게 프로젝트를 이끌어갔는지 A to Z를 말하는 글들이 부족하더라구요. 저도 많이 헤맸는데요.

사이드 프로젝트 시작하시는 다른 분들도 이 글이 도움이 되었으면 하는 마음으로 글을 씁니다. 당연히 ‘이게 국룰이다. 이렇게 해라’는 글은 아니구요. PM으로서 사이드 프로젝트를 진행하며 느낀 회고이자 일기입니다.

[타임라인] 서비스 기획부터 배포까지

각설하고, 사이드 프로젝트를 시작할 때 가장 고민인 부분은 일정짜기입니다.

제가 프로젝트를 진행했던 타임라인은 이렇습니다.

1) 기획 완료
2) 함께할 크루 찾기 (설득)
3) 디자이너와 디벨롭 + 시안 완성
4) 개발자 이해시키고 플랜 합맞추기
5) 개발과 디자인 그리고 미처 생각하지 못했던 디테일 기획의 무한굴레
6) QA + 오류잡기

하단의 메모는 다음 프로세스로 넘어가기 전에 필수적으로 완료되어야 할 일들을 적어둔 것입니다.

사실 프로젝트를 진행하는 방법론은 참 많죠. 애자일, 워터풀 등등이요. 저는 워터풀 방식을 택했는데요. 아무래도 프로젝트가 처음이다보니 애자일은 조금 한계가 있었던 것 같아요.

<프로젝트 기획하기 (a.k.a. 사람들 꼬시기)>

: 저는 프로젝트 기획이란, 잘 꼬시기 라고 생각했어요. 나와 함께 이 서비스를 만들 사람들을 꼬시고, 이 서비스를 사용할 유저들을 꼬시고, 마지막으로 이 서비스을 짠 나 스스로에게 확신과 근거를 찾아가는 일이라고요.

이 방법은 바로 서비스 기획안이라는 이름으로 세상에 나오게 되죠.

📍서비스 기획안 완성

서비스 기획안은 공감할 수 있는 문제 의식을 잘 드러내어 내 서비스가 꼭 필요한 서비스라고 설득하는 것이라고 생각합니다. 공감할 수 있는 문제 의식을 드러내는 데 가장 초점을 두었어요.

디테일한 기획안 말고, 러프한 버전의 아이데이션 차원으로 작성했던 기획안의 일부를 공유합니다.

🔎 필수로 들어가야 할 항목
1) 기획의도
2) 페르소나
3) 시장 분석 + 타겟분석
4) 서비스 차별성
5) MVP 핵심 기능 소개

저는 사실 서비스 기획안을 완성하기 이전, PM끼리 모여서 기획안에 대해서 돌아가면서 질문/피드백을 하는 시간을 가졌는데요. 이 시간이 정말 도움이 많이 되었습니다. 제 눈엔 꼭 필요하다고 생각했던 것들이 다른 사람에게는 전혀 아닐 수 있거든요. 주변에 다른 기획자가 있다면 많은 대화를 해보시는 것도 정말 추천합니다.

1) 기획의도

: 기획 의도가 잘 설명되면, 서비스 자체에 대해서도 훨씬 이해도가 높아집니다. 더불어 내가 제시한 해법이 아니라, 다른 더 좋은 서비스 혹은 기능 아이디어를 바탕으로 디벨롭시킬 수도 있죠.  

더불어 공감할 수 있을만한 문제 의식을 가졌을 때 다른 사람들도 공감할 수 있고 재밌게 책임감을 갖고 서비스를 만들 수 있다고 생각해요. 시장에서 정말 필요한 서비스인지, 회고할 수 있었습니다.

2) 페르소나

: 특히나 기존 시장에 있는 서비스가 아니라 타겟층이 새로워진 서비스인 경우엔 이 페르소나를 잘 설명하게는 게 중요하다고 생각해요. 페르소나를 설정하는 것이 추후 디자인/브랜딩 방향성을 정하는 데에도 아주 주요한 역할을 하죠. 

3) 시장 분석 + 타겟 분석

: 실제로 내가 이 서비스가 필요하고 시장도 원한다고 생각하지만, 사실은 그렇지 않을 수 있습니다. 내가 만들려고 한 서비스가 얼마나 시장성이 있는지 확인하는 것도 중요합니다. 기껏 만들어놨지만, 이 서비스는 나한테만 필요한 서비스라면..? 흠.. 생각해봐야겠죠?  

4) 서비스 차별성

: 사실 비슷한 서비스들이 정말 많은데, 내가 지정한 문제 의식을 이렇게 구현했을 때 가장 큰 해결법라는 확신을 찾아가는 단계라고 생각해요. 이 서비스는 다른 서비스들보다도 이런 점에서 강점을 가지고, 더 많은 유저가 효용을 느끼며 사용할 것이다 라는 확신이 들어야 한다고 생각해요. 저는 개인적으로 이 부분을 작성하면서 왜 이 서비스를 만들어야 하는지를 가장 확실히 할 수 있었습니다.   

5) MVP 핵심 기능 소개

직접적으로 내가 생각한 기획 의도에 맞게 설계한 기능이 바로 이것이다! 를 보여주는 섹션. 개발자분들은 이 부분을 집중해서 보셨던 것 같아요.   

✍🏻 TIP 이라면, 이 핵심 기능을 어떤 api를 사용해서 어떤 로직으로 구현할지까지 미리 찾아보고 소개하는 것은 아주 좋습니다.   
사이드 프로젝트의 경우엔 개발자분들의 걱정 중 하나는 내가 이걸 실제로 구현할 수 있을까? 시간 내에 완성할 수 있을까? 도 있는데요.   
이때, 미리 찾아본 개발 정보나 개발 방법을 소개하면 개발자분들의 의욕을 더 불러일으킬 수 있습니다. 더불어 PM으로서도 일정 배분부터 개발 프로세스를 대략적으로 가늠할 수 있구요. 

6) BM

사이드 프로젝트의 필수 항목엔 넣지 않았지만, 팀원들의 의욕 상승을 위해 필수적으로 필요하다고 생각하는 부분입니다.

💬 Vi.NO의 서비스 기획안 작성법 편은 따로 작성하겠습니다.

📍 팀원 모으기

이렇게 제 기획에 확신을 가지고, 다른 사람들도 꼬실 수 있는 서비스 기획안이 완성됐습니다. 이제 함께 만들 사람을 찾아 나서야겠죠.

저는 함께할 팀원을 고르는 것이 정말 어려웠었는데요.  
어떤 기준으로 함께할 사람을 고르면 좋을지 누군가 알려줬으면, 하는 생각이 있었어요. 
누군가에겐 참고가 되었으면 하는 맘에 저의 기준을 남겨놓습니다. 
(물론, 가장 먼저 제가 함께하고 싶은 사람이 되는 게 가장 중요하겠죠?)

Q1. 어떤 디자이너, 개발자와 함께 해야 할까요?

A. 저는 이런 기준으로 함께할 분들을 찾았어요. 1) 일정 약속 2) 꼼꼼함 3) 열정 을 가장 중요하게 생각합니다.  이렇게 하라 고 직접 말해줘야 사람 보다는, 공통의 목표가 정해져 있을 때 자신이 할 일이 무엇인지 아는 사람이랑 일하는 것이 가장 효율이 좋다는 저만의 기준이 있었습니다.

🖌️ 디자이너는 자신의 디자인에 이유가 있는 사람과 함께 일하고 싶었습니다. (실제로 저희 디자이너님은 정말 이 부분에 강한 것 같습니다!) 디자인이 그냥 취향의 산으로 빠져버리는 것은 위험하다고 생각했기에, 논리와 이유를 기반으로 이야기할 수 있는 분과 일하고 싶었어요.

🖥️ 개발자는 경험과 열정, 정리 능력을 기반으로 함께할 분을 찾았습니다. 워낙 제가 개발 부분에 강점을 갖지 못하다보니 열정과 경험을 보여주신 분들을 뽑으려고 했던 것 같습니다.

Q2. 사이드 프로젝트의 시작, 어떻게 팀원들에게 믿음직한 pm이 될 수 있을까요?

제가 가장 고민한 부분이었습니다.

회사가 아니기에 원할한 프로젝트를 위해선 신뢰를 쌓는 것이 가장 중요하다고 생각했어요. 회사에선 검증된 pm이 있다고 생각하지만, 사이드 프로젝트에서 못미더운 pm이 있으면 중간에 애정을 잃기 쉬우니까요.

A. 저는 팀원들에게 신뢰를 쌓기 위해 이 부분에 집중했습니다.

1) 존댓말을 썼어요.
상호존중의 시작은 아무래도 존댓말이더라구요. 반말은 친해질 수 있지만, 사적인 사이로 빠지기 쉬웠어요.

2) 정리를 습관화했어요.
우왕좌왕 정리가 안된 모습은 신뢰를 얻기 힘들어요. 회의 전, 회의 내용을 미리 공유하고, 회의 후에도 체계적으로 정리해서 공유해요.

3) 질문거리에 대한 답변은 미리 준비했어요.
질문이 나올법한 내용은 미리 고민하고 공부해 두어요. 언제든지 답변할 수 있도록이요.

4) 확실한 화법을 사용하려 했어요.
제게 어려운 부분이기도 했는데요. 최선을 다했던 부분이기도 합니다.
애매모호하고 자신 없는 답은 다른 분들께 혼선을 줄 수 있다고 생각했습니다. "확실이 이렇게 할 거예요." 라는 것이 개발자분들이 가장 선호한 화법이기도 했습니다.

그래서 답변하기 힘든 질문이 오면 잠시 시간을 달라고 말씀드렸어요. 전후 상황과 맥락 등을 모두 고려해서 ‘내가 확신이 드는‘ 최선의 답변을 찾아 확실하게 이야기하고는 했죠.

< 디자이너와 디벨롭하기 >

🫧 사용 툴: 노션, 피그마

step 1. 서비스 레퍼런스 찾아서 합 맞추기 

디자인 회의할 때 포인트는 항상 내가 좋아하는 예쁜 디자인이 아니라 “서비스가 전하고 싶은 메시지를 효과적으로 전달할 수 있는 디자인” 에 집중하려 했습니다

디자이너에게 이 서비스의 기획 의도부터 페르소나, 기대효과, 어떻게 유저들이 이 서비스를 사용했으면 좋겠는지까지 아주 아주 디테일하게 이야기했습니다.

아무래도 Vi.NO는 정보성 영상 콘텐츠들을 텍스트로 전달하니, 가독성이 매우 중요했어요.

그래서 동일한 타겟층의 서비스들의 컬러링부터 라인의 사용, 텍스트 굵기나 크기까지 어떤 것이 가독성이 가장 좋을지 타 레퍼런스도 정말 참고를 많이하고 디자이너와 이야기했습니다.

이 뒤, 서비스 기획단계의 디자이너의 업무는 이 아티클 에서 더 디테일하게 확인할 수 있습니다.

초반 서비스 방향과 목표에 대한 공감대와 이해도가 잘 형성되어야 이후 디벨롭 과정이 더 의미있어진답니다.

step 2. 와이어프레임 + 기능 명세서 완성

서비스의 디자인 방향성을 함께 잡았다면, 이제 화면을 진짜 그려야겠죠.
이 때 필요한 것은 와이어프레임과 기능명세서입니다. 내가 짠 기능하나 하나 이 버튼을 눌렀을 때 어떤 결과가 펼쳐지는지를 디테일하게 적는 것이 중요합니다.

이렇게 각 기능들에 번호 부여하여,
1) 숫자 순번으로는 '각 기능들에 대해 설명'을,
2) 영어 순번으로는 '어떤 액션을 했을 때' + '어떤 결과가 나오는지'를 모두 적어주었습니다.

기능명세서는 꼭 필요하다고 생각하는데요.

📍협업의 측면에서ㅣ 진전을 멈추게 하는 불필요한 핑퐁을 줄여줍니다, 하나하나 질문할 필요없이, 모든 설명들이 기능명세서에 응축되어 있으니까요
📍PM 스스로도ㅣ 기능명세서를 쓰면서 ‘이렇게까지 디테일하게 써야 할까’ 하는 생각이 많이 드는데요. 한 기능에서 파생되는 모든 결과치들을 생각하다보면 미처 생각하지 못했던 경우들에 대해 생각하게 될 뿐만 아니라 “이 기능이 꼭 필요할까? 추가로 어떤 기능이 필요하겠다”는 근본적인 고민들로 더 나은 서비스를 만들어나갈 수 있다고 생각해요.

➕ 더 나아가 디자이너와 UX의 측면에서도 더 나은 기능은 무엇일지, 어떻게 대체할 수 있는지 이야기했습니다. 
이 부분에 대한 디테일한 고민은 추후 콘텐츠에서 따로 소개할게요.

< 개발자와 합맞추기 + 커뮤니케이션 하기 >

저는 개발에 대한 지식이 별로 없습니다. 아는 문법이라곤 sql 정도..? 입니다. 22살 스타트업에서 인턴하던 시절, 아빠처럼 잘 챙겨주시던 개발자 팀장님께서 하시던 업무를 옆에서 보던 정도..? 요 정도 노베이스 상태의 pm이 어떻게 개발자와 커뮤니케이션 했는지 말씀드릴게요.

📍 사이드 프로젝트 시작 전 pm이 개발 관련 알아두면 좋은 것.

1) 프로젝트 전 프론트엔드/백엔드가 담당하는 일과 업무들.
저는 테크 블로그들도 전전하며 어떻게 개발하는지 최대한 많이 염탐했습니다. 대충 역할과 개발 흐름을 알겠더라구요. 이정도면 대략적으로 개발자분들과 대화가 가능해졌습니다.
어떤 업무를 프론트에서 담당하고 어떤 업무를 백엔드에서 담당하는지 파악하고 정확하게 담당자와 커뮤니케이션하기 시작하면 효율적인 일정 관리가 가능해지더라구요.
2) 오류 종류들
프로젝트가 끝나고 개발자분들께서 오류 종류들에 대해서는 미리 공부하는 것도 추천해주시더라구요. 현재 어떤 개발상의 문제점이 생겼는지를 파악하고 기획자로서 개발 일정을 애자일하게 확인하는 것이 중요하니까요!

*PM이 참고하기 좋은 IT 플랫폼: 1) 요즘IT 2) velog 3) 브런치

💬 TIP1. 개발짱을 선정하라.

저처럼 노베이스인 pm께 드리는 자그마한 팁은, 가장 밀접하게 개발 상황을 커뮤니케이션할 수 있는 개발짱을 선정하라는 것입니다. 저는 프론트짱 1명, 백엔트짱 1명을 선정했는데요.

각 개발 부분에 대한 총체적인 뷰로 바라볼 수 있을 뿐만 아니라, 어떤 부분이 병목인지에 대한 디테일한 설명을 들을 수 있었습니다. 더 디테일하게 현재 빨리 개선되어야 하고 진행되어야 하는 부분들을 정확하게 지시하여 컨트롤 할 수 있었습니다.

💬 TIP2. 솔직하게 모른다고 하고 공부하자.

디테일한 부분들은 솔직하게 모른다고 이야기하고, 개발자 분들로부터 설명을 들었습니다. 설명 들은 내용을 바탕으로 더 아티클을 탐색해서 왜 이 부분이 어려운 지점인지 이해하려 했죠. 더 빠르게 일을 진행시킬 수 있었고, 서로가 이해가 되지 않는 지점을 쉽게 파악할 수 있어 훨씬 용이했죠.