by
Jan 17. 2021
SOPT 27th 앱잼 멘토 참여 후기
13개팀 모두 고생하셨어요!
안녕하세요. 도그냥입니다.
오늘은 대학생 IT 벤쳐 창업 연합 동아리인 SOPT의 앱잼 데모데이 행사에 기획 멘토로 참여했습니다,
소감을 짧게 남겨봐요:)
1. gather town으로 이 정도까지!
코로나 시국에 400명이상의 인원이 한곳에 모이기가 쉽지 않죠. 운영진분들도 모일 수가 없다보니 게더타운을 선택해서 컨퍼런스 행사를 진행했어요.
다른 게더 타운 쓰셨던 분들의 말에 따르면 거의 장인정신이라고 하더라고요. 근데 저는 늙은이라 그런지 게더타운이 처음부터 익숙치는 않았는데요, 저는 멘토링 일정이 빡빡하여 운영진 캐릭터 손잡고 그대로 따라 다니느라 더 자유롭게 돌아다니고 그러진 못해서 아쉽네요.
운영관점에서 특이했던 점은 몇가지가 있어요.
맵 전체에 동시 송출되는 프레젠테이션룸의 지정
부스로 설정된 프라이빗룸은 4인 테이블 기준으로 4인씩만 대화가능하고 고스트모드로 청취 가능
데모데이 행사 게더맵 캡쳐완전히 온라인으로 대체할 순 없겠지만 어느 정도 오프라인과 온라인 중간의 대안이지 않나 생각했어요.
물론 멘토로 참여한 제 입장에서는 오프라인 행사에 비해 더 높은 집중력과 에너지가 들기는 했어요, 자료와 설명을 오로지 모니터에 맞춰서 집중해야했고 주위환기가 되지 않기때문에 이동하며 개별 부스의 팀에게 피드백 조언을 하는 텀이 없었기 때문이죠. 오프라인 행사의 북적임도 느껴지지 않기 때문에 온라인 특유의 어려움은 분명 있었어요. 그래도 전반적으로 오프라인 구성을 그대로 잘 가져왔다는 생각이 들었어요. 운영단이 대학생이라서 할 수있었던 모험의 성과인 것 같아요.
2. 13개의 팀, 코로나 시기의 마음들
이번 프로젝트는 10주 세미나 걸친 교육후에 5주간의 앱잼 기간을 통해서 앱을 만들었다고 하는데요. 협업과정이 온라인으로만 비대면으로 진행했다는 점이 특이한 점이라고 합니다. SOPT뿐 아니라 전국적으로 어쩔 수 없는 상황이었죠,
그래서 그런지 13개의 팀의 내용중에서 '나를 돌아보거나' '마음을 치유하고' '자신을 관리하고' 등 자신에게 집중된 서비스를 한 팀이 많았아요.
결이 조금 다르지만 성장을 위해 '정보를 모으거나' '동기부여를 하는'쪽도 있어서 많은 사람들이 코로나 시기의 자신을 부여잡고 스스로 성장하는 것에 마음이 집중되어 있는구나 생각할 수 있었습니다.
어떻게보면 마음이 참 아픈게요, 일상속에서 소재를 찾기가 쉬운데 그만큼 다양한 경험이 되지 않고 자신에게 집중하는 기간이 길었다는 생각이 들었어요!
다들 힘내시면 좋겠고, 올해는 더 다양한 경험을 통해 소재 다양성이 나타나면 좋겠다고 생각했어요:)
자세한 팀별 내용은 공식페이지를 참고하세요
https://sopt-demoday.oopy.io/
3. 창업과 사이드프로젝트 사이
작년은 사이드 프로젝트가 유행했었죠. 사이드 프로젝트는 Toy프로젝트라고도 부르는데 직업이라기보다는 경험과 재미, 성장을 목적으로 서비스를 부담없이 만들어본다는 취지가 강하다고 생각해요. 그런 영향인지 모르겠지만 IT 창업동아리의 앱발표이고 모두 하나같이 기간이 끝나고도 서비스를 이어 나가며 진짜 런칭을 하길 바랬지만, 그 느낌이 사이드프로젝트인지 창업인지 혼동되는 느낌이었습니다.
저는 기획 멘토였기때문에 이 부분을 가장 중요시했는데요. 향후 지속하기 위해서는 서비스의 목표와 가설이 분명해야해요. 스케일업을 하는 것도 특정 비즈니스 가설에 대한 목표가 있어야 방향을 잡을 수 있으니까요. 일단 만들어보고 니즈를 파악하는 것도 맞지만, 비전이 없다면 이 앱잼 기간이 끝나고도 멤버들에게 지속적인 헌신을 바라기는 어려우니까요. 특히 PM들이 거의 CEO의 역할이라면 더더욱 명확한 비전을 보여줘야한다고 생각해요. 기능적인 개선은 그런 기준을 가지고 이뤄져야 협업인들이 힘들어지지 않으니까요. 게다가 하나둘 취업하게 되면 더더욱 헌신에 대한 보상은 필요하다고 느낄거에요. 그게 사회인이고 어른이니까요.
그래서 더더욱 리텐션과 성장지향점, 비즈니스모델에 대한 로드맵을 물어보고 거기에 대한 멘토링을 하려고 노력했습니다. 창업이기에 투자와 영속성을 위해서 꼭꼭 고민해야하는 부분이었다고 생각합니다:)
4. 프로젝트 일정과 잦은 변경에 대해서
부스 방문 때에는 미리 멘토들에게 궁금한 점을 묻는 질문들을 받아두었다가 각 팀에 가서 대답해주는 시간들이 있었는데요. 각 프로덕트에 대한 고민도 있었지만 프로젝트 진행 과정에서 겪는 고민들도 있었습니다.
자꾸 나중에 기획 내용이 추가수정 된다고 개발로부터 말을 들었는데 변경사항을 어떻게 체크해야할까
기획자가 디자인에는 어디까지 관여해야할까
기획자로서 협업할 때 팀원들과 관계형성은 어떻게 해야할까
대부분 협업에 대한 질문들이었어요. 아마도 협업과정에서 기획과 PM을 담당하신 분들이 직무적으로 겪는 가장 큰 어려움이기도 하죠. 저 역시 항상 고민하는 부분이고요. 몇가지 일관성 있는 답변을 드렸습니다:)
최초 기획시 프로세스와 정책설계를 먼저하지 않고 디자인으로 기획하면 feasibility의 체크가 제대로 이루어지지 않아서 나중에 서버개발단계에서 케이스 수정이 굉장히 많이 필요해질 수 있다.
앞에서 개발과 합의된 부분이 있으면 일단은 최대한 약속된 양을 지키고 더 추가하고 싶은 아이디어가 있어도 차후 스프린트나 백로그로 두어야한다. 그리고 협업자들이 바뀌거나 더 만들어야하는 것을 미리 알고 혼란스럽지 않고 현재에 잘 집중할 수 있도록 PM이 시기에 잘 관리하는 것이 중요하다.
기획자 본인이 디자인이나 개발을 할 수 있어도 본인이 직접할 것이 아니기때문에 마이크로매니징하지 말고 애초에 기획에서부터 자율성을 가질 수 있는 여지를 남기고 협업자에게 넘겨야한다. 그렇지 않으면 협업자들과 신뢰관계가 깨질 수 있어서 장기적으로 협업하는 관계에서는 서로 믿어준다는 것을 느끼게 해줘야한다.
