[제로베이스 pm스쿨] 매일학습일지 Week 7-3

✍🏻 오늘의 할 일

- 챕터 17 강의 (2/3)

- 아티클 스터디 1개

- 매일학습일지

---

프로덕트 목표와 지표 설정하기 

AARRR 지표

 

PV (Page View, 페이지뷰)

: 페이지가 사용자에게 노출된 지표

 

UV(Unique View, 순방문자)

: 데이터 수집 기간 동안 페이지에 방문한 전체 사용자 중 중복되지 않은 순 방문자를 의미

 

전환율 (Conversion rate)

: 방문한 사용자 중 특정 행위를 한 방문자의 비율

 

이탈율 (Bounce Rate)

: 페이지와 상호작용하지 않고 사이트를 떠난 단일 페이지 세션의 비율

 

종료율 (Exit Rate)

: 방문한 모든 페이지를 대상으로 1개 이상의 페이지를 보고 화면을 종료한 방문(세션)행동의 비율

 

데이터 분석 목적

- 데이터를 분석할 때 항상 조직의 이슈를 기반으로 생각한다.

- 데이터는 숫자나 수치보다 패턴에서 발견되는 변화/추세가 중요하다.

- 문제를 개선하기 위한 가설을 수립하고, 조직에 공유하고 공감대를 얻는다.

- 문제를 발견한 시점의 데이터는 개선 후 결과 평가할 때 랜드마크로 활용한다.

- 최종적인 목적은 데이터를 분석하여 비지니스에 기여하고 성과를 창출하는 것이다.

 

프로덕트 관리 및 산출물

프로적트 기획 단계별 산출물

1. Product의 목표, 사용자 정의, 핵심 지표 설정

2. 구조 설계 - 인포메이션 아키텍처

3. 상위 기획 - 요구 정의서 (요건 정의)

4. 상세 설계 - 와이어프레임, workflow

 

일정관리

전체 일정 진행상황 파악, 업무 할당 및 진척도 확인

 

과거 - WBS(엑셀 파일)로 관리

현재 - JIRA로 일정&업무 진행도 실시간 확인 가능

 

프로덕트 배포

프로덕트 배포할 때 유의사항

1. 배포 일정은 개발 조직이 정한 배포 일정이나 절차가 있는지 먼저 확인한다.

2. 미리 배포 일정과 변경사항을 협업팀(법무팀, 마케팅팀, 고객센터)과 공유 협의한다.

3. 저녁 늦게 또는 금요일에는 배포하지 않는다.

4. 사용률이나 매출이 급증하는 기간에는 배포를 지양하자.

 

"배포일정을 정할 때 플랫폼을 고려하라"

1. iOS와 안드로이드는 특정 기관의 검토/승인이 필요하다.

iOS는 새로운 버전을 배포하려면 애플 앱스토어의 승인을 받아야 다운로드 업데이트가 가능하다. 

안드로이드는 구글의 승인을 받아야 되짐나 상대적으로 덜 보수적이다.

 

2. 플랫폼 배포 순서와 일정을 다르게 진행한다.

국내에서는 안드로이드 앱을 먼저 업데이트한 후 몇 주후에 iOS앱을 업데이트 한다.

 

배포 주기를 정해서 배포해야 되는 이유

1. 여러 팀에서 동시 다발적으로 배포 시도할 경우 기술적인 문제가 발생할 가능성이 높아진다.

이는 서비스의 안정성, 신뢰도에 영향을 미친다.

2. 버전 관리의 어려움이 발생한다.

3. 수시로 업데이트 될 경우, 고객 경험의 일관성을 유지하기 어렵다.

 

RFP (Request for Proposal)

제안 요청서 : 발주자가 특정 과제의 수행에 필요한 요구사항을 체계적으로 정리하여 제시함으로써 제안자가 제안서를 작성하는데 도움을 주기 위한 문서이다.

 

메뉴 구조도

Main Structure를 파악할 수 있는 계층적 구조의 '메뉴 구조도'

 

I.A (Information Architecture)

정보 구조 설계, 어떤 기능을 하는 화면들이 어떤 뎁스

 

Wireframe

화면 단위의 구조(레이아웃)을 설계하는 작업

 

User Flow

실제 사용자들이 구체적으로 이용하는 순서에 따라 화면들이 전개되는지 정의

 

UI Workflow

 

Prototype을 활용한 Small test

처음 접하는 기능 또는 디자인을 어떻게 사용하는지 관찰하는 목적

 

Usability 휴리스틱

사용성을 평가하기 위한 척도로 사용되는 10가지 기준

신규 서비스를 출시 하기 전에 체크 리스트 기준으로 활용

 

1. 시스템 상태의 시각화

2. 시스템과 실제 세계의 일치 (Metaphor)

3. 사용자 제어와 자유

4. 일관성과 표준 (Consistency)

5. 에러 방지

6. 에러 인식, 진단, 복구

 

개발 플랫폼 정의

Web vs App 특징

Web	App
기준 해상도 정의 (예시: 1024 * 768)	표준 OS 설정 (안드로이드, iOS)
브라우저 호환성 강함 (iE9, Chrome, Firefox 등)	브라우저 호환성 약함 (Safari, Chrome)
마우스/키보드 인터페이스	터치 인터페이스
넓은 영역	제한된 영역
정보 우선순위에 대한 배치	정보 우선순위에 대한 노출 순서
웹접근성 준수	Native App의 경우 App 접근 권한 정의, 앱접근성 준수 (스마트폰 앱 접근 권한 안내서)
웹표준 준수 (HTML5, CSS, JavaScript)	앱 표준 Guideline

 

Native App

안드로이드 앱은 google play store에서, 

iOS는 앱스토어에서 다운로드 가능하고 해당 OS에서만 실행된다.

 

Mobie Web

브라우저에 URL만 입력하면 어떤 디바이스에서도 동일한 내용을 확인할 수 있다.

 

Hybrid App

"네이티브앱 + 웹앱", 네이티브 앱에 웹뷰를 띄워 웹앱을 실행시키는 형태이다.

 

적응형 웹 (Adaptive Web)(과거)

데스크탑 버전과 모바일 버전의 사이트를 각각 제작해 운영주소 앞에 'm'을 붙인 '모바일 웹 페이지'

 

반응형 웹(Responsive Web)

하나의 소스 코드로 모든 스크린에 최적화된 웹 사이트를 구축할 수 있는 방법

브라우저 가로 넓이에 반응하여 구성 요소가 변하는 기술

 

플랫폼 출시 순서를 정할 때 고려하는 점

1. 내부 디자인과 개발, QA 리소스를 고려한다. 동시 오픈을 준비하더라도, 일정 간격을 두는 걸 권장한다.

2. 출시 국가에서 OS의 시장 점유율을 고려한다.

3. Target User가 선호하는 OS를 먼저 출시한다.