KDT 데이터 분석가 과정 9주차 (서비스 기획)

휸하엘레나킴·2021년 9월 15일

패캠 데이터 분석가 과정 (feat. 국비지원)

목록 보기

13/13

서비스 기획 - GA (21.09.15 - 21.09.27)

기획

일본식 조직구조 + 미국식 업무 진행
기획부서 내 팀원, 프로젝트 발주 및 검수, 프로덕트 책임자/설계자, 프젝트 관리자

기획자간의 구분

① 사업기획/전략기획	② 서비스(Product)기획	③ 서비스 구현 프로젝트	④ 마케팅 기획/사업 운영 기획
시장 기획 분석	서비스 구조, 프로세스	상세 정책 기획	홍보/프로모션
수익 모델 분석	운영 프로세스	디자인 / 개발	운영 개선
	성장전략 / 데이터분석	테스트 / 오픈	Growth hacking

사업/전략 기획자 + 전략 컨설턴트 :①②
서비스기획자 / Product Manager : ①②③④
운영 서비스 기획자 / UX 기획자 : ②③
마케팅 / 사업 운영 기획자 : ③④

비즈니스에 따른 구분

Inter Service	B2B Service	B2C Service
ERP나 Admin, 사내 커뮤니티, 메신저 등	고객은 다른 기업, 사용자는 고객사 내 정의	고객 및 사용자가 개인
사내 비즈니스를 위한 내부 사용자들을 위한 서비스	고객사의 입장과 사용자의 입장이 다를 수 있음	가장 많은 서비스 형태
모든 기업 내 존재	Admin도 고객사용이 따로 있을 수 있음	B2C service를 운영하기 위한 Inter Service가 포함 됨

오프라인Vs온라인 서비스

오프라인	$\leftarrow$ Digital Transformation $\rightarrow$	온라인
물리적인 프로젝트 진행 `건설 프로젝트`		디지털 환경에서 IT기술로 구현되는 프로젝트 진행
이용자에 대한 추상적 타겟팅		이용 흐름을 기반으로 한 행동 타겟팅
마케팅 깔대기 이론		데이터화 된 실질적 성과 확인 가능
서비스와 고객 생활의 분리		서비스와 고객 생활의 융합
접객 서비스의 발달(영업)		UI의 발달과 UX의 중요성 강조

서비스 기획자의 역량

Tech
User Centered Design
Business Model
Product Managing 방향성 분석과 Pivoting
Growth hacking을 위한 데이터 분석
Project Managing

프로젝트 상황에 따른 기획자 구분

상위 기획	서비스 구축	운영 기획
사업 기획 후 컨설팅	그랜드오픈 구축 프로젝트	운영 개발건
리뉴얼을 위하나 리서치	스타트업 구축	운영 중 추가 프로젝트 건
프로세스 개선 위한 리서치 컨설팅		리뉴얼 프로젝트 건
$\downarrow$	$\downarrow$	$\downarrow$
UX LAB, UX리서치&컨설턴트	상위기획자, 구축 에이선시 기획자(SI), 프리랜서	운영 기획자(관리기획/실무기획), 운영 에이전시 기획자(SM), 인하우스가 많음

인하우스Vs에이전시

인하우스	에이전시
내부 데이터 접근 가능	프로젝트 경험 빠르게 증가 (다양항 도메인 경험)
UX 개선 실무 가능	UX리서치 절차 등 경험 가능
프로덕트 발전시 만족도 높음	프로덕트 최초 오픈 시 만족도 높음
기획 능력 평가 후 입사	구축기획 능력 키워주는 환경
단점 : 한가지 프로덕트 매몰, 회사 상황에 따른 조직환경	단점 : 마이크로 UX 관리 및 경험 부족, 프리랜서 형태의 조직 구성

Product(서비스)와 Feature(기능)

product : 고객에게 가치를 주는 아이템, 정보 소스, 툴, 환경 또는 서비스.
feature : 프로덕트 안에 포함된 기능.

입사 후 Product(서비스) 체크 사항

기존 운영 프로덕트 참여 시에는 프로덕트/서비스를 빠르게 파악한다.
아래의 모든 항목을 다 보유하지 않았을 수 있다.
1. 프로덕트/서비스의 형태와 개수 : 어느 채널/소프트웨어에 접속이 가능한지, 운영체계 등.
2. 정책서 또는 위키 : 모듈 단위 어취 정의와 정책 정의, 상태값과 케이스 파악, 운영 기조 확인.
3. Information Architecture(IA) : 화면의 목록 확인, 전체 시스템의 복잡도나 운영화면에 대한 파악.
4. 화면 설계서(스토리보드/SB) 또는 User Story : 각 화면 단위 기능 및 구조 확인, 특이사항 예외케이스 등 정책의 구현 확인.
5. Business Intelligence(BI) : 데이터 접근 권한 확인, 수집 가능 데이터와 KPI 확인, Data Science 인력과 접근 범위.
6. 디자인 가이드 : 컬러 레벨과 텍스트 레벨, 일부 공통 UI 및 인터렉션 가이드
7. 협업 담당자 및 각 팀의 KPI : 기획/디자인/개발/테스트 등 유관 부서와의 R&R 확인, 모듈 단위 핵심 질문 대상자(개발 담당자) 확인, 테스트 업무 R&R과 관리 방식 확인.
8. 배포(DevOps/반영) 프로세스 : 테스트 서버 종류, 빌드와 배포 일정, 담당 부서와 긴급배포 협의자.
9. 결재/품의 절차 : 각 팀간 협의 시 결제 및 품의 절차와 문서, 결재 시 유관부서 공유 등 사내 정책 확인.

