<이미준(도그냥)의 서비스 기획 무작정 따라하기> 후기
(IT 시스템 기획) 이벤트 기획하기, 후기를 빙자한 강의정리
본 강의는 '내돈내산'으로 참여한 강의이며, 강사님에게 허락을 받은 후 강의 내용을 정리하여 작성하였습니다.
날이 꽤나 추웠던 겨울, 그로스쿨(픗픗 아카데미)에서 진행한 <이미준 작가님의 서비스 기획 무작정 따라하기, 부제 : IT 시스템 기획하기>를 수강했다. 강의를 들으며 Notion에 개인적으로 정리를 하였기에 브런치에 글을 써야지, 써야지 하며 미루기를 차일피일, 이제서야 이렇게 후기를 빙자한 강의정리를 남겨본다.
What-Why-How가 명확한 강의
개인적으로 좋은 강의라 함은 수강자가 무엇(What)을 왜(Why), 어떻게(How) 배울 것인지 명확하게 하는 것이라고 생각한다. 이 강의는 명확하게 '왜 기획하는가-무엇을 기획하는가-어떻게 기획하는가'를 기준으로 진행되어 수강자 입장에서 좀 더 수월하게 이해할 수 있었다.
또한 강의는 온/오프라인 모두 참여할 수 있도록 현장 라이브를 송출하는 형태로 진행되어 코시국에 걸맞는 환경으로 진행되었다. 본 강의가 좋았던 점은 이론적인 내용과 그 내용을 토대로 실습을 진행했기에 단순히 이론을 배우는 데 그치지 않고 실습을 해볼 수 있어 좋았다.
Back-end 기획 과정을 살펴볼 수 있는 강의
강의 제목에서도 알 수 있듯 Back-end 기획을 위주로 강의가 진행되었다. Data, 정책, 뒷 단(Back office)의 기획 업무를 수행하는 Back-end 기획자 업무과정을 배울 수 있었다. 강의 초반부 강의자가 정리한 Back-end 기획은 아래와 같다.
1. UI가 나오기 전 정리해야 하는 것
2. 디자이너/개발자와 협업하기 위해 기획해야 하는 것
3. 시니어 기획자가 기획에 들어가기 전 머릿속에 가지고 있어야 하는 틀
실제 강의를 통해 위 3가지에 대해 어느 정도 기초적인 틀을 잡을 수 있었다.
본 강의는 이벤트 기획을 예시로 진행되었다. 강의에서 제시한 이벤트라 함은 '선착순 N명, 한정 특가, 구매 후 N분께 상품을 드립니다' 등의 것과 같이 클릭 등의 특정 행동을 통해 고객을 당첨-추첨하는 것을 말한다.
cf. 이벤트와 유사한 프로모션(Promotion)은 쿠폰 등과 같이 할인과 관련된 개념으로 이벤트와 명확히 구분한다
어떻게 하면 운영자가 원할 때 이벤트를 만들 수 있도록 시스템을 기획할 수 있을까?
실제 현업에서는 이벤트가 진행되면 개발자가 한 땀, 한 땀 개발을 하는 경우가 많다고 한다. 본 강의는 이러한 문제점을 극복하고 Admin에서 이벤트를 생성, 관리할 수 있도록 하는 시스템을 기획하는 과정을 다뤘다.
왜 기획하는가?
왜?를 고민하는 것은 곧 프로젝트 업무의 시작이며 동시에 프로젝트의 비즈니스적 의미를 찾는 것이다. 즉, 정말 이 시스템을 만들 필요가 있는지?에 대해 기획자 자신이 설득되어야 한다. 이러한 고민 과정은 개발자의 "그래서 왜 해야 하는데요?"에 적절히 답하고 설득할 수 있는 토대가 될 것이다.
정말 만들 필요가 있는 지 검증하는 방법
1. 회사 차원에서 해당 서비스의 전략적 중요도를 파악하기(Q.는 질문 예시)
- 차후 브랜딩 전략, 마케팅 전략에서 이벤트 사용 계획을 확인한다
Q. ~가 개발되면 얼마나 쓸 것 같아요?
- 현 시점의 이벤트 사용 현황을 파악한다
Q. 지금은 이벤트를 얼마나 자주 하시나요?
2. Operation 현업의 의견 청취 : Pain Point와 Needs 발굴
- 사용자(이벤트 수기개발에 질린) 관점에서의 불편사항을 수집한다
Q. 어떤 점이 개선되면 좀 편할 것 같으세요?
- 고객의 실제 불만을 청취한다(CS센터 불만 접수건수 파악).
Q. 이벤트 관련해서 고객이 가장 불만 있는 부분이 뭐에요?
3. 비즈니스 임팩트(Business Impact) 검증하기 : 현재 이벤트가 매출에 끼치는 영향
- PUSH에 의한 인입 구매전환 비율 조사하기
- 이벤트 평균 신청 건수 확인하기
- 트래픽 및 지표 변동 여부 추적하기(구매전환율, MAU)
- 경쟁사의 이벤트 횟수 조사하기(Ex. G-market의 On-site Marketing 현황)
Point 1. 기획자 스스로가 프로젝트가 정말 중요한 지에 대한 직관적인 판단이 있어야 한다. 리소스(Resource) 경합 중인 다른 프로젝트(Project)와 비교하여 지금 프로젝트의 가치를 판단해야 한다. 물론 프로젝트를 진행하지 않게 된다면, 그 이유 또한 명확해야 한다(대안, 리소스 부족 등).
4. 현재 운영 방식에서 발생하는 비효율을 수치화하여 측정할 수 있는지 파악하기
- 이벤트 하나를 제작하기 위한 프로세스 소요기간, 개발 공수, 진행 방식 등을 조사하여 수치화 한다.
Q. 기획부터 실제 이벤트가 시행되기까지 기간은 얼마나 걸리나요?
Q. 일정 조율은 어떻게 하시나요?
Q. 만들고 싶은 이벤트 유형이 무엇인가요?
Q. 지금까지 이벤트는 어떤 방식으로 진행됐었나요?
Point 2. 프로젝트 진행을 마음먹었다면 어떤 방식으로든 지금 느끼는 그 불편함을 해소해주기 위하여 노력하고 있다는 라포(Rapport)를 형성하라. 이후 협조 혹은 도움 받을 수 있는 상황에서 유용하게 작용할 것이다.
5. 시스템으로 개발(자동화) 시, 얼마나 많은 시간, 비용이 단축되고 매출이 증대할 지 기대치 파악하기
- 목표치에 따라 정보 효율과 매출 발생이 가능한 지, 업무 효율이 얼마나 증대될 수 있는 지 파악한다.
Point 3. 이 단계는 결정적인 진행 논리를 마련하는 데 과정이다. 이처럼 냉정한 분석을 통해 수치화 하는 것은 중요한 단계이다. 하지만 수치는 설득을 위한 기본 재료에 불과하다. 시스템 개선과 달리 KPI가 모호한 신규 시스템 개발에서는 이러한 수치 뿐만 아니라 기획자 본인의 직관 또한 중요하다.
모두가 앞선 단계를 잘 이해하고 수행할 수 있다. 그럼에도 불구하고 UI로 넘어가는 실수를 범한다.
1. 왜 이렇게까지 Detail하게 고민하는 걸까?
- 튼튼한 시스템은 곧 Scale 단계에서의 이용자 급증 Risk에 대응할 수 있는 토대가 된다.
- 명확한 Vision(목표)를 제시해야 자원 경쟁상태에서의 자원할당이 가능하다.
- 강의자는 J커브의 초기 단계와 Scale 단계를 비교하여 제시했다. 초기 단계(시작점)에서는 고객도 적고, 운영 인원도 적다. 따라서 기획, 개발, 디자인이 한 데 모여 한 가지 목표로 다같이 기획하며 초기이다 보니 이슈 대응에 대한 Risk도 적다. 하지만 Scale-up 단계에 돌입하면 급격하고 빠르게 늘어나는 이용자를 감당할 수 있는 튼튼한 시스템이 필요하다.
하워드 러브가 본인의 책 <The Start-Up J Curve: The Six Steps to Entrepreneurial Success>에서 제시한 스타트업의 성장 곡선Point 4. UI로 넘어가는 실수를 범하면 어떻게 될까?
1. 이벤트 페이지를 구조화하라는 말에 이벤트 페이지를 유형별로 캡쳐하고, 유형화한다.
2. 평소 해보고 싶었던 아이디어와 유형을 포함하여 와이어프레임(Wireframe)을 구성한다.
3. 현업에 UI(User Interface)로 리뷰하며 유형을 알려준다. 이 과정에서 현업에서 더 많은 요구사항과 아이디어를 제시한다.
4. 개발팀에 유형화에 대해 리뷰를 진행한다. 개발팀에서는 "운영할 Admin 정리해주세요"을 요청
5. 비슷하게 공개되어 있는 Naver, Cafe24 등을 참고하여 정리한다. 나름 사용 편의성을 위해 스텝도 나누고 Admin의 UI 개선을 위해 노력한다.
6. UI 기준 회의이다 보니, 몇차례에 걸친 개발팀과의 회의에서도 아이디어만 추가될 뿐이다. 더불어 디자인 및 UI에 대한 질문에도 명확한 답을 하지 못한다(타사에 있었는데요? 혹은 Front의 UI를 기준으로 답한다).
7. 개발이 시작되어도 Front와 Admin 간의 데이터 부족 혹은 부적절한 정책으로 인해 계속 추가 기획을 요청하고, 그 과정에서 점차 개발기간이 길어진다.
8. 결국 오가는 무수한 Deal 속에 프로젝트는 Drop 당한다.
EX) "등록은 어디서 하나요?"라는 질문에 답하기 위해 열심히 그려서 가면, 또 다시 "이건 어디서 하나요?", "이건 뭐보고 정리하죠?" 등 무수한 질문 사례를 받는다.
무엇을 기획하는가?
"왜 기획하는가?"에 대한 토대를 튼튼히 했다면 이제는 '무엇'을 기획할지 고민해야 하는 단계이다. 여기서 '무엇'이란 강의 목표였던 Admin 에서 이벤트를 생성, 관리 할 수 있도록 하는 시스템(System)을 말한다. 그렇다면 이 시스템이란 것은 무엇인지에 대해 알아보아야 한다.
우리의 비즈니스(Business)는 어떻게 운영(Operation)될까?
1. 온라인 서비스란?
- 입력된 행동이나 값에 대해 정해놓은 정책과 룰에 따라 정확한 Output을 산출할 수 있도록 하는 기능들의 집합(Template)
- Data의 Input-Output으로 구성된다(입력처-저장처-출력처)
- 서비스 내에서 Input-Output data를 기획하는 것이 화면 기획이다.
현재 회사에 적합한 시스템을 개발하기 위해 알아두어야 할 것들
1. 시스템의 구조
- Admin side-Data side-User Side
- 이벤트 운영, 특정 유형 노출, 이벤트 당첨 등을 위해 필요한 정보를 정의한다(Admin Side).
- 저장된 정보를 바탕으로 노출하는 방식의 로직을 정의한다(User Side).
- 템플릿의 URL 구조
- 템플릿이 여러가지여도 호출하는 URL은 1가지로 놓고, 내부적으로 이를 분리하여 노출한다
- 회사마다 다르다.
- DB(Data Base)구조의 차이
- 데이터베이스가 분화되어 구성되어 있으며 DB 간의 데이터를 불러오기 위해 API가 필요하다(MSA)
- 데이터베이스가 한 개로 구성되어 있으며 ERD(Entity-Relationship Diagram)를 보고 데이터를 보다 쉽게 활용할 수 있다.
MSA와 Monolithic 구조의 비교(출처 : https://kr.tmaxsoft.com/info/storyTView.do?seq=345, 티맥스소프트)2. 화면 구성 방식
- 유형별 예외처리 방식은 모든 유형을 개발하고, 필요한 정보만 노출하는 방식을 말한다.
- 반대의 방식은 유형별로 화면을 다 다르게 개발한 후에, 이를 유형별로 노출하는 방식을 말한다.
Point 5. 유형 1(예외처리 방식), 2(유형별 개발 방식)을 선택할 때, 노출되는 화면이 대동소이 할 경우 1의 방식을 채택하고, 그렇지 않을 경우 2의 방식을 채택한다.
3. 시스템화의 효율적 개발
- 효율적 개발을 위해서는 최소 범위 개발 후 스프린트 단위의 개선을 수행해야 하며 크게 2가지로 나뉜다.
- 유형을 확장성 있게 구조 내에 추가하는 방식(저장정보가 한곳에 있음)은 최소단위 개발 시 유형의 확장 가능성을 사전에 협의해야 한다. 또한 유형 추가 시에는 기존 유형에 영향/이슈가 없는 지 전체적으로 체크가 필요하다(Migration)
- 유형을 만들 때 마다 새로 똑같은 구조를 만드는 방식은 개발기간이 짧을 수는 있으나 유형이 다양해지면 한계에 다다를 수 있다.
어떻게 기획하는가?
앞서 왜(Why)의 과정에서 개발의 토대를 튼튼히 하고, 무엇(What)의 과정을 통해 회사에 알맞는 시스템에 대해 고민을 마쳤다면 이제 본격적으로 어떻게 만들지 고민해야 한다. 이 단계에서는 강의자가 제시한 미준맵을 활용해 순차적으로 기획을 진행할 수 있다.
1. 조사한 내용을 바탕으로 서비스의 목적, 목표, 사용자 니즈, 데이터 및 구성요소, 정책 정리하기
- 우리 회사에 필요한 것에 집중하기 위해 아는 정보에 대해 모든 것을 나열한다(정책, 현업, 이용방식 등)
- 나열한 모든 정보에 대해 시스템 내에서 입력될 수 있는 데이터와 필요 정책을 정리한다(시스템화 기초)
2. 사용자(User)를 중심으로 프로세스 나누기
- 사용자를 정리하고, 데이터 입/출력을 기준으로 선행되는 Process를 정리한다.
- 순서에 따라 Process를 정리하며 각 사용자(User)의 추가적인 니즈를 고려해 추가한다.
3. 나눠진 프로세스를 화면 기준으로 정리하기(개발 페이지 목록)
- 업무별로 하나의 화면에서 처리할 수 있다면 화면 단위로 구분한다.
- Admin과 Front는 선형 관계가 아니라, 동시다발적 Data의 N:M 관계임을 알고 추가 정책을 정리한다.
(천번을 출력해도 똑같이 출력되는 Logic 정의)
- 대략적인 페이지 기준의 IA를 정리한다(페이지 분리 여부는 개발팀과 협의)
강의를 진행하며 수강자와 함께 작성한 미준맵의 일부
4. 설명할 수 있을 정도의 Flow chart를 정리하기
- Logic에 대한 Flow Chart는 행동이 아닌 Logic과 Data의 흐름 관점으로 정리한다.
5. 스케치와 Wireframe, 그리고 Mock-up
- 협업자들과 싱크를 맞추기 위한 목적을 잊지 말자
- UI적 문제 해결을 위해 스케치를 작성한다면, 여러가지 버젼의 스케치가 필요하다
- 문제 해결이 필요하지 않다면 UI는 디자이너에게 위임하자(디자이너는 디자이너에게, 개발은 개발자에게)
- 요구사항의 싱크를 맞추기 위해 Wireframe이 중요한 경우도 있다.
Point 6. Admin 화면의 UI 설계 시에는 업무 순서와 영향관계, 저장시점 등을 정의해야 한다. 이때 업무 순서에 관해서는 화면의 좌측에서 우측(L->R)으로, 영향 관계에 있어서는 위에서 아래로(U->D), 저장시점에 대해서는 즉시 저장 또는 최종 저장 등을 주의해야 한다.
6. 자, 이제 협업자와 리뷰를 하러 가보자!
서비스 기획안, PRD
이제 진짜 프로젝트를 시작할 단계가 되었다. 이 단계에서는 "프로젝트를 어떻게 세팅할 것인가"에 대해 고민해야 한다. 앞서 정리한 내용을 토대로 조직의 특성에 맞추어 서비스 전략 기획안 혹은 PRD(Product Requirement Document)를 작성한다. 이 단계 이후에 이르러서야 비로소 Waterfall, Agile 등이 시작되는 것이다.
Point 7.
서비스 전략 기획안을 활용하는 경우, 주로 Waterfall(폭포수) 방법을 활용하며 기능별로 팀이 구성되어 있다. 보고의 느낌이 강한 문서이다(전략팀에서 "OO"라는 미션을 제안, 정리 후 보고)
PRD를 활용하는 경우, 목적 조직으로 구성되어 있다. 이 때 PRD는 Product팀 내에서 지속적으로 공유하고 싱크를 맞추기 위한 성격이 강하며(공유), 때로는 수정을 하기도 한다.
강의를 수강한 지 어언 반년이 지나서야 이렇게 후기(?)를 남기게 되었습니다. 강의를 수강하면서도 강의 자료가 없다보니 적으랴, 들으랴, 이해하랴 집중력을 많이 요했던 기억이 납니다. 아무쪼록 본 강의 정리 내용이 다음 수강하시는 분께 도움이 되었으면 하는 바람입니다 :)
실제 강의 녹화본(아래 링크)에 담긴 좋은 내용에 비하면 아주 모자란 부분이 많으니, 관련하여 보다 자세한 정보를 원하시거든 강의를 수강하시기를 추천드립니다(여담으로 그로스쿨에서 정말 다양한 강의를 많이 진행하시더라구요)
https://groschool.kr/category/business/course/service-planning-training
더불어 좋은 강의를 제공해주신 @도그냥 강사님께 다시 한 번 감사드립니다. 강사님을 포함 혹시라도 제가 잘못 적은 내용이 있거든 편하게 댓글에 남겨주시면 감사드리겠습니다.
그럼 오늘도 긴 글 읽어주셔서 감사드립니다.
