서비스 출시만 하면 여유로워질까?
주니어 PM의 스타트업 적응기 #6
마지막 글을 올린 지 벌써 한 달이 지났다.
브런치에서는 '작가님을 기다린다'는 알림을 수차례 보냈지만, 쉽사리 브런치 글을 쓸 수 없었다.
입사 직후부터 담당했던 서비스의 출시가 임박했었기 때문이다.
서비스 출시 날짜가 다가오면서, 퇴근 시간도 점점 늦어졌다.
9시 전에 집에 도착하는 날이 없었고, 10시가 넘어서 집에 도착하는 날도 더러 있었다.
매일매일 피곤에 찌들어 퇴근하는 버스에 몸을 맡길 때마다
서비스 출시만 하면 꼭 칼퇴를 해야겠다는 생각을 빼놓지 않고 했었다.
정신없이 시간은 흘러갔고, 어느새 서비스가 출시되었다.
그러나, 여유로워질 것이라는 예상과는 다르게 퇴근 시간은 쉽사리 빨라지지 않았다.
경력이 있는 PM이라면 서비스를 출시하고 나면 좀 쉬어보겠다는 신입 PM을 보고 아직 멀었다는 생각을 할지 모른다.
반대로, PM을 꿈꾸고 있거나 아직 서비스를 한 번도 출시해보지 않은 신입 PM이라면 왜 서비스가 출시되었는데도 계속 바쁜지 이해하기 힘들 것이다.
우선, 서비스 출시일이 다가올수록 PM이 왜 바빠지는지 이해할 필요가 있다.
당연하게도 서비스를 출시하기 전에 테스트 환경에서 서비스에 대해 여러 테스트를 해본다.
기획 방향에 맞추어 서비스가 동작하고 있는지, 오류 없이 개발이 완료되었는지, 그리고 막상 구현해보니 유저에게 불편함을 주지는 않을지 등등 A부터 Z까지 모든 것을 테스트한다.
테스트하느라 화면을 너무 많이 봤더니 오류도 안 보일 지경이고, 게슈탈트 붕괴로 모든 게 이상해 보인다.
『현업 기획자 도그냥이 알려주는 서비스 기획 스쿨』393p
이 때는 서비스와 관련된 대부분의 인원이 테스트에 참여한다.
많은 인원이 테스트를 진행하는 만큼 오류가 끝도 없이 쏟아져 나온다.
이렇게 쏟아져 나오는 오류는 모두 PM에게 보고된다.
보고된 오류에 대해 PM은 아래 내용에 따라 이슈들을 분류해야 한다.
정말 오류인가?
출시 이전에 꼭 해결해야 하는 오류인가?
출시 이전에 꼭 해결하지 않아도 되지만 출시 후 우선순위가 높은 오류인가?
무시해도 되는 사소한 오류인가?
기획 내용이 수정되어야 하는 오류인가?
기획 내용이 수정되어야 한다면 어떻게 수정되어야 하는가?
오픈 시점까지 해결이 불가능한 경우 의사결정 피드백을 빨리 내릴 수 있도록 '기획 우선순위'에 대한 기준을 미리 마련해둔다면 모든 오류 건에 대해 스트레스를 받을 필요가 없다.
『현업 기획자 도그냥이 알려주는 서비스 기획 스쿨』397p
짧은 시간 안에 많은 오류들을 정확하게 분류하기 위해서는 조건이 있다.
우선, 서비스 기획 의도를 이해하고 있어야 한다.
만약 서비스 기획 의도를 알지 못한다면 보고되는 오류가 정말 오류인지, 아니면 의도적으로 기획한 것인지 답변하기 어렵다.
또한, 서비스의 방향성을 이해하고 있어야 한다.
이는 오류 해결에 대한 우선순위를 결정하는 데 꼭 필요하다.
'고객이 느끼는 불편함을 최소화한다'는 서비스 방향성이 있다면, 회사가 손해를 보게 되는 오류는 우선순위를 낮추고 고객이 불편함을 느끼는 오류만 먼저 해결하면 되기 때문이다.
위와 같은 조건을 갖추더라도 해결하기 힘든 케이스가 있다.
바로, 기획 내용이 수정되어야 한다면 어떻게 수정되어야 하는가? 에 대한 경우이다.
추가 질문과 고민은 서비스가 오픈하기 전까지, 심지어 개발과 테스트 기간에도 계속된다. 기획자가 최대한 머리를 짜내는 것은 예의이고, 이슈가 발견될 때마다 빠르게 정리해서 디스크립션을 업데이트하고 협업자의 업무를 정리해주는 것은 센스이다.
『현업 기획자 도그냥이 알려주는 서비스 기획 스쿨』352p
일정에 맞추기 위해서는 디자이너와 개발자의 업무 리소스를 최소화하면서 기획적으로 문제가 없도록 기획 내용을 수정해야 한다.
시간이 얼마 남지도 않았는데 UX 분석이나 타 서비스 분석부터 다시 하고 있을 여유가 없기 때문이다.
센스를 발휘해 해결이 쉽지만 고객에게 보여주기에는 문제가 없는 기획을 빠르게 진행해야 한다.
다른 업무는 제쳐두고 이슈만 처리하다 보니 어느새 서비스 출시일이 되었다.
api 배포부터 시작해 웹 프로덕션을 배포하는 순간까지 떨리는 마음을 감추기 힘들었다.
입사 후 3개월 만에 담당했던 서비스가 처음으로 배포되는 것이기 때문이다.
심지어, 회사에서는 약 1년 6개월 동안 준비했던 프로젝트였기에 전사가 집중하고 있었다.
프로덕션 배포가 모두 완료되고 함께했던 디자이너와 개발자들 모두에게 한 명 한 명 찾아가 수고했다는 인사를 전했다.
그렇게 화기애애한 분위기 속에서 3분쯤 지났는데, 누군가 큰 소리로 핫픽스급 오류가 있다고 소리쳤다.
눈앞이 아찔해졌다.
그렇게 많은 테스트를 거쳤고 수도 없는 이슈들을 힘들게 해결했는데 배포하자마자 핫픽스가 있다니...
핫픽스를 외친 누군가의 목소리는 또 다른 시작의 출발을 알리는 소리에 불과했다.
끝없이 핫픽스급 오류가 터져 나왔으며, 출시 이전보다 더 어려운 이슈들을 더 빠르게 해결해야 했다.
이에 더해 고객들의 불만 섞인 문의가 빗발쳤고 핫픽스급 오류들과 뒤섞여 끝없는 이슈들이 나한테 밀려왔다.
멘탈이 처참히 무너지는 순간이었다.
하지만, PM이 흔들리면 서비스 자체가 흔들리는 것과 마찬가지기 때문에 의연하게 대처하고자 노력했다.
다행히 사수가 많이 도와준 덕분에 급한 불은 어느 정도 해결할 수 있었다.
서비스를 출시하기만 하면 여유로워질 줄 알았는데 전혀 그렇지 않다.
테스트하면서 나온 오류들에 대해 출시한 뒤에 해결하려고 미뤄둔 이슈들이 있었고,
여기저기서 새롭게 터져 나온 이슈들까지 더해져 업무가 훨씬 많아졌기 때문이다.
또다시 PM에게 밀려오는 이슈들을 파악하고 분류하고 해결해나가는 과정을 반복해야 한다.
서비스를 출시하는 것은 새로운 시작과 같다.
서비스가 새롭게 탄생했다면 잘 성장하기 위해 옆에서 끊임없는 보살핌이 필요하다.
마치 아기가 태어나면 성인이 될 때까지 부모님은 쉴 수 없는 것처럼 말이다.
서비스 출시만 하면 칼퇴하고 집에서 쉬겠다는 다짐과는 다르게
여전히 나는 밤늦게 지친 몸을 버스에 맡기고 있다.
