정의
•
해외의 프로덕트 매니저와 하는 일이 비슷하다.
•
말 그대로 기획을 하는 사람
•
시대에 따라 필요한 능력들이 추가되면서 다양한 이름으로 불리곤 한다.
하는 일
1.
UX와 비즈니스 모델까지 생각한다.
a.
CGV, 네이버 앱 메인화면 사례
2.
개발환경과 비용까지 생각한다.
a.
씀의 임시저장, 자동저장 기능 사례
3.
서비스 전체의 선순환을 생각한다.
a.
원티드 연차 입력기능 사례
•
서비스 기획자의 관점은 단순히 불편에 머물러서는 안된다.
•
비즈니스 모델과 전략, 개발환경과 비용, 서비스 전체의 순환구조가지 고려하는 폭넓은 시각을 가지고 있어야 한다.
•
고객이 사용하는 UI 를 고치는 기획자가 아니라 여러 방향에서 서비스 전체를 볼 수 있는 서비스 기획자가 되어야 함
서비스 기획자의 본질
•
문제없이 서비스를 구현하기 위해 필요한 모든 것을 할 수 있도록 만드는 것
•
UX 분석하여 얻은 비즈니스 이슈를 해결하고 구현해낸다는 것
서비스 기획에서 가장 중요한 것
•
문제해결
•
방법론 그 제체에 집중하기 보다는 해결책을 찾아가는 방법
구글의 스프린트
•
5일만에 프로토타입을 만들어서 실용적인 서비스 전략을 얻어내는 방법
•
1일 : 주제에 대해서 10명 이내의 관계자가 해결하려는 문제의 구조와 이면의 이슈들을 분석하여 핵심 주제와 타깃을 설정
•
2일 : 이에 대한 해결방식을 각자 스케치하고
•
3일 : 각자 아이디어를 내서 최적의 솔루션을 선정하고 서비스 흐름을 만들어본다.
•
4일 : 1-3개의 현실적인 프로토타입을 만들고
•
5일 : 4명의 타깃 고객을 대상으로 사용자 테스트를 진행하여 피드백을 얻는다.
순환구조의 중요성
•
아마존의 플라이 휠 전략
비즈니스 전략과 서비스 기획
•
서비스가 사용되는 시장과 환경을 고려하여 법률적인 검토도 필요
•
고민의 깊이가 중요하다.
워터폴방법론과 애자일
•
워터폴
◦
“기획-디자인-개발-테스트-오픈” 의 과정이 순차적으로 진행되는 방식
◦
한 단계가 끝나면 이전으로 돌아갈 수 없기 때문에 기획자는 신중하게 기획을 해야한다.
◦
장점
▪
프로젝트의 정해진 기간이 명확하다.
▪
제대로 기획되었다면 산출물이 좋다.
◦
단점
▪
유연성 부족
▪
기획자에게 요구되는 범위가 많음
◦
1950년대에 생겨나서 70년 넘게 사용되어왔으나 더이상 시대의 흐름을 따라갈 수 없게 됨
•
애자일
◦
2001년 켄트 백을 중심으로 개발자 17명이 애자일 선언을 하며 촉발한 사상적인 변화
◦
기존 워터폴 방식의 선형적인 프로세스는 빠르게 변화하는 IT 세상에 적합하지 않고 대안적인 프로세스가 필요함
◦
변화에 유연한 프로젝트 방법을 주창
◦
기획, 디자인, 개발이 처음부터 프로젝트의 팀원으로 함께 참여하여 서비스에 대한 이해도가 높은 상태에서 더 좋은 서비스를 만들자
◦
기획자는 사용자 스토리 백로그를 작성하는 것이 주요 업무가 된다.
▪
전체 서비스가 갖춰야할 고객의 목표와 핵심 결과를 사용자 목표에 따라 잘게 나눠 작성한 요구사항정의서
▪
디자이너와 개발자의 자유가 보장되어야 하며
▪
몇 개의 백로그를 합쳐 스프린트를 만든다. 하나의 스프린트는 2-3주
▪
Epik - Task - Sub Task
◦
기획자의 미션
▪
꿈꾸는 서비스에 대해서 더 많이 고민하고 그 고민을 프로젝트 팀원 모두에게 본인과 비슷한 수준으로 이해시키는 것
▪
모두의 사상과 목표를 합치시킬 수 있어야 한다.
방법론은 거들뿐 기획은 기획!
서비스가 내 자식 같으려면
•
전체 프로덕트가 지향하는 방향 안에서 주어진 미션을 완결성있는 서비스로 만들어야 한다.
•
서비스의 완결성은 고민의 깊이와 넓이에 의해 결정된다.
•
고민이란 자사의 IT구조와 역량, 비즈니스적 이해, 고객의 UX 에 대한 분석을 바탕으로 서비스 전략을 만들어내는 과정을 의미한다.
기획자가 가장 먼저 해야할 것
•
고객을 이해하는 것이다.
•
UX분석이다.
역기획법으로 기획 혼자 공부하기
기획자 vs. 오퍼레이터
•
기획자가 단순 반복되는 일을 하고 있다면 본인의 업무 태도를 점검해봐야한다.
•
오퍼레이터는 단순히 운영팀과 프로덕트팀 사이의 간극을 매우기만 한다.
•
서비스 기획자는 비즈니스 목표나 문제를 온라인 서비스를 통해 해결책을 제안하는 사람이다. 다만 고객의 사용자 경험과 자사의 시스템과 기술에 대한 이해를 바탕으로 실제 구현가능한 해결책을 제안해야 한다.
마인드맵 그리기
•
1단계 : 필요한 기능과 데이터를 정의한다.
◦
일단 필요하다고 생각되는 데이터 항목이나 기준을 생각나는대로 쓰고 정리는 나중에 하기
◦
첫째 : 서비스의 재료가 되는 기능과 데이터 생각해보기
▪
데이터, 기능, 목표 등 세가지로 구분해서 떠올리기
▪
예시
•
서비스 : 인근 미용실 지도
•
기능
◦
미용실을 지도에 표시
◦
지도위의 표시를 누르면 상세 정보를 보여준다.
•
데이터 : 미용실 상호, 미용실로고, 미용실 주소지와 좌표
◦
둘째 : 데이터 활용 정책 정하기
▪
10분 내외로 걸을 수 있는 200m 를 디폴트 값으로 한다.
▪
조회할 결과가 없다면 팝업으로 알림을 표시한다.
◦
셋째 : 서비스 운영과 관련된 제약사항 떠올리기
▪
법적인 문제소지 미리 검토하기
▪
서비스 이용자의 위치정보 활용 동의 필요
•
2단계 : 내부와 외부 사용자별 플로우를 정리한다.
◦
내부사용자(사내)와 외부사용자(고객)의 입장에서 처리될 플로우들을 정리한다.
•
3단계 : 정보구조(Information Architecture) 작성하기
◦
트리방식으로 정리되는 정보 구조 체계를 의미함
◦
페이지 정의
개발자와 협업하기
•
개발자와 만날때 가장 추천하는 방법은 요구사항정의서를 작성해서 리뷰하는 것
UI 설계