[패스트캠퍼스 부트캠프 : PM 2기] Day 3

맥 자동 업데이트 때문에 작성 글 날라갔다.. 인생

---

서비스기획 프로세스 

 

리서치 분석

고객들이 어떤 생각을 가지고 있는지 고객 니즈 파악

시장 고객 트랜드 분석까지 한다

 

요구사항 정의

PRD 제품 요구사항 정의서

리스크 검토 진행

법적으로 문제 보안적으로 문제가 있는지 확인

 

기획 문서 작성

ppt로 옮김

IA 정보구조도 , 와이어프레임, 스토리보드

WBS 프로젝트 전체 일정 작성

리스크 분석을 이 때 할 수 있다

 

유관부서 리뷰

마케팅이 필요한 팀이라면 마케팅 팀이 있다

UI/UX가 바뀔 수 있어서 디자인 팀 부터 한다

QA팀 리뷰도 한다

 

디자인/개발 시작

디자인 필요 없는 것 부터 개발 시작

→ 서버 로직 구성

→ 프론트 개발시 디자인 가이드 필요

 

취약점 점검

서비스가 보안적으로 안전한지 살펴봄

해킹, 정보탈취 가능성 확인

정보보호 정보보안팀에서 검토

 

QA

기획대로 만들어졌는지

계획대로 만들어졌는지 확인

Quility Assurance 품질 보증

기능적 심미적으로 잘 동작하는지 검수하는 작업

 

배포/오픈

서비스에 생명을 불어 넣을 수 있는 작업

 

목표 설정

 

서비스 기획 할 때 가장 중요한 부분 

서비스 목적에 따른 목표 설정 필요

정성적인 목표보다는 정량적인 목표를 성정하여 트래킹하는 것이 중요하다

-> 가장 중요한 부분이다

 

OKR(Objective & Key Results, 목표 & 핵심결과지표)

-> 회사, 팀 등의 조직 및 구성원 개인들의 목표를 설정하고 성과를 측정할 수 있는 방법

1999년 구글에 최초 도입

아마존 디즈니 메타 등 글로벌기업이 활용

국내에서도 스타트업, 대기업으로 확산되고 있음 

 

OKR 구조 

Objective(목표) : 달성하고자 하는 이상적인 목표 또는 목적지 

-> 이상적으로 공격적으로 목표를 설정 해야한다

Key Result(핵심 결과) : 목표 달성을 위한 구체적인 방법

-> 측정 가능 해야한다

CFR

Conversation, Feedback, Recognition

정량적인 Key Result 작성하는 것이 핵심

CFR 지속적으로 트래킹해야한다 

OKR 특정 기간동안 OKR 목표 수정하는 것이 필요하다 

이상적이고 공격적인 목표를 설정한다고 했는데 어려운 목표가 쉬운 목표 보다 성과 개선을 이룬다

구체적인 어려운 목표가 높은 성과를 주기 때문에 OKR을 이상적으로 공격적으로 설정 해야한다 

 

OKR vs KPI

KPI는 목표를 향해서 제대로 진행되고 있는지 체크 할 수 있도록 지속적으로 지표를 제공 

OKR은 목표와 목표달성을 위한 핵심목표를 묶어서 다루기 때문에 핵심 목표를 달성 할 때 마다 목표달성에 어느정도 가까워지는지를 알 수 있는 지표

KPI는 장기 목표다 

OKR 직원들이 동기부여를 받을 수 있다 

 

제품로드맵 작성 

 

제품로드맵 

정의 

시간 경과에 따라서 제품/서비스 또는 팀의 비전, 방향, 우선순위에 따라 제품/서비스가 앞으로 어떻게 진행 될 것인지 나타내는 문서 

제품의 전략, 방향성과 명확하게 연결 되어야 한다

고객 피드백 및 경쟁 환경의 변화에 대응해야 한다 

 

대상 

내부 제품을 만드는 팀을 위한 로드맵, 영업팀을 위한 내부 로드맵, 경영진을 위한 내부 로드맵 