신규사업

아이디어 개발

경영전략 방식	Venture Innovation	✔Creative Innovation
지속가능 경영과 경쟁력	VC/Startup 투자	User Centered Design
생존을 위한 신사업	Open Innovation	Lean startup
$\downarrow$	$\downarrow$	$\downarrow$
현재의 핵심사업의 역량을 기준으로 하여 확장, 수익구조 답습 (롯데의 알미늄, 웅진의 방문판매)	VC의 60% 기업이 파산 (벤처 Vs 스타트업)	고객의 Pain Point 관찰, 비즈니스 모델 구축

스프린트 방식

구글 벤쳐스의 스프린트 방식

과제 $\rightarrow$
지도/그리기&타깃 선택 $\rightarrow$ 서로 경합을 벌이는 솔류션들 스케치 $\rightarrow$ 가장 좋은 솔루션 결정 $\rightarrow$
진짜 같은 프로토타입 제작 $\rightarrow$ 표적 고객과 테스트 $\rightarrow$ 학습

비즈니스 모델

수익구조

수익구조가 없어 적자를 볼 수 있다.
자금이 떨어져 투자로 매꿔서 회사를 운영하는 경우.
수익성 증명이 불가하면 추후 투자 유치가 어렵다.
따라서 비즈니스 모델을 통해 어떻게 돈을 벌 것인지 계획해야한다.

비즈니스 모델

고객 가치 제안
- 타켓고객
- 해결해야 할 일
- 제공할 상품과 서비스
수익 모델 공식
- 수익모델 : 수익창출 방식
- 지속 가능한 이익 모델 : 이익률, 원가구조, 자원회전율, 총 투입 대비 총 수익(비용구조), 성장/탈출 용인
핵심 자원
- 인재, 기술과 제품, 기기와 설비
- 정보(DATA)
- 유통 경로, 파트너십 또는 제휴
- 브랜드
핵심 프로세스
- 서비스 프로세스
- 규칙과 평가 기준
- 최저 기준

서비스 프로세스

서비스가 작동되기 위해서는 구체적인 서비스의 이용 프로세스와 데이터적 프로세스가 필요하다.

기존 비즈니스 프로세스를 분석하여 습득하고 유형화.
지금 설계하는 서비스에 어떤 프로세스가 적합한지 대응하며 구조를 설계.

조직 구성과 KPI

영업/정산 : 계약진행, 입점사 관리, 상품등록/검수, 정산/마감
마케팅 : 전시 관리, 회원 관리, 광고/제휴
CRM : 이메일, PUSH, 개인화추천
시스템 관리 : 실시간 로그 분석/관리, 트래픽 관리

$\Rightarrow$ 큰 비즈니스 모델의 목표 속에서 서비스 운영을 위한 조직과 각 조직이 지향하는 KPI를 설정 또는 이해하는 것. 세부 정책의 방향성 설정의 기준이 된다.

성장전략

서비스의 생애주기

Product development $\rightarrow$ Intoduction $\rightarrow$ Growth $\rightarrow$ Maturity $\rightarrow$ Decline

온라인 서비스도 Product이기에 제품수명주기에 따른다.
각 단계에서 적절한 서비스 전략을 구성해야 한다.

개발 단계

빠르고 도전적인 MVP(Most viable Product)를 개발한다.
그러나 성장을 위한 데이터 전략이 필요하다.

서비스의 등장과 성장 단계

선순환 구조 (Virtuous cycle)
서비스 핵심 프로세스를 지속적으로 강화시킬 선순환 구조로 성장을 견인 네트워크 효과

플랫폼이란?

온라인 서비스 플랫폼은 개방성과 매칭을 전제로 한 거래의 장을 지향하며, 네트워크 효과를 통해 높은 트래픽을 이푸어 생태계를 확장한다.

온라인 서비스

온라인 서비스의 구조와 기획

온라인 서비스는 데이터의 입력과 출력의 구성.
서비스 내에서 입출력할 데이터를 기획한다.

기획 템플릿

온라인 서비스란 함수처럼 입련된 행동이나 값에 대해서 정해놓은 정책과 룰에 따라 정확한 아웃풋을 산출할 수 있도록 만들어진 기능들의 집합.
템플릿이란 각 페이지 단위로 룰을 정해놓은 것을 의미.
룰이란 규칙 없이 임의로 출력값을 고정 시켜놓은 경우는 'hard coding'이라 한다.

서비스 레벨과 화면 레벨

판매 상품 Admin 등록 : 판매자 등록, 상품정보 등록, 상품 재고 관리
$\downarrow$
상품 전시 : 카테고리 상품 리스트, 검색결과 리스트, 상품상세 페이지
$\downarrow$
주문하기 : 주문 페이지, 주문조회 페이지

서비스 레벨에서 정의되는 데이터 입출력과 실제 서비스를 구성하는 화면 레벨에서의 데이터 입출력을 구분한다.
화면 레벨에서 출력하려는 데이터에 따라 다르게 화면 내용이 정의되도록 만든 화면을 '템플릿'이라 한다.

웹/앱 서비스

