서비스 기획자는 무슨 일을 하는가 (1)
기획자의 업무 A-Z
0. INTRO
대부분이 직업들이 그렇겠지만 사실상 현업에 투입되기 전까지는 어떤 일을 하는 직업인지 쉽게 알 수 없다. 나 역시 그러했다. IT 업계에서의 서비스 기획자라는 직군은 "기획자는 그냥 코딩이랑 디자인 빼고 다 한다고 보면 됨"이라는 말이 돌아다닐 정도로 그 업무의 범위가 상당히 넓기 때문에 도대체 무슨 일을 하는 직업인지 가늠하기 어려웠다.
대충 기능을 정의하고 UX를 설계하는 것 까지는 알고 있었지만, 본격적으로 서비스 기획자로 취업하고 나서야 비로소 나는 기능 정의 및 UX 설계 업무는 기획자가 담당하고 있는 업무의 '빙산의 일각의 일각'이라는 사실을 마주할 수 있었다.
현업에 투입되고 나서야 그 사실을 마주하게 될 서비스 기획자가 되고 싶은 사람들을 위해서 최대한 구체적이고 현실적인 버전의 '기획자의 업무 A to Z'를 나열해보고자 한다.
서비스 기획자의 업무는 최근 PM(Product manager), PO(Product owner), PD(Product designer)라는 직군들과 일부 겹치는 부분이 있지만 이 글에서는 일반적으로 '서비스 기획자'라고 불리는 직무에 대해서 다뤄보고자 한다.
아무래도 내가 경험한 회사에서의 업무 위주로 작성되었기 때문에 이 글이 모든 회사의 서비스 기획자들이 하고 있는 업무를 대변하지는 않는다. 조직 구조, 담당하는 서비스의 성격, 클라이언트의 유무에 따라 하는 일에는 많은 차이가 있기 때문이다.
참고로 내가 속했던 조직들은 아래와 같다. 별도로 클라이언트가 존재하는 형태의 에이전시 근무 경험은 전혀 없고, 전부 인하우스에서의 업무 경험만 해왔다.
국내 IT 계열 대기업
국내 이커머스 기업 내 신사업실
초기 단계의 스타트업
1. 서비스 전략 수립 및 기획
1-0.
시장 조사 및 Pain points 발견
신규로 런칭을 준비하고 있는 서비스라면 시장에서 Pain points 와 Needs를 발견하는 것부터 시작한다. (물론 이것은 엄연히 따지면 기획자 혼자만의 역할이라기 보단 서비스를 어떻게 만들기 시작하는가에 해당하는 내용이기는 하다.)
발견한 Pain points 와 그를 해결하는 과정에서 돈을 벌 수 있는 기회를 포착되면 본격적으로 서비스를 구체화하기 시작한다.
1-1.
서비스 컨셉 및 방향성 수립
그렇게 어떤 카테고리의 서비스를 만들어야겠다는 것이 대략적으로 정해졌다면, 해당 서비스가 시장의 어떤 문제를 어떻게 해결한 것인지에 대해서 정리하는 단계로 이동한다. 이 단계에서 내가 만드는 서비스가 어떠한 컨셉으로 사용자들에 보이기를 원하는지에 대해 논의하기도 한다. 이 부분은 브랜딩과 연관된 부분으로 시각적인 영역에 전문성이 있는 디자이너들과 협업한다.
어떤 사용자들을 주요 타겟으로 할 것인지를 함께 정리하며 중장기적으로 어떤 서비스로서 시장에서 자리매김할 것인지에 대한 방향성을 수립한다.
1-2.
프로덕트 로드맵 작성
프로덕트를 만듦에 있어서 로드맵이라는 것을 활용하는 팀도 있고 활용하지 않는 팀도 있는 것 같다. 사용자들은 우리가 예측한 대로 움직이지 않을 수도 있고, 사실 서비스의 미래는 두어 달 미래도 예측하기 어려운 것이 사실이기 때문에 일단 빨리 출시하고 반응을 확인한다는 생각으로 로드맵 없이 운영되는 서비스도 있다. (장단이 있다고 생각한다.)
로드맵은 주로 기획에서 작성을 시작하지만, 다른 파트들로부터 받는 실현 가능성, 대략적인 리소스, 회사 내외부의 이벤트와 관련한 피드백들을 받아보면서 싱크를 맞추고 로드맵에 현실감을 반영한다.
로드맵이 있다는 것의 장점은 특정 기간 동안에 필요한 리소스를 미리 예상하여 계획할 수 있다는 점과, 서로가 같은 방향을 보고 일을 진행할 수 있다는 점에 있다고 생각한다.
1-3.
KPI 설정 및 관리
우리 프로덕트의 성장을 어떤 지표를 바탕으로 평가할 것인가에 대해서 정의를 하는 업무이다. Data scientist/analyst 가 있는 조직이라면 그들과 함께 이를 정의하고 지속적으로 트래킹 한다. 월별/연간 목표 KPI를 세우고 그를 우리 팀이 잘 달성하고 있는지를 확인하며 서비스가 잘 성장하고 있는지 확인한다.
초기에 설정한 KPI를 계속해서 달성하고 있지 못하고 있다면, 혹시 우리가 무리한 수준으로 목표 KPI를 잡아둔 것은 아닌지, 무엇이 문제인지, 해결하기 위해서는 어떤 것들이 필요한지에 대해서 논의한다.
2. 프로덕트 기획
2-1.
기획 안건 선정 (백로그 우선순위 관리)
어떤 기능을 기획할 것인지를 선정하는 업무이다. 출시해야 하는, 출시하고 싶은 기능들은 산더미이다. 이 기능들을 쌓아둔 것을 주로 Backlog(백로그)라고 표현한다. 이 백로그 중에서 우선순위에 따라 기획 안건을 선정한다. (백로그 우선순위에 대한 부분은 2편에서 자세히 언급하겠습니다.)
2-2.
기획 의도 및 배경 정리
기획 안건을 선정했다면 본격적으로 상세 기획에 들어가기에 앞서, 이 기능이 왜 사용자에 필요한지, 어떤 것을 목적으로 하는지, 기대하는 효과는 무엇인지에 대한 내용을 논리적으로 정리한다. 기획자가 하는 업무 중 가장 중요한 업무 중 하나이다.
이때 정성적으로 논리 구조를 만드는 것도 필요하지만, 가능한 데이터를 기반으로 기획에 대한 근거를 확보하는 것이 중요하다. '우리는 이 것을 해야 해'라는 것에 대해서 다른 파트들을 설득을 위해서는 숫자만큼 확실한 무기가 없기 때문이다.
데이터를 추출하고 그를 분석하는 것은 전문 지식이 필요한 부분이다. 훌륭한 기획자분들은 이 업무 또한 직접 하실 것이다. 하지만 Data analyst 가 함께하는 프로젝트라면 그들의 도움을 받기도 한다. 기획자는 어떤 데이터를 봐야 원하는 궁금증을 해결할 수 있을지, 어떤 목적으로 데이터를 보고 싶은지에 대한 부분에 대해서 데이터 분석가들과 논의한다.
2-3.
리서치 및 벤치마킹
해야 할 것이 명확한 경우는 스킵하는 경우도 있지만, 타사의 사례나 사용자 리서치를 활용하면 기획의 방향성을 구체화하거나 논리를 더 단단하게 만들 수도 있다.
이 과정에서 직접 유저 리서치를 진행하기도 하고 전문 리서쳐들에게 리서치를 의뢰하기도 한다. 리서치를 의뢰하는 경우에는 어떤 목적으로 이 리서치를 의뢰하는 것인지, 무엇이 궁금한지, 어떤 것을 얻고 싶은지에 대한 부분을 정리하여 전달한다.
벤치마킹은 '남들이 이미 이렇게 하고 있으니까 우리도 이렇게 해버리자'라는 의도로 진행하는 것이 아니라 타 서비스들의 사례에서 '배울 점'과 '아쉬운 점'을 뽑아내어 그를 우리 서비스에 적절하게 녹이기 위해서 진행한다.
2-4.
기획서 작성 (UX 설계, 상세 기획, 정책 수립)
기획자의 주 업무 중 하나이다. 기획서를 어떤 툴로, 어떻게 작성하느냐는 회사마다 많은 차이가 있다. '기획자'라는 직군이 없는 회사는 Product designer 라고 불리는 사람들이 디자인과 상세 기획을 함께 정리하기도 한다. 또한 애자일 하고 린하게 움직이는 조직이라면 기획서를 작성하는 순간부터 제품 개발팀이 함께 참여하기도 한다.
일반적인 기획서에는 와이어프레임이라고 불리는 대략적인 화면의 구조를 정리한 이미지와 각각의 페이지 및 버튼들이 어떻게 작동하는지에 대해서 기술되어 있다.
그 외에도 Edge/Corner case 라고도 불리는 수많은 예외 케이스들과 (용어의 차이는 있을 수 있다.) Error 가 났을 때는 어떻게 처리해줄 것인가와 같은 부분에 대한 정리도 필요하다.
정책이라고 하는 것에는 아주 많은 것들이 포함된다. 어떤 Device (iPad/WatchOS/PC 등)까지 대응할 것인지, 다크 모드/가로모드는 대응할 것인지와 같이 비교적 상위 개념에 속하는 정책부터 해당 페이지에서 최대 입력 글자는 몇 개인지, 한 번 스크롤할 때마다 몇 개의 결과를 불러올 것인지와 같이 디테일한 부분의 정책도 정의가 필요하다.
눈에 보이는 기능에 대한 정리가 50이라면 눈에 보이지 않는 기능에 대한 정리가 100인 것 같다.
2-5.
디자인 협의
기획서가 1차적으로 정리가 되면 디자인 요청을 진행한다. 기획서를 작성하기 시작할 때 디자인을 요청하는 경우도 있다. 디자인이 구체화되면서 세부적인 기획 내용이 달라지는 경우도 많아서, 긴밀하게 협업하여야 효율적으로 일할 수 있다. 소통 없이 각자의 일(기획자 - 기획서 작성, 디자이너 - 시안 구체화)만 열심히 하면 서로의 작업물에 대한 싱크가 맞지 않아서 서로 일을 두 번 해야 하는 경우가 발생할 수도 있다.
디자이너가 공유해주는 시안을 바탕으로 KPI 측면에서 더 좋은 UX는 없을지 함께 논의하고, 또 실제로 구현이 가능한 디자인인지에 대한 부분도 기술팀에 문의하며 구체화시킨다.
2-6.
UX writing
서비스 내에 들어가는 문구들을 작성하는 업무이다. (메뉴 이름, 버튼 이름, 팝업 문구 등) 요즘은 UX writer 라고 문구 작성 업무만을 전문적으로 하는 직군도 존재한다. 아직은 기획자가 기획서를 작성하며 문구 작성도 같이 하는 곳이 더 많은 것 같다.
하지만 문구라고 하는 것은 실제로 서비스 톤 앤 매너에 매우 중요한 역할을 하는 부분 중 하나이기 때문에 전문 UX writer 를 팀 내로 고용하는 경우가 많이 늘고 있는 것 같다. 특히 다양한 국가에 서비스를 제공하는 글로벌한 서비스의 경우 각 국가의 문화에 맞는 문구 번역이 필수적이기 때문에 전문가에게 해당 업무를 맡기는 편이다.
2-7.
Data 설계
이 업무도 자신의 팀에 Data와 관련한 전문 인력이 없느냐, Data 관리 시스템에 대한 환경의 수준 등에 따라서 많은 차이가 있을 것이다. 하지만 기본적으로 어떤 데이터를 수집하여 어떻게 활용할 것인지, 무엇을 알아내고 싶은지에 대한 고민은 기획자가 필수적으로 해야 하는 부분이다.
2-8.
리뷰 미팅 진행
스펙 리뷰란, 작성된 기획서와 디자인 시안을 바탕으로 구현을 담당하는 기술자들에게 스펙을 설명하는 업무이다. 왜 이 기능을 출시해야 하는지, 왜 개선해야 하는지 기획 의도와 목적을 설명하고 어떤 기능을 사용자들에게 제공하고자 하는지에 대해서 자세히 설명한다.
기획자에게는 미처 검토하지 못했던 Edge/Corner/Error case 에 대한 피드백을 수집하거나, 기술적으로 구현이 가능한지, 대략적인 공수가 얼마나 드는지(너무 많은 공수가 든다고 하면 기능을 축소하거나 간소화할 필요가 있다.)에 대한 정보를 얻을 수 있는 시간이다.
결국 분량 조절에 실패하여..
2편으로 돌아오겠습니다 !