-> 누구에게 보여주기 위해 작성하나? -> 팀원?, 영업부서?, 경영진?  

 

 

요구사항 정의서

정의 

기획하는 단계에서 왜 이 제품/서비스를 만들어야 하는가?에 중점을 둔 문서

각 이해관계자들의 관점 차이를 해소, 기획한 의도 및 주요기능을 유관부서 등에게 명확하게 전달하는 문서 

 

PRD 구성요소 

개요, 기회 및 임펙트, 제품 정의 및 요구사항, 마일스톤, FAQ

PRD는 제품이나 서비스를 기획하는 과정에서 왜 이 서비스 제품을 만들어야하는가에 대한 문서 

PRD를 통해서 이해관계자 마케팅팀 개발팀 디자인팀의 관점 차이를 해소하고 기획한 의도대로 명확하게 전달하기 위한 문서이다 

개요 : 왜 작성해야하는가?

어떤 문제를 해결하기 위해서 이 제품 이 서비스를 만드는지 이 서비스 제품을 만들기 위해서 어떤 배경인지 주 타겟층은 누구인지 나아가는 방향성 목적 목표 설정 

기회 및 임펙트 : 시장에서 어떤 기회들이 있는지 우리의 회사 입장에서 서비스 입장에서 적어주면 좋다

현재 트랜드 기술 주요 통계 자료를 기술해서 데이터들이 어떠한지 내용을 담는다 

서비스나 제품을 출시하면 고객들이 어떤 행동을 하고 어떤 영향을 받는지 기술한다 

제품 정의 및 요구사항 : 제품의 구체적인 형태를 제시하고 구성하기 위한 기능 기재 이해관계자들과 더 나은 제품을 만들기 위해서 이야기도 가능하다

 

개요 작성하기

문제 정의, 목적 및 배경, 주요 사용자(고객), 유저 스토리/ 유저 저니맵, 사용자 가치, 개발 원칙

 

예를 들면, 

지구온난화로 제철과일 출하시기를 알 수 없다

우리 제품 서비스를 기획을 했는지 기술 (설득하는 영역) → 제철 과일은 맛향 완벽 소비자에게 출하시기를 알려주고 소비자에게 출하되면 알려줘서 마트를 방문해서 구매하게 되는데 더 나은 방법을 소비자에게 소개해주고 싶다

과일 섭취가 필요한 1인가구 대상 혹은 주부 대상 명확하게 기술해야하고 어떤 어려움을 겪고 있는지 작성해주면 좋다

고객들이 문제를 해결하기 위해서 유저 스토리를 작성하거나 유저 저니맵 작성하는 것이 좋다 → 고객이 어떻게 문제를 해결해나가는지 보고 우리는 관여 할 수 있다

우리 서비스를 통해서 고객들이 문제를 해결해나갈수있는지 기술하면 좋다 → 명확하게 기술하는게 좋다

개발원칙은 기술 안하는 경우도 있다 필수적으로 개발하는 우선순위를 적어둔다 제품을 만들 때 의사결정의 부재하는 경우 적는 경우가 많다

 

기회 및 임펙트 작성하기 

기회, 가설 및 가설 검증 지표, 임팩트 예측(사용자가 얻게 될 가치)

사전의 준비한 모든 자료들이 PRD에 작성하는 것에 활용됨 시장환경 사회분위기 트랜드 기입

swot분석이나 stp 분석도 같이 하기도 한다

현재 시장 상황이 이러해서 우리는 고객을 위해서 이런 문제점을 해결할 수 있는 기능을 만들거야라도 해도 우리가 만든 서비스 모두가 성공한다는 보장이 없다 우리 제품이 소비자에게 적합한 해결책이 아닐 수 있다 제대로 문제를 정의하지 못 한 경우도 있다 수익창출도 간과 할 수 없다 어떻게 돈을 벌지도 계속 생각해야함

 

예를들면,