구분	PC웹	모바일 웹	네이티브 앱
기본 인터렉션 도구	마우스	손가락 터치	손가락 터치, 각종 센서
인터렉션 종류	클릭, 마우스오버, 휠	제스춰(Tap, Swipe, Drag...)	제스춰(Tap, Swipe, Drag...)
데이터 로딩 단위	페이지 이동 / AJAX	페이지 이동 / AJAX	모듈 단위 로딩
주요 구성	F형 UI 패턴	I형 UI 패턴, 컨텐츠 분할 로딩	I형 UI 패턴, 컨텐츠 분할 로딩

반응형 웹과 적응형 웹

반응형 웹
화면의 가로 크기에 따라 계속 다른 UI 형태를 보여주는 퍼블리싱 형태.
적응형 웹
기준 가로 크기에 따라 2~3벌의 퍼블리싱 형태로 보여주는 웹
Landscape, Portrait
UI 재조정 여부, 혹은 비회전여부 결정 필요.

네이티브 앱과 하이브리드 앱

웹 앱 : 앱 안에 브라우저를 넣은 것.
- 장점 : 상대적으로 기간 및 비용이 저렴하다. 단말기의 기종에 관계 없이 모든 단말기에서 같은 콘텐츠를 볼 수 있다. 유지 보수가 쉽다.
- 단점 : 카메라, 음성검색과 같은 스마트폰의 기능은 사용할 수 없으며 기능상 제약이 많다. 앱스토어에 등록 및 판매가 불가하다. 앱을 다운로드 하는 것이 아니라 검색이나 주소 입력 등의 과정을 거쳐야한다.
하이브리드 앱 : 웹 뷰를 넣은 앱. 네이버, 다음, 크롬 등
- 장점 : 카메라, 음성검색 및 인식 등의 스마트폰 기능을 사용할 수 있다. 유지 보수가 간단하다.
- 단점 : 네이티브 앱 보다 UI를 구성하는 디자인 부분이 취약하여 속도가 느리다. 기증적인 접근에 제한이 있으며 앱의 성능이 떨어진다.
네이티브 앱 유튜브, 인스타그램, 페이스북 등
- 장점 : 앞의 두 종류보다 실행 속도가 가장 빠르며 안정적이다. 스마트폰의 기능은 물론 2D, 3D 증강현실 등의 기능도 활용할 수 있다.
- 단점 : 제작이 어려우며 제작 기간 및 비용이 상대적으로 많이 든다. 운영체제에 맞춰 따로 제작해야 한다.

프로젝트 방법론

폭포수

폭포수 방법론은 1950년대에 처음 언급된 소프트웨어 개발의 표준 방법이다.

장점

단계가 명확히 구분되어 있어서 정확한 진척률 확인이 용이하다.
단계별로 책임 소재가 명확하다.
프로젝트 인력에 산출물 기준이 명확하여 Push를 잘 하는 조직에서는 오히려 오픈 일정을 맞추기에 적합할 수 있다.
산출물 문서가 명확하여 관리에 용이하다.
외주 인력과 작업하기 용이하다.

단점

앞의 단계에서 잘못된 기획이나 설계가 되었을 때 되돌리는 것에 굉장히 오랜 시간이 걸린다.
앞 단계의 문서에 명시되지 않은 부분에 대해 누락되기 쉽고, 기획 변경 시 영향 범위가 넓다.
테스트 기간 전까지 산출물의 형태를 미리 보거나 테스트하기 어렵다.

$\Rightarrow$ 애자일 방법론은 긴 시간 폭포수 방법론을 사용하며 문제를 개선하기 위해 등장한 방법론이다. 따라서 폭포수 방법론의 각 프로젝트 진행단계의 업무를 정확히 알지 못하는 상태에서 애자일 방법론만 학습하면 프로젝트 자체를 이해하기 어려워진다.
$\Rightarrow$ 단기간에 동일한 산출물을 만들려면 애자일 방법론보다 폭포수 방법론이 더 빠를 수도 있다.

애자일

2001년 켄트 벡을 중심으로한 개발자 17명이 애자일 방법론을 선언하여 촉발.

기존 폭포수 방법론의 선형적인 프로세스가 매우 빠른 IT 시장에서 적합하지 않다고 판단하여 등장한 대안적 방법론.

사전 문서 준비보다 실제 개발을 작은 스프린트 단위로 잘라서 실제 개발과 테스트를 통해 프로덕트의 기획과 검토를 여러 번에 걸쳐서 하는 방법론.

애자일의 4가지 핵심 사상

절차와 도구를 넘어선 개성과 화합.
종합적인 문서화를 넘어선 동작하는 소프트웨어.
계약과 협상을 넘어선 고객과의 협력.
계획 준수를 넘어선 변화에 대응.

장점

문서화 시간을 단축하고 개발된 산출물을 빠르게 만나볼 수 있다.
중간 단계에서 변화하는 기획을 수용하여 빠르게 변화할 수 있다.
개발자와 디자이너의 자유도가 높아 창의적인 결과를 가져올 수 있다.
과정 내내 팀원들과 많은 협의를 통해 최고의 산출물을 만들어낼 수 있으며, 개발자와 디자이너와의 끈끈한 협업이 가능하다.

단점

복잡한 프로젝트에 참여자의 수준이 제각각이면, 전체적인 진척률과 수준을 관리하기 어렵다.
참여자들이 애자일 사상에 대한 공감이 없는 상태에서 출발하면 상호간의 R&R 문제로 번지기 쉽다.
팀과 밀접하게 움직여야 하기 때문에 애자일 전문가 역할이 필요하고 전체적인 사상과 팀웍 관리가 필요하다.

