SOPT 기획 파트 회고(6) 앱 서비스 출시하기
16시간 해커톤에서 출시까지
SOPT 27기 솝커톤은 굉장히 성공적이었다. 시연 연상이 잘 나왔고, 팀워크는 훌륭했으며 인기상까지 수여 받았다.
회고를 하러 뒤풀이를 열었을 때 모두 '출시'를 하고 싶다했다. 그래서 우린 앱잼 이전, 그리고 앱잼 이후에 출시를 위해 모였다.
기획 재정비하기
솝커톤 때 단시간내에 회의해서 나온 아이디어였다. 즉 초기 칭찬할고래는 기획의 정당성이나 고객 니즈 파악은 하지 않고 기획한 어플이다. 앱잼이 끝난 후 기능을 다시 살피며 생각했다.
매일 칭찬을 주는 어플이 본질적으로 필요한가 ?
칭찬 카드, 칭찬 레벨, 순위가 고객 니즈에 맞는가?
앱잼 덕분에 나는 '고객 니즈'를 우선 시하는 서비스 기획자로 성장했다. 그래서 칭찬할고래에 칭찬과 관련된 고객 니즈를 파악 한 후, 기능을 대거 추가/수정하고 싶었다. 하지만 우리는 솝커톤에서 출발한거고, 앱잼이 아니었다. 출시 자체가 목표였기에 기능을 추가하지 않기로 약속을 했었다. 그래서 서비스 기획자로서의 내 미션은 '기능 수정 없이 정당성 확보하기' 였다.
그래서 회의 도중 기획자가 아닌 팀원들이 기획에 대한 의견을 내면 최대한 수렴하여 수정하되, 추가하지 않는 방향으로 진행했다.
기능 수정없이 기획의 정당성 확보하기
칭찬할고래는 매일 아침 9시마다 유저에게 칭찬 미션을 보내준다. 칭찬 데이터 확보는 기획자의 임무였다. 칭찬 미션을 통해 고객 니즈를 반영하여, '유저가 듣고 싶어하는 칭찬'을 모으기로 했다.
그래서 우리 팀원들의 각 학교별 에브리타임과 여시, 캠퍼스픽 등등 MZ세대가 자주쓰는 커뮤니티에 글을 써서 사람들이 듣고 싶어하는, 실제로 듣기 좋았던 칭찬과 이유를 모았다. 원활한 수집을 위해, 거부감이 들지 않기 하기 위해서 의도를 숨기고 글을 썼다. 추첨을 통한 보상이 있는 설문조사 식으로도 진행을 했었다.
그렇게 얼추 모은 칭찬 데이터를 보기 좋게 가공했다. 수집한 이유를 토대로 칭찬 미션 문구를 만드는데 힌트를 얻을 수 있었다. 그렇게 112개의 칭찬 미션을 만들 수 있었다. 더 만들고 싶었지만 중복되는게 많았고, '칭찬은 반복하면 할 수록 좋은 것'이란 초기 기획의도를 들어 112개를 3번 반복해 1년을 채우기로 했다.
기획자의 역량 : 세밀한 커뮤니케이션을 통해 설득하기
원래 칭찬의 대상은 지인이었다. 그러다 칭찬의 대상을 넓히자는 의견이 나왔다. 칭찬할고래의 기획 의도가 '칭찬에 인색한 사람들을 어플을 통해 칭찬에 익숙해지도록하자!' 였으니까. 지인 -> 부모님 -> 버스 기사님, 즐겨보는 웹툰 작가(댓글로 칭찬), 학교 미화원, 경찰 등 평소에 도움을 받지만 감사 표현을 하지 못한 분들 대상으로 칭찬 미션을 만들어보잔 의도였다.
물론 부담스러울 수 있으니
지인에게 하는 칭찬 미션을 약 두 달 동안 실행한 후에 특정 대상에 대한 칭찬 미션을 주자
이 미션은 총 336개의 칭찬 미션 중 14개라 크게 부담스럽게 느껴지지 않는다.
어느 정도 칭찬을 시도하고, 습관화한 유저라면 시도해볼 수 있다
이렇게하자고 했다. 사실 이게 서버 개발자 언니랑 칭찬 미션 문구의 맞춤법을 고치다가 나온 얘기였고 좋다는 생각이 들었다. 그래서 이유를 세밀하게 얘기하지 않고 그냥 가볍게 '칭찬대상을 늘리기로 했어!'라고 단톡방에 말을 했는데 팀원 전반이 엄청난 반대를 표했다.
'원래 지인 대상으로 하는거 아니었어?'
'난 학교 미화원, 경찰분께 말 잘 못걸거 같은데'
'갑자기 ??'
팀원의 반응을 보며 기획 수정을 근거 없이 가볍게 언급하는건 굉장히 잘못된 일이란걸 깨달았다. 현재 대상을 넓힌 칭찬 미션, 의도, 팀원들의 우려에 대한 점을 다 정리해서 슬랙에 올렸다.
슬랙에서 이렇게 길게 써본 적은 처음이었다.이 글을 본 후 팀원들이 처음부터 이렇게 설명을 하면 좋았을 것이라 피드백을 해줬다. 모두 다 칭찬대상을 확장하는 것을 동의했고, 군인과 경찰은 너무 부담스러울거 같아서 뺴기로 했다.
기획 수정을 근거 없이 가볍게 언급하는건 굉장히 잘못된 일이란걸 다시 한번 느꼈다. 기획자는 항상 기획의 정당성, 근거를 세밀하게 먼저 제시해야 혼란이 생기지 않는다. 그것이 팀원들에 대한 예의이기도 하다.
기획자로서 코로나 시국에 10명의 팀원 매니징하기
칭찬할고래 릴리즈 기간은 2021.01 - 2021.03이었다. 5인미만 집합 금지에 합숙도 할 수 없어서 최대한 슬랙과 노션을 적극 활용했었다. 또한 이런 기간에 10명이나 되는 팀을 기획단으로서 매니징하는건 쉽지 않은 일이었다. 그래서 이것저것 좀 도입을 해봤다.
1. 분위기 환기하기
예를들어 난 첫 회의부터 제대로 릴리즈 계획을 세우고 싶었다. 하지만 PM은 첫 회의인만큼 앱잼이 어땠는지 등의 사적인 얘기를 하며 분위기를 환기해 무겁게 시작하지 않게 했다. 직접 첫 회의를 하며 가볍게 시작하길 잘했다는 생각을 했다. 릴리즈 과정은 험난하기에 처음부터 무거울 필요는 없는거 같다.
2. 팀원들의 니즈 파악하기
머리말랑토크
칭찬할고래는 정기 회의와 상황 공유를 위한 스크럼 회의를 주로 했었다. 오프라인으로 자주 못만나고 처음부터 회의를 하면 무거울거라 생각해 머리말랑토크를 도입했다.
"내가 가장 좋아하는 날씨와 싫어하는 날씨는?"
"요즘 가장 하고 싶은 것은?"
이런식의 머리를 말랑하게 식힐 수 있는 주제를 10분 동안 서로 얘기한 후 회의를 시작하는 것이다.
KPT 회고 도입
KPT 회고란?
1. 앞으로 계속 유지할 것(Keep):
잘된 것에 대해 이야기할 때는 개인의 덕으로 돌리는 것도 좋습니다. 칭찬을 듣고 동기부여가 되고 그런 행동을 반복하는 것은 개인에게도, 팀 분위기에도 도움이 됩니다. 마치 축구에서 엄지를 들어 올리는 행위와 비슷합니다. 팀원 서로가 서로를 인정해주고 신뢰할 수 있는 조직을 만들어야 합니다.
2. 이번에 발생한 문제(Problem)
문제에 대해 이야기하다 보면 결국 그 문제를 만든 누군가를 비난하기 쉽습니다. 그러면 팀 분위기가 안 좋아지고, 문제 자체를 이야기하지 않게 됩니다. 어떤 문제가 있을 때 특정인을 비난하는 것은 마치 축구에서 골 먹었을 때 항상 골키퍼를 탓하는 것과 비슷합니다. 문제는 항상 복합적입니다. 문제 상황의 대부분이 개인의 실패가 아닌 조직이나 시스템의 실패로 생긴다는 것을 구성원이 이해해야 합니다.
3. 다음에 새롭게 시도할 것(Try)
아주 흔하게 벌어지는 상황은 어떤 문제가 특정 개인을 향하고, 그 개인이 다음번엔 더 잘하겠다고 다짐하는 것으로 회고가 끝나는 경우입니다. 이것은 도움이 되지 않습니다. 조직과 시스템 측면에서 어떻게 그 문제를 해결할 수 있을지 고민해야 합니다
오프라인으로 못 만나다보니 소통 부제가 발생할 수 있었다. 이를 방지하기 위해 파트별 KPT 고래 타임을 도입해 진행했다.
2-3번 정도 진행하며 깨달았다. 팀원들은 회의를 그냥 빨리 끝내고 싶어했다. 우리 기획단이 팀 매니징을 위해 도입한 머리말랑토크와 KPT회고는 팀원 니즈에 맞지 않았다. 그래서 중간부터는 뺐다.
항상 팀 매니징은 어렵고 명쾌한 정답은 없는거 같다. 그때 그때 팀원들의 니즈를 파악해 반영하는 것이 최선인 거 같다.
중간 중간에 처리해야하는 이슈가 굉장히 많았다. 기획에 조금이라도 궁금증이 생기거나 어긋나다고 생각되는게 있으면 항상 기획단이 소환됐기 때문이다.
기억에 남는거 몇 개를 좀 적어본다
1. 온보딩의 제한
온보딩 와이어프레임을 디자이너 언니에게 넘겨주었다. 나름 여러 어플을 다운받아 온보딩 래퍼런스를 모은 후 와이어프레임을 만들었다. 기획 의도를 다 담다보니 5개의 뷰가 나왔었고 래퍼런스를 삼은 몇몇 어플이 그랬어서 괜찮다고 생각했다.
이에 대해 '온보딩이 너무 많으면 앱 기능을 소개하려는 좋은 의도라고 해도 앱 이탈을 유도할 수 있기 때문에 3~4개가 한계다'란 디자이너 언니의 피드백이 있었다. 디자이너 언니에게 고마웠던 점은 우리 기획단이 생각하지 못한 UX 적인 피드백을 항상 해준다는 것이다.
이런 UX 적인 건 배워보지 못했기 때문에 좀 신기했던거 같다. 이래서 디자인하는건 실력상 좋아하지 않지만 UX적인 이론을 배운다는 점에서 디자인 파트가 항상 부럽다.
2. 기능 추가에 대한 긴 논의
하루는 칭찬미션 "못했어요", "했어요" 버튼 둘 중 하나를 이미 눌렀을 경우 - 홈으로 다시 돌아왔을 때의 어떻게하냐를 논의했다. 내가 제시한 1,2안 둘 중 무엇을 할지 선택을 해야했다.
1안 : 했어요, 못했어요 버튼이 사라진 칭찬 완료/실패 뷰로 나누기
칭찬 미션 도착 푸시 알림 -> 어플에 첫번쨰 방문하여 칭찬 미션을 확인한 후 -> 유저가 칭찬 미션을 성공했냐 실패했냐에 따라 나뉜다.
1. 칭찬 미션 완료 뷰
칭찬 성공 -> 어플에 재방문하여 '했어요 버튼' 클릭 시 -> 칭찬미션 뷰는 완료뷰 ( 했어요, 못했어요 버튼이 사라지고 기뻐하는 고래가 나옴) 로 변경 됨
2. 칭찬 미션 실패뷰
칭찬 실패 -> 어플에 재방문하여 '못했어요 버튼' 클릭 시 -> 칭찬 미션 뷰는 실패 뷰로 변경됨(했어요, 못했어요 버튼이 사라진 후 우는 고래가 나옴)
이거 와이어프레임임...최종뷰아님..
제안 이유
1. (디자인) 미션 진행 유무 칭찬 미션 카드 내에서 알려주는 게 가장 효과적
2. (기획) 칭찬에 대한 동기부여 및 미션 진행 유무 알림
우려 되는 점
1. 못했어요를 눌렀을 경우 사용자를 차단하는 느낌을 준다
- 칭찬 내용 자체를 가려버리진 않기 때문에 지속적으로 칭찬을 할 기회는 주어진다
2. 개발이 복잡하다
칭찬 미션 완료/ 실패뷰 구현에 관한 회의를 하는데 이런 얘기가 나왔다.
2안 : 했어요, 못했어요 버튼은 놔두고 토스트 메시지 띄우기
제안 이유
1. 개발이 간단하다 (효율, 시간 절약)
우려 되는 점
1. 미션 진행 유무를 직관적으로 알려주지 못한다
2. 칭찬에 대한 동기부여의 약화
개발난이도와 유저 입장을 고려하여 1,2안 둘 중 뭐가 나을지 논의하고 있었다. 그때 한 팀원이 이렇게 말했다.
" 그런데 칭찬을 안했는데 어플에 다시 들어오는 이유가 있어?"
어라. 그러게 말이다. 그래서 구현 전에 이 기획이 옳은가에 대해 다시 얘기를 하게 됐다.
알림을 굳이 설정하면서까지 칭찬을 해야할 필요가 있는가? 칭찬할고래의 의도는 무엇인가? 팀원들이 다같이 되돌아보게됐다.
일단 기본적으로 아침 9시에 칭찬 미션을 알려주는 푸시알림이 떠 유저는 기본적으로 어플에 한번 들어간다.
그래서 오후 9시에 "칭찬을 하셨나요? 칭찬으로 하루를 마무리해봐요!" 이런식의 리마인드 푸시알림을 추가하는게 어떠냐는 얘기가 나왔다.
그런데 아침 9시는 출근 준비 시간이라 정신없으니 지인을 만나는 오후에 첫 알림을 주는게 낫지 않냐는 추가 의견도 다시 나왔다. 그럴거면 그냥 유저가 편한 시간에 알림을 설정할 수 있게 기능을 추가하자는 의견이 나왔다.
점점점 기능 추가/수정에 대한 의견이 많이 나오기 시작했고 방향이 다르게 흘러가기 시작했다. 처음에도 언급을 했지만 우린 약 16시간의 솝커톤에서 시작한 어플인만큼 기획의 정당성이 약하다. 앱잼도 아니고 솝커톤에서 시작해 릴리즈를 하는 만큼 최대한 기능 추가없이 사이즈를 그대로 유지해서 가기로 약속을 한 터였다.
그래서 내 목표는 항상 "최대한 기능 수정없이 기획의 정당성 확보하기"였다. 그래서 기능 사이즈와 상관없는 칭찬 미션을 크게 바꾼 것이었다.
회의 방향성이 팀의 목표와 점점 멀어지고 있었고 바로 잡아야 한다는 생각이 들었다. 난 서비스 기획자이며 팀 기획자이기 때문이다.
"지금 나온 의견을 적용하려면 근본적인 기획부터 다 바꿔야해"
"솝커톤 때 나온거라 완벽하지 않아. 더 나은 기획보다 기간 안에 끝내는 것이 더 중요해"
"우리 처음 약속은 기능 추가 없이 가기로 한거잖아? 우린 이 약속을 꼭 지킬거야 "
실제로 나와 PM이 회의 중간에 정리하려고 이런 말을 했었다. 모두들 초기 약속을 상기하며 수긍했다. 그래서 일단 1안으로 가기로 했고, 더이상의 기능 추가 논의는 나오지 않았다. 초기 약속처럼 순조롭게 갈 수 있었다.
코딩해본 기획자
칭찬할고래 홈뷰칭찬할고래의 홈뷰다. 보다시피 굉장히 예쁘다.
기획단이 수집한 칭찬 데이터를 서버 개발자에게 넘겨줘야했다. 칭찬 미션이 그리 길지 않기 때문에 줄 바꿈으로 뷰에 예쁘게 띄워졌으면 좋겠단 생각을 했다.
난 프로그래밍, 컨텐츠, 디자인, 영상을 다 배우는 융합 학과에 배운터라 어느정도 프로그래밍 지식이 있었다.
그래서 서버 개발자에게 칭찬 미션에 '\r\n' 개행문자를 추가해도 되냐고 물었다.
서버 개발자는 그래주면 더 좋다고 했다. 그래서 한 줄당 최대 글자수를 고려하여 개행문자를 추가해 칭찬 미션을 넘겨주었고, 뷰에 더 예쁘게 띄울 수 있엇다.
만약 내가 코딩을 배우지 않았다면 사전에 이런 제안을 하지 못했을 것이다. (우리 PM은 문과라서 기획단 중에선 이런 제안은 나만 할 수 있었다.) 개발을 알아야 기획에 도움이 된다는 걸 다시 한번 꺠달았다. 이건 내가 28기 안드로이드 OB에 지원한 이유 중 하나기도 했다. (나중에 포스팅 예정)
이번 글에선 솝커톤에서 릴리즈를 하는 과정에서 기획 측면에 대한 내용을 주로 다뤄보았다.
2편에선 QA 과정, 출시 이후, 전체적인 느낀 점을 다루며 마무리할 것이다.