제철과일을 정기적으로 구매하기 위한 소비자가 존재할것이다 → 구독 N건이 있을 경우 가설검증이 된 것으로 한다

우리 제품이 어떠한 사회적 가치를 주는지 사용자가 얻게 될 가치에 대해서 고민해 보는 내용

제철과일 소비증대를 통해서 농민들의 소득을 늘릴 수 있다 택배 포장이 친환경이라 환경보호 가능

 

제품 정의 및 요구사항, 마일스톤, FAQ 작성

구체적인 제품 정의 및 요구사항 기술, 마일스톤 또는 WBS, FAQ

이 부분이 서비스를 만들 때 가장 중요하다 

이때 작성한 내용을 통해서 이해관계자들과 별도로 논의하고 나아가야 할 방향을 정하고 수익 전략구조를 도출한다 

마일스톤도 작성 우리가 서비스를 만들어나가기 위한 일정이라 할 수 있다 

FAQ 각 팀에서 궁금 할 수 있기 때문에 미리 궁금한 점을 정리해서 다른 팀들에게 배포하면 좋다 

 

프로젝트 일정관리 - WBS

 

프로젝트 일정관리 - WBS(Work Breakdown Structure) 

 

정의 

프로젝트를 효율적으로 진행하기 위해 업무 일정을 계획하고 관리할 수 있는 기초 문서

Work Breakdown Structure의 약자로 업무 분업 구조 또는 작업 분해 구조를 말한다 

프로젝트 전체 업무를 더 작고 관리하기 쉬운 작은 요소로 세분화하는 단계

 

목적

효율적인 업무 수행, 작업의 책임과 역할 명확화, 작업 진척 모니터링

상세하게 작성된 WBS를 통해서 어느 시점에 프로젝트가 실행되고 있는지 파악 가능 

 

WBS 구성요소

구성요소 

구분 : 큰 단위 업무 기재 

Task : 가장 작은 단위로 쪼개어진 세부 업무 명칭 기재

담당자(담당조직) : Task를 수행하게 될 담당자 기재

기간(시작일 및 종료일) : Task의 시작과 종료일자 기재

일정 차트(간트 차트) : 전체기간 대비 각 Task의 소요 기간을 색으로 표기

비고 : Task 수행 시 예외사항이나 제약사항을 기재 

-> WBS 작성은 서비스 기획자 PM이 작성한다

개발팀 디자인팀의 리소스를 혼자 리소스를 담당하기 어려워서 해당 팀원들의 담당자들과 리소스 취합함

 

WBS 예시

기획디자인 단계에서 시장리서치 전략 분석

개발요청 단계에서 우리 서비스가 앱 네이티브 서버 개발만 필요한 경우도 있어서 각 개발팀의 기획 문서 리뷰 개발팀 일정 공유 받음

개발 진행 -> 개발된 결과물로 테스트 진행 

담당 부서와 담당자까지 모두 WBS 기입하는 것이 업무에 도움된다 

담당자 미기입시 담당자 확인하는 과정을 거쳐야해서 리소스 낭비가 된다 

 

제품 설계 - IA

 

한눈에 우리가 만드는 서비스의 전체 메뉴와 흐름을 파악하는 것이 중요하다 

기능이 어떻게 묶여있는지 화면 단위로 한눈에 볼 수 있는 것이 중요하다

 

정보구조도 

정의 

정보구조도, Information Architecture의 앞글자를 따서 부르는 UX 용어

서비스 구축 시 기본 설계 구조도이며, 일종의 사이트맵 형식을 구체화한 문서 

네이비게이션, 푸터의 고객동선도 확인해 볼 수 있다 

 

트리 구조 

하위페이지 가지고 있는 계층 구조는 상위페이지를 통해 하위페이지로 접근 가능

 

종류

계층 패턴

탭 패턴

허브 앤 스포크 패턴

라이너 패턴 

네스트 돌 

벤토 박스 

-> 단점은 한 화면에서 다른 화면으로 넘어가기가 어렵고 멀티태스킹에서는 적합하지 않다