$\Rightarrow$ 개발 결과물을 받아보는 시점 자체로는 빠르다고 할 수 있지만, 프로덕트를 만들기 위해 이러한 스프린트를 여러 번 거쳐야 한다.
$\Rightarrow$ 스프린트간 검토 과정에서 지나치게 많은 기획 변경이 일어나고, 개발자와 디자이너가 너무나 많은 실험을 반복한다면 애자일 방법론도 느릴 수 있다. 협력과 많은 대화를 통해 이러한 부분에 대해 상호간의 이해가 선행되어야 한다.

협업과 커뮤니케이션

프로덕트 개발 진행 후 서비스를 운영하면서 직접 사용하거나 활용해야하는 업무자를 이르는 업계의 슬랭.

마케팅 담당자, 영업 담당자, CS 처리자 등등 프로덕트의 개선을 요청하거나 관계가 있는 모든 관련자.
Admin 서비스의 내부 사용자에 해당. (인하우스 기획 입장.)

현업 요청의 유형

업무적 목표를 위한 시스템적 의견 요청.
업무 중 시스템의 불편 사항 접수.
타사 서비스 캡쳐에 그림까지 있는 형태.
와이어프레임 수준의 UI와 설명까지 있는 형태.
외주 기획의 입장이라면 RFP(Request for Proposal)나 요구사항 정의서의 형태로 수령

현업과의 협의

요청된 UI는 수단일 뿐, 근본적인 목적을 파악하여 대안을 제시한다.
꼭 개발을 해야만 하는 것이 정답은 아닐 수 있다. 목표를 위해 기존 시스템으로 할 수 있는 것을 안내해 줄 수도 있다.
요청된 사항이 전체 프로덕트의 비즈니스적 관점이나 고객 관점에서 충돌이 되는지 판단해야 한다. 요청사항에 대해 제로베이스에서 검토해야 한다.

비주얼 디자이너의 업무 순서

드래프트
SB의 기본 설계 요소를 기준으로 전체적인 디자인 컨셉과 방향을 만들어 보는 여러개의 시안.
기본 시안과 Variation
기획자 : 의도대로 되었는지, 개발이 불가능한 디자인은 아닌지 기획자 검토가 필요.
디자인 디렉터 : 그리드, 레이아웃 검토, UI 요소 $\rightarrow$ '운영요소'의 가이드화.
시안의 기본 케이스를 중심으로 여러가지 케이스에 필요한 여러가지 요소를 개별 디자인을 정리한다. 버튼 클릭 시/후, 체크/미체크, 케이스 분기처리에 대한 시안 등
프로토타이핑
원하는 형태의 동작과 인터렉션을 프로토타이핑 툴로 구현한 것.
이를 통해 디테일한 인터렉션에 필요한 디자인 세부사항을 디자인 할 수 있다.
스타일 가이드 작성
퍼블리싱을 하기 위해 디자인에서 주는 가이드, 메인 컬러, 서브컬러, 여백, 폰트, 텍스트 레벨.

디자이너와 커뮤니케이션

비즈니스와 기획적 관점에서 의논하고 취향으로 접근하지 말 것.
기획자는 컨펌자가 아니라 의논하고 논의하는 협업자다.
모바일의 가변적인 환경을 이해하고 시안을 검토하고 또 다른 협업자들의 입장에 대해서도 충분히 대변해 주어야 한다.

개발자에 대한 이해

SW 형상 관리 빌드 담당자 : 깃허브, SVN 등의 형상 관리를 담당하고 소스 빌드 및 배포하는 담당자.
TA(Technical Architecture) : 데이터, 애플리케이션 아키텍처를 지원하는 데 필요한 정보기술 인프라 요소 및 구조, 그리고 이들 간의 관계를 정의하는 아키텍처 담당자.
DBA(Database Administrator) : 데이터베이스의 테이블 구조 및 인덱스, 쿼리 검수 등 관리자.
AWS의 보급으로 점점 더 Data Science영역의 업무가 요구됨.
시스템 프로그래머 : 대형 시스템의 내부에서 OS처럼 움직일 시스템을 설계하는 개발자.
보안 프로그래머 : 정보보호와 방화벽, 네트워크 보안 등을 담당하는 프로그래머.
웹 프로그래머 : JAVA, C++, Python 등의 언어로 웹 어플리케이션을 개발하는 프로그래머. 코더 : 전문적인 지식없이 단순 코딩을 하는 사람을 낮춰 부르는 말
임베디드 프로그래머 : IoT, 스마트폰 등 디바이스에 이식된 소프트웨어를 개발하는 프로그래머.

기획 산출물

비즈니스 관련 : 정책서, 업무 프로세스, 화면설계서(SB), 운영 가이드 매뉴얼
UI 관련 : 와이어프레임, 목업(페이퍼 목업), 화면설계서(SB), 프로토타입
개발 관련 : 요구사항 정의서, 화면설계서(SB), User Story, Backlog, Test Case

UI 관련 기획 산출물 구분
- 와이어프레임(Wireframe) : UI 중심의 화면 레이아웃
- 목업(Mockup) : 실물과 흡사한 정적인 형태의 모형
- 프로토타입(Prototype) : 다양한 인터랙션이 결합되어 실제 서비스처럼 작동하는 모형 $\rightarrow$ 디자인 진행 후 진행
- 화면설계서(SB, Storyboard) : 정책, 프로세스, 와이어프레임, 디스크립션 등이 모두 포함된 설계 문서.

