서비스 기획자는 무슨 일을 하는가 (2)
기획자의 업무 A-Z
분량 조절 실패로 2탄을 갖고 왔습니다. 1탄은 아래 브런치 글을 참고해주세요.
그리고 쓰다 보면서 느낀 것인데, IT 업계(혹은 다른 업계도 마찬가지일 것 같긴 합니다만)는 정말 굳이 써야 할 필요가 없는 외래어, 외국어를 많이 사용하는 것 같다. 쓸데없는 외래어, 외국어 사용을 지양하고 싶지만 이미 현업에서 많이 쓰이는 단어이고 그것을 그대로 살려서 적는 것도 의미가 있겠다 싶었다. 그래서 해당 글에서 등장하는 남용되는 외래어, 외국어들을 양해해주시면 감사하겠습니다.
3. 개발 및 QA 대응
3-1.
진행사항 트래킹
말 그대로 프로젝트가 굴러가고 있는 상황을 계속해서 지켜보고 일정대로 각 파트가 잘 움직이고 있는가를 확인하는 업무이다. 하나의 서비스를 만들기 위해서는 다양한 파트들이 움직이는데 각 파트의 업무들은 당연히 유기적으로 연결되어 있다. 예를 들어 디자인이 끝나야, 디자인 가이드 작업을 진행할 수 있고, 가이드 작업이 완료되어야, 프론트엔드 개발 작업을 진척시킬 수 있다. 그렇기 때문에 하나가 밀리면 뒤에 이어서 진행되어야 하는 업무들의 일정까지 밀리게 되고, 그렇게 되면 해당 담당자가 진행하고 있는 다른 프로젝트의 스케줄에도 영향을 주게 된다.
사실 밀리는 것 자체보다는 그렇게 밀리는 스케줄이 공유가 제대로 되지 않는 것이 더 문제이다. (원래 모든 일들은 계획한 일정대로 되지 않는 경우가 훨씬 많다.) 따라서 기획자는 각 파트에서 진행되고 있는 업무들의 진행 상황과 목표 일정에 문제가 없을지 확인하고 문제가 있다면 다른 파트에게 빠르게 공유하고 해결책을 찾아야 한다.
당연히 일정만 문제가 되는 것은 아니다. 디자인을 하다 보면, 개발을 하다 보면 예상치 못한 문제들, 고려하지 못했던 케이스들이 등장하게 되고, 그에 대해서 빠르게 해결책을 제시하고 의사 결정을 내리는 것은 기획자가 가장 많이 하게 되는 업무 중 하나이다.
3-2.
QA 진행 / QA 대응
QA = Quality Assurance. QA는 기획서대로 기능이 잘 구현되었는지, 기능상 결함은 없는지, 제품 출시 전 제품의 전반적인 퀄리티를 검수하는 단계로서 출시 전, 반드시 거치게 되는 과정이다. 이 QA는 기획자나 다른 프로덕트 멤버들이 진행하는 경우도 있고, 조금 규모가 있는 조직이라면 별도의 QA 조직에서 진행하게 된다.
QA를 진행하다보면, 예상하지 못했던 케이스(엣지케이스, 에러케이스)들이 자꾸 튀어나온다. 예상하지 못했던 케이스란, 기대결과가 기획서에 명확하게 정의되어 있지 않은 케이스라고 봐도 무방하다. 여하튼 기획자는 그런 케이스들에 대해서 기대결과를 정의하는 업무를 한다.
또 기획서대로 동작하지 않는 일부 오류들에 대해서 반드시 수정이 필요한 안건인지, 혹은 수정 작업이 어렵고 마이너한 이슈이므로 그냥 오류 동작 그대로 내버려둘 것인지에 대해 결정하고 판단하는 업무도 한다.
개인적으로 QA 기간은 기획자가 제일 바쁘게 이리저리 뛰어다니고 연락도 제일 많이 받는 기간 중 하나라고 생각한다.
3-3.
오픈 시나리오 작성
오픈 시나리오란 말 그대로 해당 기능을 어떻게 사용자들에게 출시(open)할 것인지에 대한 시나리오를 작성하는 것이다. 기능을 온전히 사용자들에게 오픈하기 위해서는 버튼 하나만 꾹 누르는 것이 아니다. 개발 A파트에서 작업한 코드를 배포하고, 그다음에 개발 B에서 작업한 코드를 배포해야 하는 순차적으로 코드를 배포해야 하는 기능들이 있고, 또 단순히 코드의 측면이 아니라 운영적인 요소도 시나리오에 포함될 수 있다. 예를 들어 서비스 운영자가 조작법을 숙지해야 할 필요가 있는 기능이라면 그들에게 기능 사용법을 안내하는 것도 시나리오에 포함된다.
또 만약 AB test 나 사내 테스트를 진행하는 안건이라면 시나리오가 더 복잡해진다. 언제부터 언제까지 테스트를 진행할 것이고, 테스트 결과를 언제까지 확인할 것이고, 일반 사용자를 대상으로는 언제 최종적으로 기능을 오픈할 것인지를 전부 고려한 시나리오가 필요하다.
4. 프로젝트 관리
4-1.
요구사항 취합 및 우선순위 반영
어떤 기능을 새로 기획하고 출시할 것인가에 대한 판단은 대부분 기획 조직에서 한다. 어떤 기능을 필요한지, 어떤 문제를 해결해야 하는지에 대한 요청은 다양한 곳에서 인입된다. 디자인팀은 디자인적인 관점에서 요청하고, 마케팅팀은 마케팅적인 관점에서 요청하고, 또 사용자는 그의 개인적인 관점에서 새로운 기능을 요구한다.
기획자는 그렇게 인입되는 수많은 요구사항들을 취합하고 기준을 갖고 우선순위를 매기는 업무를 진행한다. 우선순위를 고려함에 있어서 적용되는 기준들은 조직마다 다를 것 같다. 서비스의 주요 지표에 얼마나 큰 영향을 끼치는지,
4-2.
릴리즈(출시) 전후 공유
PR, CS, 마케팅/운영 등 기능이 출시되었음을 잘 인지해야 할 필요가 있는 유관부서들이 있다. 따라서 그들에게 어떤 기능이 언제 유저들에게 공개될 것인지 잘 공유해야 할 필요가 있다.
4-3.
릴리즈(출시) 후 결과 분석
릴리스했다고 끝이 아니다. 실제로 예상한 결과만큼의 성과를 내는지, 예상했던 것처럼 유저들이 해당 기능을 잘 사용하고 있는지, 해당 기능이 출시됨으로써 서비스 전체 KPI에 어떤 영향을 주었는지를 파악하는 후속 작업을 진행한다. 데이터 분석가들에게 의뢰하기도 하고 이미 관련 대시보드가 있다면 그를 통해 간단히 지표를 확인하기도 한다.
결과를 확인했으면 이후에 어떤 작업을 이어서 할지에 대한 것들을 논의한다. 예를 들어 생각보다 결과가 좋지 않았다면, 왜 결과가 좋지 않았는지를 파악하고 그를 어떻게 다시 개선할 것인지에 대한 업무를 이어서 진행하게 된다.
4-4.
CS 및 버그 대응
서비스와 관련해서 들어오게 되는 CS와 버그 건들을 처리하는 업무이다. 버그라고 하는 것은 사실상 오류이고, 정의된 기능대로 작동하지 않는 것이기 때문에 대부분 개발팀과 논의하여 바로 잡는 작업을 진행한다. 하지만 CS로 인입되는 것들은 다르다.
"이거 불편해요.", "이거 만들어주세요." 정말 다양한 요구사항들이 인입되는데 그렇게 CS를 인입하는 사용자도 결국 수많은 사용자 중 한 명이기 때문에 얼마나 잦게 많이 발생하는 CS냐에 따라서 처리하는 우선순위를 조정한다. 정말 긴급하게 대응이 필요한 불편점인지, 얼마나 많은 사용자들이 겪고 있는 불편함인지 등 다양한 방면으로 확인하고 진행 여부를 결정한다.
4-5.
리스크 관리
회사 혹은 서비스마다 유난히 신경 쓰는 리스크(Risk)가 있다. 예를 들어 저작권 이슈, 개인 정보 이슈, 불법 성매매 이슈 등이 있을 것 같다. 서비스적으로 의도하지는 않았지만, 그 서비스를 이용하는 사용자가 사회적으로 또는 법적으로 문제가 될만한 소지의 방향으로 활용하는 경우가 굉장히 많고 그에 대해서 어떻게 방지하고 관리할 것인지에 대한 부분도 기획자가 놓치지 말아야 하는 업무 중 하나이다.
이 리스크 관리를 전문적으로 하는 조직도 존재한다. 그럴 경우, 기획자는 해당 조직의 멤버를 도와 기능적으로 리스크들을 해결할 수 있는 방법들을 논의하고 필요한 기능들을 설계한다.
4-6.
법무/보안/특허 검토 요청
말 그대로 법적으로, 보안적으로, 특허의 관점에서 문제가 없을지 검토하는 것을 의뢰하는 업무이다. 각각에 대해서는 전문가들이 존재하고 그들에게 '우리가 이러한 기능/서비스를 출시하려고 하는데 각각의 관점에서 문제가 없을까요?'를 물어보고 문제가 있다면 그를 해결할 수 있는 방법을 논의한다.
생각했던 것보다 글이 너무 길어진 것 같다. 워낙 기획자가 담당하는 업무는 그 경계가 명확하지 않고 범위도 매우 넓어서 막상 실무를 시작하기 전에는 어떤 업무를 하는 직무인지 파악하기 어려운 부분이 있는 것 같다. 누군가가 간지러워하는 그 어려움과 모호함을 이 글이 조금이나마 해결해줄 수 있었으면 좋겠다.