멀티태스킹에서는 적합하지 않다?

-> 허브엔 스포크 같은 경우에는 앱 사용시 하나의 View에서 다른 View로 넘어간다면 다른 메뉴로 넘어가기에는 전에 View로 가서 다시 들어가야한다는 것 

 

와이어프레임

정의 

앱/웹 서비스를 만들 때 동선, 구조를 제안하기 위한 화면 설계도 

디자인 요소가 들어가기 보다는 선을 이용해 윤곽을 잡는 것을 말함 

기획자의 요구사항, 서비스의 기능 요소를 모두 파악하여 전략적으로 설계 필요

와이어프레임은 디자이너, 개발자 등과 의사소통을 위한 수단이다 

 

제작방법 

펜과 종이를 사용한 스케치, 파워포인트, 그래픽 툴 활용

 

와이어프레임에 포함 할 내용?

화면에 어떤 정보가 나타나야 하는지?

어떤 레이아웃 모습을 보여줘야 하는지?

세부 컨텐츠가 있다면 어떻게 표현해야하는지?

다음 화면으로는 어떻게 이어지는지?

공통영역(내비게이션, 푸터 등)은 적절히 기능을 하는가?

 

추천 툴?

유료 - 스케치, 아도베 XD

무료 - 피그마(협업 가능 / 4.30~5.1에 부술 예정)

 

프로토타입

정의

본격적으로 개발에 들어가기 전 UI/UX 상호작용을 시뮬레이션 하기위해 동적으로 만드는 모형 

정적인 화면으로 설계된 와이어프레임 보다 사용자들의 경험에 대한 테스트를 진행해 볼 수 있다

 

스토리보드(상세계획서)

정의

일반적으로 기획서라고 칭하는 문서 (서비스기획 문서의 최종 산출물)

스토리보드 = 상세기획서 = 화면설계서 등의 용어로 불려짐

최종적으로 유관부서에게 공유하는 문서

 

구성요소 

서비스 개요

-> 목표, 주요기능 

서비스 구성 

-> IA, 서비스 정책

-> 주요 서비스 프로세스

상세 기획 

화면(UI) 시나리오

화면별 와이어프레임 + 기능 상세설명

개요 : 함께 일하는 분들이 우리 제품 서비스를 이해하기 쉽게 우리 제품 서비스에 공감대를 형성하게 작성하는 것이 좋다 

구성 : PRD 문서 생각해라 

기획 : 우리가 제품 서비스에 주요 동선에 화면들을 추가 와이어프레임에 상세한 설명을 덧붙임 

 

서비스 개요

-> 최신본인지 확인하기 위해 버전과 작성일을 기입해야한다 

-> PRD에서 작성해 본 목표나 주요 기능들을 서비스 개요 부분에서 옮겨 담을 수 있다 

-> 규모에 따라서 생략이 가능한 부분은 생략을 해야한다

-> 서비스 정책 서비스 프로세스를 작성한다 

-> 회원가입 정책, 결제/주문 정책이 이에 해당된다 회원관리 정책도 해당한다 

-> 프로세스는 전체 프로세스가 눈에 보이도록 한장에 그리고 기능단위 프로세스 정리 정보흐름도도 그려주면 좋다

-> 상세 기획은 화면(UI) 시나리오, 와이어프레임에 기능 상세설명을 작성한다 

-> 기능별로 쪼개서 작성

-> 화면의 이동을 볼 수 있도록 화면 시나리오를 작성한다 

-> 와이어프레임 화면 자체는 정적임 변화되는 모든 것을 담을 수 없다

-> 그 변화되는 부분을 정의하는 것을 기획서에 상세설명을 추가한다고 표현하다

-> 고객을 만나는 과정에서 오류케이스가 파악된다면 여기에 추가해주면 좋다

 

테스트 

분석단계에서 만들고자 하는 서비스의 방향과 목표를 설정하고 고객층 시장 경쟁사를 분석한다

