brunch

You can make anything
by writing

C.S.Lewis

by 지설 Jul 03. 2022

주니어 서비스 기획자의 사이드 프로젝트 여정 기록(5)

서비스 출시 그리고 회고

1편: https://brunch.co.kr/@jiseol/1

2편: https://brunch.co.kr/@jiseol/2

3편: https://brunch.co.kr/@jiseol/3

4편: https://brunch.co.kr/@jiseol/4


구현 단계를 거치면서 누군가가 이용한다고 생각하니 최대한 완벽하고 싶은 욕심이 생기게 되었다. 우리가 스스로 90% 이상 완성이 되었다고 생각이 들 때까지 수정과 보완을 반복하였고, 그 밖에 위기 상황들까지 더해져 생각보다 많은 시간이 소요되었지만.. 결국에는 우리의 서비스를 세상 밖으로 내보낼 수 있게 되었다!


드디어...! (입틀막)





59mins 출시

http://59mins.net/



'직장인들이 효율적으로 회의를 할 수 있도록 돕는 웹 서비스를 만들어보자!'라는 목표를 가지고 완성된 우리의 서비스의 이름은 바로 "59mins"이다.

회사 미팅 시간에 겪는 직장인들의 불편함을 해소해주기 위해 '모든 미팅은 1시간 미만으로 짧고 굵게 끝내야 한다'라는 것이 우리 서비스의 핵심 콘셉트이다.




서비스명과 아이덴티티

59mins라는 서비스명은 사실 MVP 스펙을 결정하면서 지어졌다.

지체되는 회의가 아닌 빠르고 효율적으로 진행되는 회의 시간을 우리는 59분(1시간) 이내로 잡았고,

'오구민s'라는 한글 그대로 읽었을 때의 말장난을 더해, 이 서비스를 사용하는 우리의 유저들을 '오구민 씨'라고 지칭하면서 서비스의 아이덴티티를 정립해나갔다.

59mins 소개 페이지 보러 가기

 



서비스 출시 과정 다시 되짚어보기

나는 다시 한번 서비스를 만들어온 과정을 점검해보고, 동시에 59mins를 좀 더 소개해볼까 한다.

당시에 던졌던 물음과 고민에 대한 대답이나 해결책을 제시했는지를 자문자답하는 형식으로 요약해보았다.



STEP 1. 아이디어 제안 / 아이템 결정

"회사에서 하는 회의가 효율적으로 이루어지게끔 도울 수 있는 서비스가 있으면 좋지 않을까?"

우리 스스로도 겪고 있고 아마도 많은 직장인들이 느낄만한 문제를 아이템으로 제안하였다.


STEP2. 가설 수립 및 검증

"그렇다면 대부분의 직장인들이 회사에서의 회의 시간이 비효율적이라고 느껴야 이 서비스가 필요할 텐데.. 과연 그럴까?"

'대부분의 직장인들은 비효율적인 회의를 겪고 있을 것이다'라는 가설을 세운 뒤, 가설 검증을 위해 사용자 인터뷰를 진행하였다. 사용자들이 평소에 회사에서 겪는 회의의 행태를 알아보고 그 속에서 니즈와 페인 포인트를 발굴해내었다.


STEP 3. 문제 인식 및 서비스 가치 도출을 위한 아이데이션

"우리가 생각한 가설이 어느 정도 부합하는 것 같아. 그렇다면 사용자들이 느끼는 문제를 어떤 식으로 해결해주면 좋을까?"

사용자 데이터를 나열하고 아이데이션을 진행하였다. 그 과정에서 우리 서비스의 key message, 사용자들에게 전달할 서비스 가치를 찾고자 하였다.


STEP 4. 해결 방안 제시 (+ 59mins 핵심 기능 소개)

"이 문제는 이런저런 기능을 통해 해결해줄 수 있을 것 같아."

 User story에 따라 기능과 아이디어를 제안하여 페인 포인트들에 대한 실질적인 해결 방법을 제안하였다.



59mins에서 제공하는 기능 예시


(문제 1) 기약 없이 길어지는 회의 시간

(기능 1) 아젠다 별 제한 시간 설정 + 총 회의 시간은 59분이 넘지 않도록 제한

