2. 팀원이라는 드래곤볼 모으기
사이드 프로젝트 팀 빌딩 하기 1편
이런 분들께 추천해요!
1. 기획/PM 경험이 없지만 팀 사이드 프로젝트를 시작하고 싶은 분
2. 어디서 사이드 프로젝트 팀원을 구해야 할지 모르겠는 분
3. 모시고 싶은 인재에게 어떻게 컨택할지 모르겠는 분
목차
1. 처음이라면 경험자를 데려오자
2. IT 인재 풀의 노다지, IT 동아리
3. 팀원은 필요한 시점에 단계적으로 모으기!
4. 원하는 인재, 콜드 콜로 영입해보자
노코드 툴이 워낙 잘 나오는 요즘이라지만 전문 개발자, 디자이너 손을 거치는 것에는 당연히 못 미친다. 멋진 결과물은 각자의 역량과 다양한 의견이 조합되었을 때 나오기 마련이다. 그렇기에 나는 개인 혼자서 하는 프로젝트보다 팀 프로젝트를 선호하고, 결과물 또한 훨씬 좋을 것이라 믿는다.
운이 좋게도 멋진 팀원들을 만나 함께 서비스를 만들고 있다. 어떻게 드래곤볼 하나하나를 모았는지 팀 빌딩 과정을 공유해보고자 한다.
팀 빌딩은 마치 드래곤볼을 모으는 것과 같다.1. 처음이라면 경험자를 데려오자
사이드 프로젝트를 해보자!라고 마음먹었지만, 막상 시작하려니 어디서 어떻게 해야 할지 막막했다. 사실 나에게는 기획, PM, 앱 프로덕트 경험이 거의 전무했기 때문에 더욱 그랬다. 린 스타트업 읽었을 때 만해도 이렇게 저렇게 하면 되겠다 싶었는데..
역시 인생은 실전이다.이럴 땐 앱 프로덕트 출시까지 한 사이클을 경험해본 사람을 팀원으로 영입하는 것이 정말 큰 도움이 된다. 이런 팀원이 있으면 어떠한 프로세스를 거쳐야 하는지 조언을 받을 수도 있고 또 어떤 장애물이 발생할 수 있는지 사전에 파악해 미리 대비할 수도 있다.
나는 운이 좋게 사이드 프로젝트 PM으로 앱 출시, 운영 경험이 있는 친구를 첫 팀원으로 구할 수 있었다. 실제로 첫 팀원은 TI 포지션(PM과 함께 서비스를 기획하면서 팀을 성공적으로 이끌어가는 역할)을 맡으며 내가 헤맬 때마다 프로젝트가 순조롭게 이어질 수 있도록 이끌어주었다. 그러니 혼자 이끌어가기 막막하다면 사이드 프로젝트던 회사에서건 앱 프로덕트 경험이 있는 팀원을 맨 먼저 영입해보자! 꼭 출시 단계까지 가보지 못했더라도 가고자 하는 곳까지 먼저 가봤기에 큰 의지가 될 것이다.
첫 번째 팀원 영입 성공!2. IT 인재 풀의 노다지, IT 동아리
사이드 프로젝트를 진행하면서 가장 많이 받았던 질문은 어디에서 팀원들을 구했냐는 질문이다. 각자 다 다른 방법으로 모집하였지만, 공통점은 모두 IT 창업동아리 SOPT를 통해 연이 닿았다는 것이다. 나는 대학생 때 SOPT 기획파트를 수료했었고, IT 기획자/개발자/디자이너를 희망하는 친구들과 연이 닿을 수 있었다. 첫 팀원인 친구도 SOPT를 통해 알게 되었다. IT 관련 학과 혹은 직종에 종사하고 있지 않다면, IT 업계 사람들과의 네트워킹이 쉽지 않을 수 있다. 이런 어려움으로 인해 팀 사이드 프로젝트 추친에 차질을 겪는 분이 있다면 SOPT, Yapp, Nexters와 같은 IT 동아리에 들어가는 것을 매우 추천한다. IT 업계 풀을 넓힐 수 있는 것은 물론, 자체적으로 진행하는 팀 사이드 프로젝트에 참여할 수 있다. 사이드 프로젝트를 위해 동아리에 들어가는 것이 부담스럽다면, 온라인 사이드 프로젝트 커뮤니티를 활용하는 것도 방법이다.
3. 팀원은 필요한 시점에 단계적으로 모으기!
팀원이 들어온 후, 첫 번째로 논의한 것은 어느 시점에 디자이너, 개발자를 모을지라는 부분이었다. 시기적 측면에서 팀원을 모으는 방법에는 두 가지가 있다.
첫 번째, 한꺼번에 모으는 방법이다. 개발자, 디자이너, 기획자, 마케터 등 일단 모으고 시작하는 거다. 이 방법의 장점은 모두가 기획에 참여할 수 있기에 모두가 기획에 공감할 수 있다. 또 프로덕트가 탄생해 서비스 다운 모습을 갖춰가는 과정을 함께하기에 프로젝트 오너십이 생긴다. 하지만 치명적인 단점이 존재하는데, 바로 이 팀원으로 인해 기획에 제약이 생긴다는 것이다. 정말 좋은 아이디어가 나왔는데 서버가 필요 없다면..? 애매해진다. 그래서 모두가 각자의 역할을 수행할 수 있는 기획이라는 조건이 하나 더 붙게 된다.
한꺼번에 팀원을 모으게 된다면 서로가 머쓱한 상황이 생길 수 있다.두 번째, 각 포지션의 역할이 필요한 시점 별로 모집하는 방법이다. 최소 단위의 인원으로 서비스를 디벨롭해가다, 필요한 시점에 필요한 인원을 단계적으로 모으는 것이다. 흔히 서비스에서 최소 단위 인원이라 하면 PM(기획), 디자이너, 프런트 개발자로 꼽는다고 한다. 그러나 이상적인 것 같은 이 방법도 단점이 존재하는데 바로 필요한 시점에 필요한 인원을 모으지 못할 때이다. 인원 수급이 원활하지 않으면 곧바로 프로젝트 딜레이로 이어진다. 이 상황이 길어지면 가장 무서운 상황인 프로젝트 흐지부지.. 이내 파멸로 이어질 수 있다. 그러니 단계별로 팀원을 모집할 것이라면 미리미리 팀 셋업을 준비해두자.
필요한 시점에 단계적으로 모집해야 하는 이유
나는 후자를 선택했다. 그 이유는 기획에 최대한 제약을 두고 싶지 않았기 때문이다. 사실 사이드 프로젝트라는 것만으로도 기획에 여러 제약이 존재한다.
아무래도 한정된 시간만을 투입할 수 있는 사이드 프로젝트 특성상, 일단 개발 볼륨이 작은 기획이어야 한다. 나아가 서비스 출시 이후를 고려해보자면 운영관리 비용이 큰 기획도 무리가 있다. 서버비가 무지하게 드는 기획도 부담스럽기 마찬가지다.
이러한 조건 고려하다 보면, 기획 가능한 범주가 생각보다 작음을 알게 된다. 여기에 또 다른 제약까지 추가된다면 프로젝트 초기 단계부터 지칠 수 있음은 물론, 좋은 서비스가 나오기도 어려워질 것이다.
그리고 팀원들의 프로젝트 오너십은 오롯이 PM 혹은 기획자의 역량에 달린 문제라고 생각했다. 포착한 문제를 효과적으로 해결할 수 있는 기획이라면, 팀원들도 충분히 납득할 것이다. 그래서 기획자와 본인 둘이서 아이데이션을 시작하기로 했다. 그리고 몇 번의 회의를 통해 기획 초안을 완성하였다. 기획 아이데이션 과정은 이후 글에서 자세히 다루려 한다.
4. 원하는 인재, 콜드 콜로 영입해보자
기획 초안이 완성되고 상세 화면을 그릴 단계가 되었다. UI 디자인을 위해 디자이너가 필요한 시점!
팀원을 모집하는 방법은 두 가지가 있다. 첫 번째, 공개모집을 하는 방법이다. 서비스에 대한 설명과 필요한 스킬 셋을 적어 오픈된 플랫폼에 올리면 관심 있는 사람이 컨택하는 방법이다. 두 번째 방법은 반대로 팀원으로 데려오고 싶은 사람에게 컨택해 영입하는 방법이다.
당시 기획 상 캐릭터 디자인이 필요했고, 캐릭터의 디자인이 서비스의 콘셉트를 좌우하는 매우 중요한 요소였다. 그래서 캐릭터 디자인을 잘하는 분을 모시고 싶었다. 당시 우리가 눈여겨보던 디자이너분이 계셨는데 비록 일면식은 없지만 SNS에 공유된 그분의 디자인 포트폴리오만 보더라도 꼭 데려오고 싶은 분이었다. 심지어 사이드 프로젝트를 진행했던 경험도 있으신 걸 보면 관심 있어하실 것 같았다. 그래서 전략을 짜 콜드 콜로 영입해보기로 했다.
5. 원하는 인재를 데려오기 위한 전략, NDR
영업 전략 프레임워크 중 NDR이라는 것이 있다. Needs, Decision Making Structure, Reliability의 약자로 각 정의를 살펴보면 아래와 같이 간단하다.
[출처] 퍼블리 - "영업 열심히 말고 제대로 접근하는 6가지 방법"즉 니즈를 파악하고, 의사결정권자 정보와 결정 구조를 파악하며 신뢰감을 심어주는 것을 말한다. 나는 NDR 프레임워크를 활용해 디자이너 영입 전략을 세워보았다.
Needs
디자이너 입장에서 어떤 사이드 프로젝트 팀에 합류하고 싶을까? 출시까지 지속할 의지가 있는, 프로젝트에 진심인 팀을 원할 것이다. 그만큼 사이드 프로젝트는 흐지부지 되기 쉽기 때문이다. 이를 보여주기 위한 수단으로 기획서를 짧게 작성해 공유드리기로 했다. 또 SNS를 보고 어떤 팀 분위기를 선호하실지 유추해 발랄한 톤 앤 메너를 사용했다.
Desicion Making Structure의 경우, 개인 혼자 결정하므로 고려대상이 아니니 넘어가겠다.
Reliability
제안받는 상대는 우리에 대한 정보가 없기에 상대측에게 우리에 대한 신뢰감을 주어야 한다. 그래서 제안서 앞에 우리에 파악할 수 있도록 간단한 소개와 각자 팀에서 맡은 역할을 덧붙였다.
디자이너분께 보내드린 기획서의 일부우리에 대한 간단한 소개, 사이드 프로젝트에서 맡은 역할과 기획안을 노션으로 정리해 인스타그램 DM으로 보냈다. SNS 메신저로 연락하는 방법은 컨택하기도 쉽고, 제안받는 입장에서도 덜 부담스럽다. 하지만 카톡이나 문자만큼의 답장 속도를 기대하긴 어렵기도 하다. 몇 시간 후 기쁘게도 합류할 의사가 있다는 답장이 왔다. 그렇게 디자이너 두 번째 팀원을 모았다.
두 번째 팀원 영입 성공!연차 쌓인 개발자가 선호하는 사이드 프로젝트는?
어느 정도 디자인의 윤곽이 나오자 기능적으로 구현 가능한지 확인해야 할 단계가 왔다. 프런트 개발자를 모실 시기가 된 것이다. 이때도 미리 염두에 둔 개발자 분이 계셨다. 다만 연차가 있는 분이라 승낙하실지 불투명했다.
하지만 NDR의 Needs에 비춰봤을 때 승산이 있을 거라 생각했는데, 그 이유는 애플 워치 OS를 기반으로 한 기획이었기 때문이다.(현재 기획은 애플 워치 OS를 기반으로 하고 있지 않고 있으며, 전혀 다른 기획이다.) 개발자의 연차에 따라 사이드 프로젝트에 대한 니즈에 차이가 있을 거라 예상했는데, 연차가 있을 경우 본인 포지션의 리드를 맡는다던지 새로운 언어/OS로 개발하는 것을 원할 거라 유추했다. 사이드 프로젝트 사이즈의 개발 경험은 이미 회사에서 충분히 쌓았을 테니 회사보다 더 큰 역할/권한을 드린다던지 혹은 새로운 기술을 개발할 수 있는 환경을 제공하는 등 다른 무언가를 제공할 수 있어야 한다. 나중에 프런트 개발자님께 팀에 들어오신 이유를 확인해본 결과 여러 이유가 있었지만 새로운 기술을 기반으로 한 기획이라는 점이 가장 컸다고 말씀주셨다. 경력이 있는 팀원을 영입하고 싶다면 이 전략을 이용해 보는 것도 좋겠다. 프런트 개발자분의 경우, 운 좋게 디자이너님과 연이 있으셨고, 디자이너님의 제안을 통해 합류하시게 되었다. 그리고 프런트 개발자 분이 서버 개발자분을 데려오시면서 이후 초기 팀 세팅은 매우 수월하게 진행되었다.
이렇게 기획/디자인/프런트 개발/서버 개발까지 모여 초기 팀이 셋업 되었다!
하지만 순탄하면 재미없지..이후 몇 가지의 난관이 있었고, 그 끝에 멋진 새로운 팀원분들이 조인하셨다.
그 이야기는 이후 풀어보도록 하겠다.
