서비스 기획, 취준생일 때 보이지 않았던 것들 2탄
2탄: 기획자의 업무와 역량에 대하여
오늘 준비한 글은 기획자의 업무와 역량에 대한 이야기입니다.
물론 역량 부분은.. 저희도 아직 갖추지 못한 부분이 많이 있는 것 같네요..
그래도 언젠간 갖출 수 있을거라 믿습니다..ㅎㅎ
1. 서비스 기획자가 현재 하고 있는 일은?
체리 : 난 이론에 대해서 설명해볼게! 서비스 기획은 Product Management Cycle이라고 불리는 이론에서 아래 단계들이 있다고 생각해. 물론 현실은 아래 단계들이 꼭 step by step으로 흘러가지 않지만..!
[1단계] 시장 분석 및 리서치: 처음에는 개선 또는 새로운 서비스가 나오게 되는 페인포인트 또는 서비스의 시장 상황을 분석하고, 그 후에는 본격적인 서비스의 구체적인 설계를 시작해.
[2단계] 기획: 페인포인트를 기반으로 이를 개선할 수 있는 설계를 진행하는데, 이 때에는 구체적인 화면이나 플로우차트 등의 도구를 통해서 개선점을 잘 보여줄 수 있으면 더 효과적인 설계를 할 수 있어.
[3단계] 디자인 및 개발: 설계가 완성되면 디자인과 개발을 통해 실제로 서비스가 만들어지는 과정을 거쳐.
[4단계] QA: QA 단계에서는 서비스가 잘 동작할 수 있을지 여러 테스트를 거쳐 실제로 서비스가 바깥 세상으로 나왔을 때 사용자들이 불편 없이 사용할 수 있도록 점검을 할 수 있어.
[5단계] 서비스 배포 및 진단: 그 후엔 서비스를 런칭하고 서비스가 잘 사용되고 있는지를 점검해. 점검하는 단계에서는 VoC 또는 데이터를 활용해서 실제로 고객의 페인포인트가 해결되었는지를 확인할 수 있어.
Product Management Cycle 의 단계들레몬 : 난 실전에 대해서 덧붙일 수 있을 것 같아.
서비스 기획자는 서비스 내의 어떤 기능을 어떻게 제작/개선해야할지, 정책(=운영 규칙)과 스펙은 어떻게 가져가야할지 등을 설계하고 의사결정해. 이 과정에서 기획자는 모든 유관 부서와 커뮤니케이션을 하고 프로젝트를 이끌어가.
대략적 과제 진행 과정은 아래와 같아.. *항상 이런건 아님!
1) 일단, 기획자는 어떤 과제를 시작하기 전에 사업, 영업팀으로부터 유저 보이스, 사업 계획 등을 듣게 돼.
2) 그리고 나면 서비스 기획자 입장에서 신규 진행 혹은 개선해야하는 서비스 영역이 무엇인지를 판단해.
3) 이 과제를 본격적으로 진행하기 전에 필요하면 법무검토를 받고(법적으로 괜찮은지 체크), 배포하고자 하는 주기의 과제 리스트에 올리고, 과제 선별회의를 통해 과제를 선별한 후 일정을 결정해
4) 과제 진행 초안을 작성하여 팀 내부 공유를 진행하고
5) 개발팀과 기술적 구현 가능성(이렇게 할 수 있는지, 하기 위해 공수는 얼마나 들지 등)을 체크해
6) 본격적으로 과제가 진행되면, 상세 설계서 작성 후
7) 개발, 디자인, QA팀, UX writing팀과 설계를 공유하고 피드백을 받아
8) 피드백을 반영하고 수정하고 반복하며 설계를 마치면
9) 개발, 디자인이 작업을 하고 QA를 진행해 (중간 중간 이슈가 없는지, 과제 진행 상황은 어떤지 체크하는 건 기획의 몫!)
10) 테스트를 위해 사내 환경에 먼저 배포하고, 버그가 있다면 fix한 후 리얼(=일반 유저도 쓸 수 있도록) 서버에 배포하면 완료!
2. 서비스 기획자가 되려면 어떤 역량이 필요해?
*아직 글쓴이들도 역량을 갖추지 않고 있음 주의..ㅎㅎ
2-1. 개발할 줄 알아야해?
체리 : 결론만 이야기한다면 NO.
개발지식은 미리 준비하는 것보다는 입사 후에 개발이라는 넓고 방대한 학문에서 narrow down하고 본인에게 필요한 실용적인 지식만을 추가적으로 공부하면 된다고 생각해. 난 아무것도 모르고 들어왔는데 눈치껏 용어의 의미도 파악했고 나에게 필요한 분야의 개발 지식을 일을 하면서 쌓아서 개발에 거부감도 덜하고 일과의 시너지도 올릴 수 있었어.
레몬 : 개발할 준 몰라도 개발지식은 있어야한다.
업무 by 업무. 나는 개발과 밀접한 서비스를 기획하기 때문에(서비스 사용 대상이 개발자) 개발지식이 없으면 일을 할 수 없어 (ex. API가 뭔지, Callback은 뭔지). 어쨌든 IT 서비스 기획자라면 개발할 줄은 몰라도 개발 지식은 알아야 일하기 편해. (항상 개발자랑 회의하기 때문!) 결국 우리가 만든 서비스는 코드로 구현되는거니까. 예를 들어, 프론트엔드와 백엔드가 무엇인지, 각각 어떤 역할을 하는지. 어떻게 대량의 사용자가 하나의 서비스를 이용하고 그 과정에서 어떤 일이 일어나는지 등은 알아야 해. 기획자의 업무에는 서비스에 이슈가 발생했을 때 원인을 파악하는 업무도 있는데, 원인이 개발과 밀접하기 때문에 어느정도는 개발 지식을 알아야 편해. 추천 콘텐츠 : 무료 강의로는 ‘이고잉’이라는 분이 운영하는 ‘오픈 튜토리얼스(생활코딩)’ 사이트의 웹 서비스 강의 시리즈를, 유료 강의로는 ‘노마드 코더’의 기초 클론 코딩 시리즈를 추천
모과 : 개발자와 직접 커뮤니케이션하는 직무인 만큼, 개발에 대한 지식은 언제나 플러스 요인이 될 수 있어. 하지만 여기서의 ‘개발’은 ‘코딩(coding)’과는 전혀 다른 개념이야. 기획자는 직접 코드를 작성하는 사람이 아닌, 개발자에게 서비스를 어떻게 만들어내야 하는지에 대한 명확한 가이드라인을 설계하는 사람이야. 그렇기 때문에 오히려 정보 구조나 프로그래밍 아키텍쳐 등 실제 서비스를 설계하는 데 필요한 전반적이고 이론적인 내용들이 서비스 기획자로서의 역량 향상에 더 도움이 되어줄 수 있어.
2-2. '커뮤니케이션 능력' 많이 강조하는 건 아는데, 도대체 무슨 커뮤니케이션을 해?
레몬 : 기획자는 일 하는 과정에서 사업, 영업, 디자인, 개발, QA, 때로는 법률 팀과도 폭넓게 연락해야해.
기획자의 커뮤니케이션에는 주로 다른 팀에게 업무를 요청하거나, 기획이나 스펙에 대해 설명하는 유형이 많다고 생각해. 그렇기 때문에, 내 말의 목적이 뭔지(=이걸 왜 요청하는지), 이걸 왜 해야하는지, 이걸하면 뭐가 좋은지에 대해 설명해야 하는 상황이 많아. 미니 창업가 같은 느낌도 들어 ㅎㅎ
좀 더 일상 업무 측면에서도 보자면, 주로 개발자와 커뮤니케이션을 해. 서비스에 문제가 생기면 기술적인 원인이 무엇인지 물어보기도 하고, 버그가 있다면 버그 개선 요청을 하고, 통계를 위해 서비스 데이터를 추출해 달라고 하기도 하고! 같은 팀 사람보다 더 자주 얘기하는 것 같아. 개발자들도 역으로 기획자에게 이건 이렇게 동작되는게 맞나요? 와 같이 서비스 스펙에 관련된 질문들을 해
2-3. 또 무슨 역량이 필요해?
레몬 : 요즘 들어 정말 느끼는건데, ‘문해력’이 진짜 필요하다고 생각해. 서비스스펙과 정책에 관한 글을 정말 많이 읽게 되더라구. 짧은 메신저든, 긴 메일이든, 더 긴 사내 문서든 어쨋든 글을 읽고 이게 무슨 소리인지 단시간에 파악해야하는데 이때 문해력이 많이 필요하다고 느꼈어.
그리고 주니어때는 벤치마킹을 정말 많이 하게 되는데, 이때 타사 제품의 스펙, 공식 문서같은 걸 많이 읽어야하거든. 어떤 날은 몇십개의 웹사이트 글을 읽게되기도 해. 그땐 어떤 기분이냐면, 평소에는 거들떠 보지도 않는 기계 사용 설명서 같은 걸 몇십개씩 정독하는 느낌이야… 하지만 해야 하는 일이기도 하고, 결국 나도 그런 문서를 작성하게 될 수도 있어. 그래서 문해력이 꽤나 중요한 역량이라고 느껴! 근데 이건 어느 회사를 가도 필요한 능력이지 않을까 싶긴해.