(기능 2) 회의 진행 시 타이머 제공



(문제) 결론이 없는 회의

(기능 1) 회의 중간 안내 팝업을 제공하여 결론 시간을 상기시켜줌

(기능 2) 회의록 작성 템플릿(논의 내용, 결론 내용, Action item) 제공



(제안) 비효율적인 회의의 반복을 막기 위해 지난 회의를 돌이켜보고 회고해볼 수 있는 요소를 제공해보자

(기능 1) 회의 자가진단 checklist

(기능 2) 회의 완료 후 목표시간 대비 소요시간 표시



STEP 5. MVP 협의

"우리에게 주어진 시간과 능력 그리고 이 아이디어가 구현되어야 할 근거들을 재고해보고 우리 서비스의 MVP 스펙을 정해보자."

시간, 구성원들의 capability 등 현실적인 요소들을 고려하며 우리 서비스의 MVP 스펙을 협의하였다.


STEP6. 와이어프레임 및 기능 정책 설계

"협의된 기능과 우리의 의도를 어떻게 웹사이트로 녹여낼 수 있을까?"

서비스의 가치와 그 가치를 전달할 수 있는 기능들을 적절한 UI로 제공하기 위해 와이어프레임을 설계하고, 정책을 정의하였다.


STEP7. 디자인 및 개발

"실제 사용자들이 이용하게 될 우리의 서비스를 구현해내자!"

만들어진 뼈대와 정책들을 가지고 GUI 디자인을 입히고 개발을 하였다.


STEP8. QA

"서비스를 출시하기 전 오류나 이상이 없는지 다시 한번 점검해볼까?"

기능과 디자인 테스트 시나리오를 미리 작성하고 테스트하면서 QA를 진행하였다.






위기, 그리고 회고

STEP대로 정리해보니 마치 순서에 맞추어 순탄하게(?) 진행되어 온 것처럼 보이는 효과가 있는 것 같다. 하지만 사이트를 구축하고 출시하기까지의 정말 눈물 나는 우여곡절이 있었다..


 개발 단계에서의 많은 이슈들

여러 이슈들이 있었지만 우리 서비스의 핵심 기능 중 하나인 타이머를 구축하는 데에 특히 애를 많이 먹었다. 실수로 페이지에서 이탈되었을 때 이 타이머는 가장 최신 시간대까지 서버에 반영이 되기로 정책을 세웠으나, 구축하는 과정에서 여러 이슈가 발생하였다. '시간'과 관련된 기능을 다룬다는 건 생각보다 까다롭고 힘든 작업이었다.


사이드 프로젝트 위기

비사이드에서 약속된 서비스 출시일에 이르렀고, 어찌어찌 전체 페이지는 구현을 해나갔지만 우리 모두가 생각했을 때 배포를 하기까지는 부족한 부분들이 많았다. 솔직히 말하자면 배포할 수 있는 수준이 아니었다.. 이 단계에서 다들 많이 지치고 팀원 중 포기하는 상황이 발생하였고, 다들 의욕이 많이 꺾여있는 상태였다. 나는 너무나 하고 싶은 의지가 강했지만 나 혼자서는 할 수 없는 일들이 너무 많았고 결국 팀원들이 필요했다.


하지만 다행히도 이 프로젝트를 계속 이어 나갈지에 대해 우리 스스로 설문조사를 진행해보았고, 다들 하고자 하는 의지가 있다는 점은 확인할 수 있었다. 약 3-4달 동안 노력했던 것들이 너무 아쉬운 건 다들 마찬가지였기 때문이었다. '그래, 출시는 해보자'라는 목표를 다시 다잡고 약간의 방학 시간을 가지기로 했다.


나는 방학 기간 동안 우리와 함께할 새로운 팀원을 찾아보았다. 사실 어느 정도 개발이 착수된 상태에서 과연 합류해주겠다는 개발자가 있을까? 싶었다.. 나 스스로도 거의 불가능하지 않을까 지레짐작하고 반쯤 포기한 상태였다. 하지만 감사하게도 함께할 팀원이 구해졌고 그렇게 다시 서비스 출시를 위한 여정을 재개할 수 있었다.