서비스 정책서

서비스의 용어 및 기본 운영 정책을 정의한 프로젝트 산출물
정책 정의를 위해서는 서비스의 비즈니스 구조와 운영 프로세스가 먼저 확정되어야 한다.
정책 설정은 회사의 서비스 방향과 전략이 반영되어야 한다.
정책 설정은 화면 UI와 IT 설계의 기본 구조를 결정한다.

구성요소 찾기

업무 프로세스와 필요한 정책에 대해서 모듈 단위로 구분하여 회의를 통해 파악.
정의해야 할 용어와 프로세스 그리고 의사결정이 필요한 선택적 정책 결정.
Process Innovation 과정이 필요.

정책서 목차 정의

목차 설정을 통해서 정의할 프로세스와 항목 등을 확정 및 작성 범위 설정.

정책서 작성

목차의 항목을 기준으로 작성.
용어정의, 상태값 정의, 의사결정 정책 정의.
표로 단순화하되 직관적으로 이해되도록 정의.

단점과 대안

기존 서비스 정책서의 단점
- UI, UX에 대한 정의보다는 구현에 집중.
- 고객 이익적 측면의 사상보다 개바라과 비즈니스적 이익만 중요시되기 쉽다.
- Word로 작성 시 업데이트 및 관리가 어려워서 잘 갱신되지 않는다.
대안적 형태의 User Story + 위키(Wiki) 정책서
- 애자일 방법론을 채택한 경우, User Story에 연결하여 위키서비스를 만들어서 누구나 접근 및 수정 가능한 오픈 정책서를 운영하기도 한다.
- 오픈 정책서이기에 작성 규칙이 일관되지 않을 수 있거나, 누락될 수 있다.

요구사항 정의서

사전 요구사항 정의서 :
현업 요청 사항을 정리하여 중요도를 체크한 문서.
요구사항 정의서 :
현업의 요청사항을 바탕으로 만든 서비스 전략에서 기술적으로 필요한 부분을 정리하여 개발에 협업 요청을 하기 위한 문서.

cf) 요구사항 명세서 :
요구사항의 수가 많을 경우, 세부 요구사항을 분석한 요구사항 정의서와 구분하여 번호만 목록화한 요구사항 명세서를 만들어서 전체 요구사항을 관리.

요구사항 정의서의 작성

서비스의 UI까지 설계 작업을 시작하면서 정책을 세분화하여 기술로 구현하기 위한 모든 범위를 개발 항목 단위로 작성.
목적
- 개발과 사전 커뮤니케이션하여 기획 포함 및 개발 수용 여부 판단.
- 최초 요구사항이 누락되지 않도록 화면설계서(SB)까지 관리할 수 있는 기준 마련.
주요 작성 항목
- 구분 : Front/Admin/기타
- 신규여부 : 신규/기존수정
- 요구사항번호 : 모듈명 + 숫자 Order001
- 요구사항명
- 요구사항 상세 설명, 분석
- 비고 : 다른 요구사항과 연결여부 등
- 개발 수용여부 : Y/N/보류
- 완료여부 : Y/N

단점
- UI, UX에 대한 정의보다는 구현에 집중.
- 정책서에 포함된 내용 기반으로 작성되며 UI, UX와 독립적으로 진행되어 개발담당자가 서비스의UI, UX를 이해하기 어려울 수 있음.
- 초기 요구사항 정의서에 없는 항목에 대해서는 프로젝트 도중에 추가 어려움. ( 폭포수 방법론의 문제점!)

대안적 형태의 애자일 Backlog : 요구사항 정의서 없이 Backlog에서 해당 요구사항을 논의 및 설정.

개발자 설득

개발자를 왜 설득해야 하는가?

개발 PL(Project Leader)의 역할
- 개발 인적 자원의 분배
- 기존 시스템의 안정성 유지 : 오류 방지 및 시스템 유연성에 대한 책임.
운영 개발 PL의 두 가지 질문
- 꼭 추가적으로 개발해야하는가? : 기존 시스템으로는 해결이 불가한가?
- 기존 영향도를 최소화할 수 있는가? : 기존 진행중인 프로젝트와 중요 모듈에 대한 영향도를 최소화한 개발 범위로 확정이 가능한가?

프로젝트 필요성에 대한 이해는 협력의 기본이며 더 좋은 기획과 산출물로 이어진다.

IA

IA(Information Architecture)

서비스의 정보 구조를 설계하는 것을 의미하며, 대부분 화면으로 이루어진 서비스의 경우에는 화면간의 상하관계를 정의하고 고객 동선을 관리한다.
과거 PC위주의 페이지 단위 사이트의 경우에는 IA가 사이트의 네비게이션을 결정하기 때문에 핵심적인 UX 관리요소로 중요하게 관리된다.
모바일 서비스가 많아지면서 한 페이지가 다수의 페이지 역할을 대신할 수 있도록 되면서 IA 문서는 개발 페이지 목록으로의 역할이 더 강해지고 있다.

Context : 비즈니스 목표, 자금, 정책, 문화, 기술, 자원, 제약조건
Content : 문서/데이터 형식, 콘텐츠 항목, 규모, 현재 구조
Users : 주요 사용자, 태스크, 니즈, 정보 탐색 행위, 경험

IA 작성 전 작업

