2023. 9. 13. 17:44ㆍ기록/회고
23년 8월~9월 초까지 진행된 카카오 모빌리티 해커톤에 참여했던 프로젝트의 과정 및 결과, 그에 대한 회고를 하고자 한다.
1. 팀원을 구하다
카카오 모빌리티에는 감사하게도 팀원 구인 공간이 따로 있다.
구인 글을 보고 먼저 요청을 넣었고, 그렇게 2명의 대학생 개발자, 1명의 전공 대학생 기획자, 그리고 실무 경험이 있는 취준생 1명(나)이 모이게 되었다.
2. 첫 회의가 열리다
가장 먼저 이뤄진 것은 팀의 리더 선정이었다.
해커톤을 위해 모인 멤버이지만, 팀과 프로덕트의 방향성을 주도할 수 있는 리더는 필요하다고 다들 느꼈다. 대체적으로 기획자가 리더인 경우가 많다는 흐름과 전공자이며 비슷한 프로덕트를 경험 이력이 있는 기획자 분께서 리더를 하게 되었다.
-> 나는 '기획자가 리더인 경우가 많으니 기획자가 리더가 되어야 한다' 말을 이해하기 어렵다. 꼭 기획자라고 리더가 되어야 한다는 법도 없고, 무엇보다 기획을 맡은 사람에게 큰 부담을 주는 말이다. 이번 프로젝트를 포함해 몇몇 프로젝트에서 위와 같은 말을 듣는 기획자 분들을 보면 다들 당혹스러워 했다. 직무와 관계없이 누구나 리더가 될 수 있고, 리더 선정 기준이 오로지 직무인 것은 좋은 리더를 뽑을 수 있는 방법이 아니라는 것을 명심하자.
3. 프로덕트 아이디에이션
팀 노션 페이지가 생성되고, 해커톤 공고 내용과 아이디어 회의 전까지 노션에 각자 떠 오른 아이디어를 모아두기로 했다.
'노션에 아이디어를 모아놓자'는 내가 제안했다.
아이디어를 '떠올려야 하는 상황'에서 퍼뜩 떠오르는 경우는 사실상 많지 않다. 일정 시간 정도가 지나도 나오는 아이디어가 없어 각자 여유를 가지고 아이디어를 준비해 오는 게 낫다고 생각되었다. 다음 회의 때 우리는 노션을 열었고, 1명당 평균 2개 이상의 아이디어가 적혀 있었다.
-> 아이디어는 어느 순간, 갑자기 떠오르는 경우가 많다. 그렇기 때문에 심리적 여유와 시간이 필요하다.
4. 프로덕트 기획 시작
아이디어가 모이자 기획자 분은 빠르게 기획 스케치를 잡아갔다. 하지만 이 단계에서 프로덕트 기획의 이해도 차이가 있었다.
기획자님은 기획 과정에서 API 및 개발 가능 여부를 가장 많이 염두했지만, 나는 '이 프로덕트는 사용자의 어떤 부분을 해소해 줄 수 있는가', '우리는 이 프로덕트를 왜 만들고자 하는가', '정말로 세상에 필요한 프로덕트인가' 에 대한 의문이 가장 먼저 들었다. (이 항목들은 해커톤 심사 기준에도 들어가 있다.)
우리가 만들고자 하는 프로덕트의 이유가 없었기에, 나는 프로덕트 자체에 대한 이해와 공감이 잘 되지 않았다.
하지만 1차 기획안이 나오기 전까지는 내가 이해하고 있는 과정에 대해 말하지 않았다. 그 이유는, 내가 정답이 아닐 수 있기 때문이었다.
1차 기획안이 나왔지만, 우리의 프로덕트를 뒷받침 해 주는 그 어떤 데이터나 근거를 볼 수 없었다. 게다가 와이어 프레임은 많은 것이 빠져 있었다. 나는 기획자님께 회의를 요청해서 조심스럽게 내가 이해하고 있는 기획 단계에 대한 설명과 우리의 프로덕트 설득력을 강화시킬 수 있는 것들, 그리고 느꼈던 의문점들을 말했다.
5. 기획안 보완! 그러나..
감사하게도 기획자님은 불쾌감 없이 나의 의견을 참고하여 기획안을 수정하셨다다. 그렇게 2차 기획안이 나왔다.
많은 것이 보완되었지만, 애석하게도 나는 여전히 의문이 가득했다. 여전히 '왜 이 프로덕트가 이 문제를 우리가 주장하는 해결법으로 해소될 수 있는 걸까?' 라는 의문이 있었다. 객관적으로 우리가 제안한 프로덕트는 흔한 프로덕트였다.
6. 상황적 선택
해커톤 특성상 시간이 제한적이다. 고민에 빠진 나는 전반적인 기획은 따르되 UI/UX 측면에서 더 좋은 방향의 시안을 제안하며 보안해 보는 방식으로 진행하기로 했다. 그 결과 기존 기획안에서 전반적으로 용자 중심적으로 더 정리해졌다. 이 과정에서 대체적으로 나의 의견은 수용되었지만, 이유를 받았을 땐 As is 와 To be의 각 이유와 결과를 설명하며 설득했다.
6-1. 디자인 작업 과정
디자인은 2~3일을 잡고 빠르게 끝냈다. 먼저 스케치로 레이아웃과 컬러를 배분하고 이후 본격적으로 UX디테일 수정 및 메인 컬러, 아이콘 등 UI를 잡아나갔다. 어느 정도 UI가 나온 뒤엔 전반적인 디테일을 챙기며 시안 디벨롭을 했다. 와이어 프레임이 있었지만 큰 틀 외에는 모두 수정하였기 때문에 앞에서 잡았던 스케치 작업은 전체 작업 시간을 줄이는데 큰 도움이 되었다.
7. 제출안 작성
디자인의 경우, MVP 단계의 이미지만 요구되었기 때문에, 기획 내용 검토에 참여했다.
제출안에는 프로덕트의 경쟁력이 되는 요소가 있어야 했는데, 경쟁 요소로 볼 수 없는 부분이 포함되어 있어 그 부분을 덜어내는 것을 제안했다. 감사하게도 기획자 분께서는 이 부분도 참고하여 제출안을 정리해 주셨다.
8. 제출! 그리고 결과는..
우여곡절 끝에 서류를 제출했고, 모든 과정이 끝났다.
그렇게 결과를 기다렸고 결과는 어느날 각자의 메일로 통보되었다. 결과는 '아쉽지만..' 으로 시작되었다. 다들 열심히 했기에 아쉬움을 감추지 못했던 것 같다. 하지만 과정 속에서 여러 의문을 가졌던 나는 결과의 이유를 알 수 있을 것 같았다.
9. 프로젝트에서 느낀 것
결과적으로는, 실패한 프로덕트지만 깨달은 것이 많다.
상대의 직무 룰을 존중하는 것은 '프로덕트의 성공' 과는 무관하다는 것을 깨달았다.
직무 롤을 존중했기 때문에 커뮤니케이션은 원활했지만, 우리의 핵심 목표였던 '프로젝트의 성공' 은 이뤄내지 못했다.
기획자 분은 전공자이면서 수상 이력도 있고, 비슷한 프로덕트에 참여한 경험이 있으셨다. 하지만 비즈니스 관점에서는 많이 부족했고,나는 그것을 캐치했었다. 그럼에도 불구하고 적극적으로 나서지 않은 것은, 직무의 '선'을 넘는 것은 상대를 존중하지 않는다는 노파심 때문이었다.
하지만 이는, 프로덕트 성공에는 전혀 관련이 없었다. 오히려 우리가 적극적으로 행동했다면, 서로 배우는 것이 훨씬 더 많았을 수도 있었을 것이다.
이 경험 토대로, 나는 '프로젝트의 성공'을 가장 중요하게 생각하고 있다.
9.-1 프로젝트의 실패 원인
우리의 실패 원인
- 개발 중심적으로만 설계된 프로덕트 기획
- 경쟁력, 비즈니스 모델, 그리고 필요성이 약한 프로덕트
- 사용자 니즈를 명확하게 해결해줄 수 없는 해결법
아무리 개발을 잘해도 프로덕트 기획이 엉망이면 그 프로덕트는 가치 이유가 없을 수 밖에 없다.
우리에겐 분명하게 알 수 있는 사용자 니즈 데이터가 있었지만, 그 데이터를 기반으로 명확한 해결법을 제안하지 못했다.
프로덕트에서 항상 중요하게 생각해야할 것은 다음과 같을 것이다.
- 현재 사회적으로 불편함이 있는지
- 사람은 어떤 불편함을 느끼고 있는지
- 어떤 아이템이 사람의 불편함을 해소시킬 수 있는지
- 불편함을 해소시키기 위해서 어떻게 할 수 있는지
가장 근본적인 내용이지만, 가장 지키기도 힘들 것이다.
그럼에도 불구하고, 모든 프로덕트들은 이를 통해 존재할 것이다.