책 <현업 기획자 도그냥의 서비스 기획 스쿨>
정의
해외의 프로덕트 매니저와 하는 일이 비슷하다.
말 그대로 기획을 하는 사람
시대에 따라 필요한 능력들이 추가되면서 다양한 이름으로 불리곤 한다.
하는 일
UX와 비즈니스 모델까지 생각한다.
CGV, 네이버 앱 메인화면 사례
개발환경과 비용까지 생각한다.
씀의 임시저장, 자동저장 기능 사례
서비스 전체의 선순환을 생각한다.
원티드 연차 입력기능 사례
서비스 기획자의 관점은 단순히 불편에 머물러서는 안된다.
비즈니스 모델과 전략, 개발환경과 비용, 서비스 전체의 순환구조가지 고려하는 폭넓은 시각을 가지고 있어야 한다.
고객이 사용하는 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 설계
Last updated