마인드맵이나 트리구조를 이용하여 고객의 TASK 동선별 화면 구조 정의
한 화면 내 통합할 수 있는 기능들은 하나의 화면내에서 통합

문서 작성

주요항목
- 화면의 Depth : 트리구조내 구조 깊이.
- 페이지명 또는 화면 코드. cf) 화면코드는 규칙으로 정의 Order001B
- 페이지 설명
- 담당자 구분 : 디자인/개발/어드민
- 개발 완료 여부 : Y/S

와이어프레임

UI 중심의 화면 레이아웃

스케치의 필요성

처음부터 와이어프레임으로 그리려고 하면,
전체적인 UI 전략보다는 '그리드'의 오와 열에 치중하게 된다.
그럴듯하게 화면 채우는 것에 대해 신경이 쓰이게 된다.
너무 신경써서 한 버전을 그리고 나면 다른 버전을 그리기 싫어진다.
따라서 스케치를 꼭 해야한다.

와이어프레임의 정의와 작성

서비스의 UI까지 설계 작업을 위한 각 UI영역의 위치에 대해 컨텐츠 없이 아웃라인만 네모 박스로 정의.
모바일 서비스로 오면서 UI 표준화가 많이 되면서 각종 목업 그리는 툴들이 활성화되면서 와이어프레임이 좀 더 목업에 가깝게 변화.
Ajax 등장과 모바일 서비스의 특징으로 한 화면에서도 여러 케이스와 서비스 시나리오 흐름이 생기면서 점차 복잡해지고 목업, 프로토 타이핑 형태로 변화.

목업의 정의와 작성

와이어프레임보다 좀 더 상세화하여 컨텐츠의 케이스와 형태를 구분할 수 있을 정도로 UI를 만들어 놓은 페이지
디자이너에게 원하는 UI를 전달하기에 용이하지만, 모바일 환경에서는 여전히 인터랙션을 표시할 수 없는 단점 존재.
대안적 형태로 인터랙션과 상호 관계를 정의하여 한 화면내에 이동 동선 표시해주는 형태로도 진화.

페이퍼 목업 테스트

목업 상태에서 종이로 오리거나 잘라서 사용자에게 Task에 따라서 이용하도록 하며 고객 사용성을 테스트.
기획 단계에서 신규 서비스의 UI나 동선 인사이트를 얻을 수 있다.

프로토타이핑과 사용성테스트

목업 또는 시안 상태에서 간단히 인터랙션을 구현하여 모바일폰 또는 디바이스에서 사용해볼 수 있도록 만든 가짜 앱.
사용성테스트와 협업자간 서비스 이해를 위해 작업하는 것이다.
회사 R&R에 따라 기획자나 디자이너가 작업하며 그 수준도 회사에 따라 다르다.

화면설계서

화면설계서
웹이 대부분 화면을 기반으로 되어 있어 나온 용어로, 화면을 구성하기 위해 기획과정에서 나온 모든 것을 포함한다는 의미로 사용된 용어.

Storyboard/SB
이용 시나리오와 인터랙션을 강조하여 전반적인 흐름을 보여줘야 한다는 의미에서 사용된 고전적 용어.

화면설계서의 구성요소별 양식

$\Rightarrow$ 기획 작업의 총집합 문서

수정 이력

화면설계서는 숙제처럼 기획자가 작성한다고 해도 프로젝트 기간동안 지속적인 업데이트가 필요하다.
개발환경, 법적 검토, 사용성 검토 등 여러가지 변수로 인해 로직이나 협의 사항이 변화하기 때문에 이에 대한 기록이 필요하다.

기획의도/KPI

특별한 양식은 없다.
기획의도에는 기획 요청자의 배경을 포함하여 기획자에 의해서 해석된 프로젝트의 목적과 목표를 작성한다.
$\rightarrow$ 비즈니스적 관점에서 프로덕트 운영 사상과 정책을 반영.
오픈 전후 효과를 측정할 수 있는 KPI가 있으면 기록.
만약 수치화 시킬 수 있는 것이 없다면 사용성 테스트 등 정성적인 목표나 계획을 포함한다.

프로세스 플로우차트

프로젝트에서 다루는 서비스의 흐름이 있는 경우, 플로우 차트로 정리하여 제시하면 서비스 파악이 용이하다.
화면설계서는 디자이너, 개발자 등 협업자와의 커뮤니케이션 문서이므로 처음에 프로젝트 범위에 대해서 인지시키는 것이 중요하다.

개발 범위 화면 목록(IA)

프로젝트에 포함되어 있는 개발범위를 페이지 단위 목록, 트리구조로 표시
전체 개발범위를 이해하기 쉽도록 표시하며 기존 IA상 화면들의 관리를 위해서도 필요하다.

와이어프레임, 목업케이스, 디스크립션

와이어프레임과 목업을 넣어 레이아웃 설계 옆에 세부적인 디스크립션을 추가한다.
화면이 케이스에 따라 변화할 경우 화면을 여러개로 분리하여 케이스를 표시한다.
디스크립션은 인터랙션, 정책, 로직 등 디자인/개발에 필요한 모든 사항을 기록한다.
케이스 및 로직 정리 시 표나 별도 장표를 활용하여 명확하게 표시한다.

화면설계서(스토리보드, SB) 디스크립션의 작성