아쉬운 점

인원이 충원된 이후에 계속해서 기획, 디자인 QA를 진행하면서 사이트를 완성해나갔다. 하다 보니 추가로 정의하고 수정할 것들이 눈에 보였고, 욕심이 생기는 부분들도 생겨서 출시가 생각보다 미뤄지게 된 점도 있었다. 돌이켜보면 출시 전에도 프로토타입이던 중간중간 사용성 테스트를 진행하면서 보완하는 과정이 있었으면 좋았을 텐데 이러한 프로세스 면에서 참 아쉬운 부분이 있다. '좀 더 애자일 하게 프로젝트를 진행하면 어땠을까?' 싶지만.. 다시 한번 말하자면 당시에는 당장 출시 조차도 보장할 수 없었기 때문에 그 부분은 어쩔 수 없었다고 생각하려고 한다. 그 외에도 '내가 좀 더 PM으로써 능력이 있었더라면 이 과정을 조금이라도 효율적으로 할 수 있었을지 않을까?' 하는 아쉬움도 크다. 




사이드 프로젝트를 완수할 수 있었던 이유

서로를 설득시킬 수 있는 목표

사이드 프로젝트 초기에 언급했던 내용이지만, 계속해서 공동의 목표를 상기시켜 의욕을 끌어내고자 했던 것 같다. 이 프로젝트가 단순히 나 혼자만의 욕심이 아니라 우리 모두를 위한 것이고, 더불어 이 사이드 프로젝트를 하면서 얻고 싶었던 개개인의 목표 또한 이룰 수 있도록 배려하고 모든 팀원 한 명 한 명을 위한 일이라는 점을 인지하는 것이 중요했던 것 같다.


목표에 대한 집요함

뭔가 추상적인 개념이 아니라 딱 떨어지는 해결책이나 근거를 제시하고 싶지만, 사실 가장 중요한 건 결국 의지였다. 현업으로 인한 시간 부족이나 구현 난이도에 의해 꺾이는 의욕 등등 충분히 이 힘든 과정을 포기할만한 외부적인 요소들이 너무나 많았다. 하지만 계속 어떻게든 이끌어내고자 하는 인원이 있고, 이 집요함은 결국 프로젝트 자체를 움직이게 하는 원동력이 되었다고 본다.


커뮤니케이션

모두가 함께 지쳐하는 모습은 눈에 보일 정도였지만, 그럼에도 불구하고 일주일에 한 번 있는 정기 미팅은 항상 모두가 참석해왔었다. 이슈나 궁금증이 있다면 확인을 늦게 하더라도 꼭 슬랙에서 얘기를 나누었는데.. 이렇게 서로 커뮤니케이션의 끈을 놓지 않았다는 점도 사이드 프로젝트를 완수할 수 있었던 요인이 아닐까 싶다.




앞으로의 계획

'출시만이라도 하자'라는 목표는 완수했다. 그런데 막상 출시를 하고 세상에 내놓아보니 욕심이 생겨버렸다. 사실 욕심이라기보다는 '계속해서 운영 경험을 쌓을 수 있는' 우리만의 서비스를 만드는 것이 초기 목표이긴 했었다. 그래서 다시 한번 이 초심(?)을 되찾으려는 여정을 시작해보려고 한다.


<주니어 서비스 기획자의 사이드 프로젝트 여정 기록>은 아직 끝나지 않았다. 앞으로는 출시를 한지 얼마 안 된 지금 이 시점부터의 이야기를 차근차근 담아내고자 한다. 아마 서비스 홍보, 데이터 분석 등등의 서비스 개선 이야기에 대해 쓰지 않을까 싶다.


제대로 된 프로덕트를 만들기 위해, 실제 우리 서비스를 통해 개선된 회의를 경험하는 직장인들이 생겨나기 위해, 우리들의 사이드 프로젝트는 챕터 2로 넘어가 보려고 한다! (챕터 2에선 나의 글쓰기 실력도 늘어나길..)



투 비 컨티뉴..


 



작가의 이전글 주니어 서비스 기획자의 사이드 프로젝트 여정 기록(4)
작품 선택
키워드 선택 0 / 3 0
댓글여부
afliean
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari