[현업 기획자 도그냥이 알려주는 서비스 기획 스쿨] 전체 내용 요약
* 대체로는 챕터에 있는 내용을 그대로 가져갔지만, 일부 내용은 뒤에 있는 내용을 앞 큰제목 내용에 적은 것도 있습니다. 흐름상 그게 더 자연스러울 것 같아 임의로 위치를 옮겼으므로 읽으실 때 참고해주세요.
Chapter 1. 서비스 기획자는 뭐하는 사람일까
해외에는 서비스 기획자가 없다면서요? (서비스 기획자의 정의)
- 기획자의 뜻 ▶ 앞으로 할 일의 절차, 방법, 규모 따위를 미리 헤아려 계획하는 사람.
해외에서는 기획자라는 단어가 일대일로 매칭이 안될 뿐, 프로젝트 매니저/프로덕트 매니저 등으로 이해하면 된다.
서비스 기획자가 하는 일
- UX / 비즈니스 모델 / 개발환경과 비용을 고려
- 당장 눈에 보이는 페인 포인트에 집중하는 것이 아니라, 위 사항을 고려하여 전체적인 시각으로 보는 사람
어디에서 일할 것인가 (인하우스 기획자&에이전시 기획자)
- 에이전시 기획자는 주어진 목표와 일정 내에서 최선의 서비스를 만드는 사람으로, 다양한 프로젝트를 경험할 수 있고 전문화된 기획을 시도할 수 있다. 시간과 갑질에 쫓길 가능성이 높다.
- 인하우스 기획자는 시작과 오픈뿐만 아니라 유지 단계에도 참여한다. 또한 회사 내 다양한 잡무를 함께 처리할 가능성도 있다고. 하나의 프로덕트를 시작부터 끝까지 책임지고 이끄는 경험을 할 수 있다. 다만, 자신이 수행하는 결과에 책임을 져야 한다.
Chapter 2. 서비스 기획을 위해 알아야 할 것들
서비스는 맨땅에서 나오지 않는다 (비즈니스 전략과 서비스 기획)
- 서비스 기획은 단순 아이디어가 아니다.
- 경영 전략 이론을 기반으로 한 전략기획과 웹/앱 서비스 내에서 작동할 수 있는 시스템으로 설계한다.
- 이때 비즈니스 모델 캔버스를 많이 이용
- 서비스할 국가의 법적 규제를 미리 살펴야 함도 중요
서비스는 프로젝트에서 탄생한다 (워터폴 방법론과 애자일 방법론)
- 프로젝트는 적어도 "기획-디자인-개발-테스트-오픈"이라는 다섯 단계를 기획자/디자이너/개발자라는 최소 세 개의 직군이 함께하여 IT 시스템으로 서비스를 함께 만들어내는 협업 업무를 의미한다. (적고 보니 마피아 게임 같다.)
- 워터폴 방법론과 애자일 방법론. 둘 다 각자의 장단점이 있으므로, 상황에 맞는 방법 채택
- 워터폴: 기획안 > 디자인 > 퍼블리싱 > 개발 > 테스트 > 오픈 단계가 명확하게 계주 달리기 방식
- 애자일: 상위 기획 > 기획안 작성 > 디자인/개발/테스트 스프린트(1개당 2~3주)의 반복 > 오픈
현업부서에서 서비스 개선 요청을 받다 (서비스 운영 개발 요청서)
- 요청한 사람의 말만 보는 게 아니라, 왜 필요한지, 어떤 방식이 좋을지 반드시 질문하고 이해해야 한다
- 서비스가 커지고 조직이 세분화되면 각 조직별 핵심 성과지표(KPI)가 달라질 수 있으므로, 서로 상충 가능성 있음. 회사의 이익을 중점으로 우선순위를 정해야 한다.
- 만약 요청사항이 현재 불가능하더라도, 요청사항의 배경과 목표를 듣고 함께 대안을 찾으려 노력해야 함
UX 분석을 하고 서비스 전략을 세우다 (기획자 산출물 서비스 전략 기획서)
무작정 와이어프레임 드릉드릉 멈춰!
- 서비스의 완결성을 생각하자: "자사 IT 구조와 역량, 비즈니스적 이해, 고객의 UX에 대한 분석"
- UX 방법론에 따라 전략 세우기 필요 (페르소나, 트래킹 분석, 쉐도잉, A/B 테스트)
사용성 테스트나 현장 인터뷰를 통해 고객이 말하는 요청사항이 아니라, 그들이 표현하지 못하는 니즈를 발견해야 한다. 이는 고객뿐만 아니라 현업 부서의 요청사항을 처리할 때도 동일하다.
서비스 역기획
단순히 와이어프레임을 따라 그리는 것은 역기획이 아니다.
1. 비즈니스 모델 파악
2. 핵심 로직 분석: 데이터 가설 설정 및 검증. 어떤 데이터들이 어떻게 보이는가? 서비스의 프로세스 등을 정리한다.
3. 기업의 목표 분석: 기업의 목표와 전략을 조사 및 분석하여 자신의 의견을 덧붙인다.
Chapter 3. 프로젝트 실무에 돌입하다
서비스 전략이 프로세스 설계로 변하는 과정
마인드맵을 활용하여 필요한 기능과 데이터를 정의하면 좋다
[1] 어떤 기능이 필요한가, 어떤 데이터가 만들어지는가, 어떤 서비스가 이루어지는가에 대한 상세 정의
- 이때 데이터의 활용 기준도 함께 정의한다
- 법적으로 문제가 될 부분도 없는지도 함께 고려
[2] 내외부 사용자별 플로우 정리
- 고객과 현업 실무자 플로우 차트 필요
[3] 정보구조 작성 (IA)
- 프로세스 단위로 화면을 몇 개로 작업할지 확인하여 작업량을 산출하는 기준으로 마련할 수 있음
디자이너와 개발자는 이 기획에 대해 아직 관심도 없고, 기획자만큼 고민도 못해보았음을 전제로 한다.
중요한 부분들을 환기시켜 이 기획에 관심을 갖게 해야 한다.
이때, 디자이너와 개발사의 관심사는 다름을 인지해야 한다. 혹은 각각을 위한 버전을 따로 만드는 것도 방법이다.
프로세스가 설계에서 자주 하는 실수들 (기획자 산출물 : 마인드맵)
- 프로젝트 범위 내에 있는 기능만 적어야 한다.
- 그냥 적다 보니 생각난 "있으면 좋을 것 같은 기능"은 과감하게 빼야 한다.
- 지엽적인 하나의 경우가 아니라, 전체 케이스를 아우를 수 있는 카테고리를 정리해야 한다.
개발자와의 첫 커뮤니케이션 (기획자 산출물 : 요구사항 정의서)
- 개발자와는 초반부부터 많은 이야기를 나누는 게 좋다.
- 기본적으로 개발진은 기존 시스템으로 구현이 가능할지, 기존 시스템에 영향을 최소화할 수 있을지를 고려한다.
"에이 그거 조금 뭐 고치는 거 가지고..." (X)
- 기획자의 의도에 개발부서가 공감할 수 있도록 대화를 나누어야 한다.
- 개발부서와의 미팅이 불만족스럽더라도, 개발자의 질문이나 피드백만으로도 추후 기획해야 할 것이 무엇인지를 알 수 있다. 구체적인 서비스의 기술적 기능과 스펙이 구체화되어있다면 UI 설계로 넘어간다.
이제 UI 설계를 해봅시다 (기획자 산출물 : UI 설계 작업 - 스케치, 와이어프레임, 프로토타입)
- 러프하게 손으로 스케치하기
- 와이어프레임을 빠르게 만든다 (템플릿 사용하면 편하다)
- 프로토타입을 심플하게 만든다.
기획자 실력이 드러나는 종합 커뮤니케이션 세트 (기획자 산출물 : 화면 설계서와 사용자 스토리)
- 화면 설계서
- 수정 이력
- 기획 의도와 KPI
- 프로세스 플로우 차트
- 수정 및 신규화면 목록 + 화면 외 개발대상
- 와이어프레임 (목업)
- 디스크립션
- 사용자 스토리
(1) 사용자 스토리 맵
- 제목 (10자 이내)
- 사용자, 사용자의 목적, 서비스 목표
- 완성 기준
INVEST 고려
- “I” ndependent: 독립적
- “N” egotiable: 조정이 가능해야 함
- “V” aluable: 가치가 있어야 함
- “E” stimable: 측정 가능해야 함
- “S” mall: 충분히 작아야 함
- “T” estable: 테스트 가능해야 함
(2) 사용자 스토리맵
- 에픽 찾기
- 에픽 하위 사용자 스토리 간의 선후관계 정리
- 백로그 작성
Chapter 4. 프로젝트는 여럿이 함께
화면 설계에 장인정신은 필요 없다 (화면 설계서의 디스크립션 잘 쓰는 방법)
- 예외처리, 분기 처리, 정합성 체크
예외처리: 정상적이지 않은 예외적인 상황에 대해 대응할 수 있도록 처리
분기 처리: 한 개의 화면에서 발생할 수 있는 병렬적인 경우의 수에 대해 고려한다.
정합성 체크: 데이터 처리에서 규칙이 맞는지 검토. 폼 기입 정보, 필수 기입 정보 등.
서비스 기획자는 디자인을 얼마나 알아야 할까 (디자이너와 협업하기)
디자이너는 예민한 아티스트가 아니다.
- 디자인은 취향의 영역이 아니다
- 주류 사용자의 관점, UX적 관점, 개발적인 부분과의 연관성을 고려하여 의견 제안
- 프로토타이핑이나 개발 테스트를 하며 디자인이 수정될 수도 있으므로, 너무 처음부터 딱딱하게 정할 필요는 없음
서비스 기획자는 개발을 얼마나 알아야 할까 (개발자와 협업하기)
- 개발 용어를 모를 수는 있음. 그 용어가 무엇인지 반드시 묻고 대화를 풀어나갈 수 있도록 안건을 풀어나가야 함
- 개발 용어를 알고 있으면 좋긴 함 / 가장 좋은 건 실제로 개발부서와 부딪히며 활용해나가며 이해하는 것
기획은 재밌는데 테스트는 재미없다 (기획자 산출물 : 테스트 케이스)
- 오류가 발생하는 케이스가 재현될 수 있도록 정확하게 개발자에게 공유한다.
- 오류 상황에 대한 원인을 함께 이해하고 적절한 산출물을 정의하거나, 한계가 있다면 대안을 빠르게 생각한다.
- 다만, 오픈에 대한 최소 기준 정의가 필요 (MVP)
Chapter 5. 서비스의 탄생
서비스야, 건강하게만 자라다오 (서비스 오픈)
- 서비스 이용 교육도 기획자의 일 (간단한 공지, 튜토리얼 화면) / 내외부 인원 모두 포함
- 관련 부서, CS 부서 등에게 매뉴얼을 전달하는 방식 추천
결과에 쿨해지자 (‘린’한 서비스 개선)
- KPI 측정
- 추후 필요에 따라 퍼널 분석, A/B테스트, 피봇팅 등 고려: 린 UX에서 강조하는 개념을 잘 받아들이려면, 자신의 가설이 틀릴 수 있음을 항상 염두하고 빠르게 다시 시도하는 것이 중요
- 서비스 개선 제안 시, 사용자의 기준을 설정하고, 히스토리를 파악하는 것이 중요하다.
프로덕트 매니지먼트 수업을 듣고 난 이후로는, 과거엔 이해가 가지 않았던 것들이 눈에 보이기 시작한다. 처음 읽을 때는 마냥 재미있고 흥미로웠는데, 두 번째 읽으니까 이제야 이게 이런 의미였구나, 라는 게 느껴진다.