디스크립션은 세부적으로 쪼개서 명확하고 정확하게 작성해야한다.
인터랙션과 데이터 노출에 대한 부분의 로직을 분명히 해야한다.
개발과 디자인시에 관련된 이슈사항이나 우회사항이 있다면 명시.
정책이 불분명한 부분은 명시하여 추후 버전관리가 되도록 해야한다.

케이스의 구분과 작성

케이스가 다를 경우, 케이스의 가지수와 경우의 수를 명시해줘야 한다.

분기처리 :
동일한 화면에서입력되는 데이터 케이스에 따라 다른 UI나 출력값을 보여주는 케이스.
예외처리 :
데이터를 불러오는 영역에서 비정상적인 데이터나 이용상황에서 발생되는 문제를 방지하기 위한 조치. 유효성체크(Validation Check)

디스크립션 정의

통이미지인가
이미지 텍스트인가
시스템 폰트인가
고정/가변인가
데이터 호출/케이스 구분인가
데이터의 관리하면은 무엇인가

UserStory & Backlog

UserStory 작성

Product Owner가 기본적으로 작성해온 프로토타입을 보며 UserStory를 작성.
UserStory는 팀원 모두가 작성하지만, 그 중 PO가 UserStory의 경중을 선정하여 Backlog를 선정.

UserStory 특성

독립적이다. (Independent)
협상 가능하다. (Negotiable)
사용자와 비즈니스에 가치가 있다. (Valuable)
예측 가능하다. (Estimate)
사이즈가 작다. 2-3주내 개발 가능. (Small)
테스트가 가능해야 한다. (Testable)

UserStory의 우선순위 평가 방법

Assumption Test
중요한 비즈니스 가설일수록 큰 포인트 + 사용자에게 중요도가 높을 수록 큰 포인트
MoSCoW
Must/Should/Could/Won't
BUC
Business benefit + User benefit - Cost

$\Rightarrow$ 각 UserStory에 Point를 산정하고 상대적 비교를 통해 중요도를 선정해야한다.

UserStory기반 Backlog 작성

UserStory의 세분화
UserStory가 너무 클 경우 EPIC, Task, Sub Task로 구분하여 관리.
Infra 기능의 구분
User나 기능에 관계없이 기본적으로 되어야하는 개발은 Infra로 구분하여 Backlog를 별도로 작성.
UserStory의 등록 시 연결된 프로토타이핑을 함께 등록.

테스트 케이스(T/C)

테스트 단계의 업무과 협업자

QA	QC	QE
테스트 일정 수립	TestCase 수행	자동화 T/C설계
프로젝트의 제품 수준 영향에 대한 의견제시	오류에 대한 공유 및 처리 확인	테스트 자동화 구현
Lesson&Learn 공유	오류 상황 관리	테스트용 데이터 생성
QC 인력 설계
오픈 여부의 결정

$\rightarrow$ QA(Quality Assurance) : 제품개발단계 품질보증 활동 (고품질 제품 확보가 주요 목적)
$\rightarrow$ QC(Quality Control) : 제품양산단계 품질관리 (불량품 제거가 주요 목적)
$\rightarrow$ QE(Quality Engineering) : QA/QC를 수행하기 위해 필요한 모든 Engineering 활동

단위테스트 : 기능단위 테스트, 데이터 확인, UI테스트
통합테스트 : 시나리오 테스트, Ad-hoc 테스트(예상하지 못한 방식으로 테스트), 디바이스 테스트
사용성 테스트 : 동작, 인터렉션, 사용성에 대한 최종 점검
베타테스트(Close/Open) : 오픈 후 실제 운영

테스트 설계를 위한 협업

개발자, UI디자이너, 인프라 개발자, HTML5개발자 $\leftrightarrow$ 기획자 $\leftrightarrow$ QA, AC, QE

SB와 기획안 리뷰
TEST 설계를 위한 고객 UX 전달
최소 테스트 기간 정의
테스트 케이스의 구성 정의
기준/대상 디바이스 선정

운영 가이드

서비스 오픈

오픈을 위해 기획자가 해야할 일

오픈 전 운영 계획 확정
-누가 운영할 것인가.
-운영 주기는 얼마인가. 오픈 컨텐츠의 작업 일정은 어떻게 되는가.
오픈 운영 가이드(매뉴얼)작성 및 교육 진행
-시스템 교육 대상은 누구인가
-운영 교육 일정 및 공유 문서 제작
-CS/SCM/법무팀 등 기획 시 유관부서에 오픈일정 및 변경사항 공유
-고객안내 사항은 별로도 없는가. 고객 안내 공지가 필요한가.

운영 매뉴얼과 SB

문서를 보는 주체가 다르다.
가이드는 운영 케이스와 입장에 따라서 N개가 필요하다. 입력자와 승인자
SB는 사용자에게 과한 정보를 담고 있다.
가이드는 사용자가 필요한 범위의 내용만 담고 있으면 된다.
복잡도가 높은 문서를 받을 수록 운영자는 읽지 않는다.
가이드는 정책에 대해서 추가 협의를 하려는 문서가 아니다.
협의는 완료되었고 개발도 끝나간다.
운영 가이드 후의 변경 요청사항은 개선요청일 뿐이다.

운영 가이드 매뉴얼

업무자별로 가이드 대상자를 나우어, 작성할 가이드 개수를 파악한다.
업무자별로 목적에 맞게 가이드를 작성한다.
업무순서에 따라 번호를 매기로 순서에 맞추어 설명한다.
각 업무자들이 할 수 있는 질문을 예상하여 기록한다.
오픈 일정에 그에 따른 오픈컨텐츠 입력일정을 공지한다.