서비스 기능을 설계 PRD 작성, 와이어프레임, 스토리보드를 작성하여 기획 산출물을 만든다 

디자인 개발 리뷰등을 통해서 실질적인 디자인 된 결과물을 바탕으로 서비스 개발 작업 진행

테스트 단계를 거쳐서 고객들에게 서비스를 오픈하게 된다 

 

Quality Assurance의 약자로 '일정한 효율과 품질이 보장되어야하는 활동'을 뜻함

개발 완료 후 서비스 오픈 전 안정적으로 작동 되는지 문제 될 만한 사항은 없는지 등을 살펴보는 단계

QA팀에서 진행하게되나 PM 또는 기획자가 진행하는 경우도 있다

 

QA 순서 

기획서 분석

-> 가장 중요한 것은 QA팀에서 기획산출물을 분석하는 작업이다

-> 서비스에 대해서 전혀 모르는 경우가 있어서 QA팀을 위해서 서비스 리뷰를 해준다

테스트 범위 설정(단말 등)

-> 테스트 범위를 설정하게 되는데 웹기반인지 앱기반인지 안드로이드만? iOS까지 제공하는지

-> 어떤 기기 단말에서 테스트하는지 범위등을 정하게 됨

테스트 케이스(Test Case, T/C) 검토 및 작성

-> 이미 출시된 앱서비스에 기능을 추가하는 경우에는 하위호환성을 어떤 앱 버전까지 살펴봐야하는지 검토해야한다

-> 테스트케이스는 기획산출물을 보고 수행절차 기대결과등을 포함해서 작성하게 된다

테스트 진행 -> 버그 리포트 

-> 테스트케이스를 통해서 테스트 진행

-> 문제가 발생할 경우 버그 리포트 적음

최종 테스트 진행 

결과 리포트 작성

-> 결과 리포트 작성 몇개의 테스트케이스가 있었고 몇개를 성공했는지 몇개를 실패했는지 결과 정보를 알려줌

 

체크리스트 

QA팀에 요청하기 전에 스스로 기획한 기능이 잘 개발되어있는지 사전 테스트를 진행

QA팀에 요청할떄는 충분한 일정을 감안하여 요청하여야한다

 

서비스 오픈 

체크리스트

서비스 오픈 전 (D-7)

최종 QA 및 테스트 결과 확인하기

서버, 앱 배포 일정, 배포 시나리오 확인하기

마케팅/프르모션 확인하기

고객센터 및 유관부서 업무메뉴얼 작성 및 오픈 공유

모니터링

 

오픈이후 

고객센터, 앱스토어 리뷰 등에 올라오는 CS 대응 및 개선 포인트 찾기

지속적인 서비스 로그 모니터링

일별/주별/월별 등 지표 분석

 

회고 방법론 - KPT

Keep, Problem, Try의 약자로 회고 내용을 세가지 관점으로 분류하고 회고를 진행하는 것이 특징

짧은 시간에 모든 구성원의 생각을 공유하고, 실행 가능하고 측정 가능한 Action Item을 도출함

 

타임라인 리뷰

프로젝트 진행 기간 동안 이슈 사항 또는 사건들을 타임라인으로 표시하여 회고하는 방법

프로젝트 기간이 너무 길 경우, 주요 사건들에 대해만 리뷰를 진행 할 수도 있음

 

주요 사건을 5F로 공유하기 

프로젝트를 진행하면서 있었던 주요 사건들을 시간축으로 정렬해서 5가지 F로 나누어 돌아보는 방법

Fact(사실), Feeling(느낌), Finding(교훈), Future Action(향후 행동), Feedback(피드백)

 

회고 방법론

요약

프로젝트를 진행하면서 어떤 일들이 일어났는지 살펴본다

좋았던 부분, 아쉬웠던 부분을 정리한다

Keep, Problem을 정의하고, Try를 설정한다

추가 개인적인 바램이나 앞으로 계획을 추가할 것을 검토하고, 액션아이템을 도출한다