기획자

기획자로서 필요한 역량

$\Rightarrow$ 사업 기획 능력 : 비즈니스 분석, 시장 흐름 이해
$\Rightarrow$ 서비스 기획 능력 : 고객분석, 고객 경험, 플랫폼 생태계 선순환 기획
$\Rightarrow$ 데이터 분석 능력 : 행동분석(GA 등 툴), 사용성 테스트, 린 UX 실행
$\Rightarrow$ 프로젝트 방법론별 실무 능력 : 폭포수/애자일 각 산출물의 작성

$+$ 추가능력
디자인, 개발 업무 대행 능력, 전략 기획 및 IR 자료 등 문서 작업 능력 등...

필요한 것은 커뮤니케이션 : 이슈를 해결하기위해 대화 속 전문 용어.
자사의 용어사전을 만들어 어휘를 통일 시키면 좋다.

포트폴리오

서류가방, 자료수집철, 자료묶음 등을 뜻하는 말.
자신의 경력이나 실력을 알 수 있도록 과거의 만든 작품이나 관련 내용을 은 것.

디자이너가 비주얼적인 제작 능력을 보여주는 것처럼 기획자는 기획자다운 역량을 보여줄 수 있도록 구성해야한다.
비즈니스와 고객에 대한 이해와 문제 해결을 위한 사고과정 그리고 산출물 작성 능력을 보여줄 수 있어야 한다.

서비스 기획 강조

서비스 화면보다 특정 시장의 Player들의 특징과 수익구조, 비즈니스 모델의 분석.
추가적으로 제안하고 싶은 서비스에 대해서 강조.

UX분석 강조

특정 기능이나 Task에 대하여 여러 서비스의 고객 UX를 분석하고 이용동선과 장단점 분석.
인사이트 정리 및 해당 Task에 대한 자신의 이상적인 서비스 형태 제안.

실무 능력 강조

간단한 프로젝트를 진행해보고 작업했던 문서 보여주기.
기존 서비스 분석 후 '데이터'와 '로직'등 개발 구현의 관점에서 디스크립션이 상세화된 화면 설계서를 역기획하기.

프로젝트 기획

프로젝트 시작에서 준비까지

✔ 시작

수행사는 사업추진의 목적을 파악하고, 사업수주 및 수행 가능성을 검토하고, 경쟁사 대비 사업수행의 강점을 파악하여 수주포인트에 집중할 인력 및 일정 소화가 가능한지 여부를 판단한다.

RFP 분석
사업추진배경, 프로젝트 목표, 업계 동향, TFT구성 및 일정
$\downarrow$
RFA 작성 및 인터뷰
제약사상에 대한 질의, 과업범위 재정의, 인프라 및 운영 질의, 개발환경 질의
$\downarrow$
요구사항 정의서 작성
요구사항 정의 목록
과업범위 검토

✔ 제안

수행사는 고객의 '근본적인' 니즈를 파악하는 것이 시작의 가장 중요한 포인트라 생각한다.
무엇을 원하는지, 왜 그럿을 원하는지에 대한 니즈 분석을 통해 다각도릐 수행방안과 리스크 대안을 마련한다.

사업평가
요구사항의 수행능력, 일정 및 인력 리스크, 사업수행의 적절성, 타 사업과의 협업구조
$\downarrow$
TFT구성 및 견적
최적의 TFT인력 파악
과업범위에 대한 견적산출
제안 경쟁력 검토
$\downarrow$
제안서 작성
요구사항 정의 분석
전략과 컨셉 정의
벤치마킹 및 동향 분석
수행기획안 수립
일정 및 관리계획 수립

✔ 분석

기본적인 수행 프로세스를 기반으로 프로젝트의 성격 및 환경에 최적화 될 수 있는 탄력적 프로세스 수립으로 일정 및 과업 리스크를 최소화 할 수 있는 분석단계를 수행한다.

스케줄링, 요구사항 분석, 타켓분석, AS-IS분석, 벤치마킹, 수행기획안

✔ 설계

요구사항 및 AS-IS분석을 통한 수행기획안을 바탕으로 기능정의, 이슈리스트와 의사결정 내역서 관리 및 정보구조(IA)와 화면 UI를 설계하여 디자인/퍼블리싱/프로그래밍 구현 리뷰를 진행하고 구현 진척관리를 준비한다.

✔ 검수

기능정의와 화면설계서를 기준으로 구현사항에 대한 테스트 계획을 수립하여 단위테스트 및 예외 처리 테스트를 수행하고, 수행 TFT와 현업 통합테스트를 순차적 진행과 동시에 수정 요청 사항에 대한 오류, 변경, 개선 사항에 대한 우선순위별로 디버깅을 진행한다.

$\Rightarrow$ 기획자는 '일정 준수', '왜를 먼저', '전체 통찰'하는 자세가 필요하다.

프로젝트 분석

무엇을 분석해야 하는가?

AS-IS 프로젝트 목적 및 배경 : 현업과 고객의 요구사항
시장흐름과 경쟁사 : 사용자, 누구에게 서비스 할 것인가, 인프라와 사용자 환경
벤치마킹 시사점 : 트렌드와 아이덴티티, 서비스와 시스템의 개선점

프로젝트가 만들어진 목적 및 배경은 무엇인가?

휸하엘레나킴

문과생의 데이터 분석 공부

이전 포스트