[새싹X러닝스푼즈] IT 서비스 기획자 취업캠프 4기 - 프로덕트 설계 강의 후기2 (4~5주차)

 

 
 
안녕하세요. 호이진입니다.
새싹 4~5주차 때 들었던 프로덕트 설계 강의를 이어서 살펴보도록 하겠습니다.
 
이전 포스팅은 아래 링크에 있습니다.
 
https://mia-choi.tistory.com/19

[새싹X러닝스푼즈] IT 서비스 기획자 취업캠프 4기 - 프로덕트 설계 강의 후기1 (4주차)

 

---

 
1 프로덕트 설계
2 서비스 기획
3 프로토타이핑/UT
4 데이터 분석
5 PO의 기타 업무
6 애자일 캠프 

---

 
4. 데이터 분석 
 

프로덕트 설계 수업 중 데이터 분석과 관련된 강의를 들었습니다.
서비스 기획자가 갖추어야 하는 데이터적인 역량에 대한 설명을 들었습니다.
서비스 기획자에게 필요한 데이터 분석의 목적은,
 
- 서비스에서 축적되는 다양한 데이터를 모니터링하여 고객 경험 최적화를 위한 개선점을 찾기 위하여
- 고객 경험 최적화를 위한 서비스 개선 과제의 개선방향 및 의사결정 근거를 찾기 위하여 
 
로 볼 수 있다고 합니다.
 
데이터 분석 과정은 
a. 데이터 분석 설계 
b. 데이터 준비
c. 데이터 가공
d. 데이터 분석
e. 결론 도출 
으로 이루어지는데, 데이터 준비, 가공, 분석은 데이터 분석가의 영역이라고 합니다.
 
서비스 기획자 혹은 PO는 데이터 분석을 위해 어떤 역할을 해야 할까요?
 
1) 데이터 분석 환경 설계 : 도메인/서비스/유저에 대한 이해를 바탕으로 이를 분석하기 위한 환경 설계
    1-1) 유저가 유입되는 순간부터 이탈하는 순간까지 전체 flow의 로그 기록 필요 
         
 [세 가지 핵심 요소를 고려해야 함]
           사용자를 데려오기 -> 데려온 사용자들이 서비스 핵심 기능을 계속 사용하도록 하기 
           -> 과정에서 매출을 일으키기 
 
2) 데이터를 지표로 가공 : 의미 있는 지표를 추출하고 정보와 인사이트를 도출
     2-1) 지표 : 다양한 Log를 의미있고 분석 가능한 형태로 정리한 것 
           선행 지표 : 원인이 되는 지표 
           후행 지표 : 결과로 확인되는 지표 
 
대부분의 지표는 후행 지표이며, 좋은 선행 지표를 찾아내야 한다고 합니다.
  
     2-2) 지표 가공 
          a. 사용자 획득 : CAC(고객 획득 비용), MAU / WAU / DAU(월간/주간/일간 활성 사용자 수)
                                    UTM Parameters
          b. 사용자 활동 : Stickiness(서비스 의존율), Bounce Rate(이탈률),  Exit Rate(종료율) 
                                    CVR(전환율)
          c. 사용자 유지 : Retention Rate(재방문율, 잔존율)
          d. 추천 : Viral Coefficient(바이럴 계수), Viral Cycle Time(바이럴 주기)
          e. 매출 : CLV/LTV(고객 생애 가치) 
 
        [데이터 대시보드 관리] 
        -Admin, Google Sheets, Zepplin, Google Data Dashboard 등 회사/서비스에 맞는 툴 사용 
 
위와 같은 내용을 통해 무슨 데이터를 어떻게 쌓아야 할지 판단해야 합니다.
 
3) 목표 설정 
    3-1) 가장 중요한 목표 설정
    3-2) 지표 개선을 위해 어떤 것을 해야하는지
 
4) 데이터 분석 
    4-1) 인사이트 도출 
    [방법론]
    -코호트 분석 : 사용자 행동을 그룹으로 나눠 지표별로 수치화한 뒤 분석하는 기법
    -퍼널 분석 : 사용자 유입 / 전환 / 타겟 행동에 이르는 주요 경로를 파악하고,
                       각 단계별 전환과 이탈율을 측정
                       ㄴ서비스 유형/특성에 맞는 퍼널을 설계하는 것이 필요함 
    -A/B Test : 두 개의 변형 A와 B를 사용하는 종합 대조 실험
 
3번과 4번의 내용을 통해 어떤 시점에, 어떤 방식으로 데이터를 분석해야 할지 정합니다. 
 
5) SQL
데이터베이스 시스템에서 자료를 처리하는 용도로 사용되는 구조적 데이터 질의 언어를 뜻합니다.
사용자나 프로그램이 필요한 데이터를 가져오기 위해 SQL을 작성합니다.
DBMS는 DB에서 사용자가 작성한 SQL을 통해서 데이터를 가져옵니다.
사용자는 SQL을 통해서 가져온 데이터를 확인할 수 있습니다.
 
   5-1) SQL을 활용하여 데이터 분석하는 툴 
          - Spark : 데이터 정제, 처리, 요약 데이터 시각화를 할 수 있는 툴이라고 합니다.
          - Zeppelin : SQL 수행 결과를 테이블, 라인 차트, 파이 차트 등 다양한 형태로 시각화하는 툴입니다.
 
SQL과 관련해서 과거에도 관심을 가지고 공부했었는데요,
관련 포스팅은 아래와 같습니다.
 
https://mia-choi.tistory.com/7

쿼리에 대하여

 

---

 
5 PO의 기타 업무
 

  이와 관련해서는 서비스 기획자, PO가 알아야 할 웹 서비스에 대한 공부를 진행했습니다.

 1. 웹 서비스 이해 
     1-1) Front-end와 Back-end 
            a. 클라이언트 (=프론트엔드) : 네트워크에서 정보를 요구해서 받는 쪽을 말합니다. 
                a-1) 웹 프론트엔드
                       - HTML : 뼈대를 구성
                       - CSS : 디자인 적용
                       - JavaScript : 동작을 처리

            b. 서버 (=백엔드) : 정보를 제공해 주는 쪽을 뜻합니다.
                 b-1) 백엔드 
                        백엔드는 서비스에 필요한 모든 데이터를 저장하고 다루는 공간입니다.          

     1-2) API 
            프로그램과 프로그램을 연결시켜주는 매개체를 뜻해요.

     1-3) Mobile App
            a. iOS : Apple / Objective - C, Swift 로 개발합니다.
               ㄴ유료 앱 결제 전략을 가지고 있습니다.
            b. Android : Google / Java, Kotlin 으로 개발합니다.
              ㄴ무료 앱 제공 + 광고 수익 / 인앱 결제 유도 전략을 가지고 있습니다.

 모바일 앱의 특성으로는, 앱의 코드 변경을 위해서 유저가 앱스토어에 업데이트된 최신 버전의 앱을
 다운받아야 한다는 것입니다. 
 앱에서 웹을 보여줄 수 있는 웹뷰를 활용하면 앱을 재배포하지 않고 최신 페이지를 노출할 수 있습니다.

    1-4) 어플의 종류
           a. 네이티브 앱
 모바일 OS에 최적화된 SDK를 이용하여 안드로이드는 Java/Kotlin으로 iOS는 Swift / Objective-C로 

개발한 앱을 말합니다. 다른 종류의 맵에 비해 성능과 실행 속도가 가장 높고 안정적이라는 특징이 있어요.

 

          b. WebApp

앱의 형태를 가지고 있지만 실제 내용은 웹에서 구현하는 앱 서비스 입니다. 

모바일 웹과 네이티브 앱을 결합한 형태로 모바일 웹과 동일하게 HTML로 개발하지만 

모든 UI와 UX를 앱과 유사하게 제작해서 모바일로 URL 접속 시 앱처럼 작동합니다. 

 

앱을 따로 설치하지 않으므로 업데이트 시 별도의 심사가 필요없고 모든 기기와 브라우저에 접근이 가능하다는

장점이 있습니다. 

 

       c. Hybrid App

네이티브 앱의 구조를 가지고 있으나, 일부 기능들을 웹으로 구현해 개발합니다. 

네이티브 앱에 웹 화면을 띄워 웹앱을 실행시키는 것으로 네이티브 앱과 웹 앱이 섞인 서비스입니다.

 

 2. 딥 링크 (Deep Link)

특정 주소 혹은 값을 입력하면 앱이 실행되거나 앱 내 특정 화면으로 이동시키는 기능을 수행합니다. 

유형별 딥 링크가 앱을 열 수 있도록 앱과 브라우저마다 다른 딥 링크를 적용하도록 설정 및 테스트가 필요합니다.

 

    2-1. 지연된 딥 링크 

앱이 설치되어 있지 않은 경우, 앱 설치 후 실행한 이용자가 앱의 첫 화면이 아닌, 지정된 특정 앱 페이지로 이동되는

기능입니다. 광고를 통해 특정 상품 페이지로 랜딩시켜야 하는 커머스 등의 앱 서비스에서는 지연된 딥 링크 적용 여부를

확인하는 것이 필요합니다. 

 

---

 

6 애자일 캠프

 

이틀간 강의시간 동안 (6시간) 팀플을 진행했습니다.

애자일한 방법으로 팀원들과 토론하면서 과제를 해결하고, 피그마로 와이어프레임까지 작성하는 시간을 가졌습니다. 

 

  6-1. 애자일 방법론은 무엇일까요?

 

고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하는 개발 방법론을 뜻합니다.

 

  애자일 방법론에서 PO의 역할은 무엇일까요?

 

 PO는 제품을 사용할 고객과 사용자의 니즈를 수렴하여 최종 요구사항을 결정합니다. 

업계의 동향, 경쟁사의 움직임, 새로운 아이디어 등을 지속적으로 관찰하여 제품에 반영합니다. 

 

  6-2. Scrum Framework란?

 

Scrum은 비즈니스 요구를 충족시키는데 초점을 맞추기 위해, 작은 목표를 짧은 주기로 제품을 지속적으로

개발하는 관리 프레임워크를 뜻합니다.

소규모의 교차기능팀이 제품 개발을 위해 스프린트라고 불리는 업무 주기를 반복합니다.

 

   a) 스크럼 구성원 

     a1) 프로덕트 오너 : 스크럼 팀의 결과물인 프로덕트의 가치를 극대화하며, 프로덕트 백로그를 효과적으로

                                    관리하는 책임을 가집니다. 

 

     a2) 스크럼 마스터 : 스크럼을 확립하는 것에 책임을 가집니다. 스크럼 팀과 조직의 모든 구성원이 

                                    스크럼 이론과 실천법을 이해하도록 돕습니다. 

 

     a3) 개발자들 : 개발자들은 매 스프린트마다 사용 가능한 증가분의 모든 부분을 만드는 것에 전념합니다.

 

6-3. 스크럼 산출물

 

  a) 프로덕트 백로그 : 프로덕트를 향상시키기 위한 업무를 우선순위에 따라 정렬한 목록을 말합니다. 

  b) 스프린트 백로그 : 스프린트 목표, 스프린트를 위해 선택된 프로덕트 백로그 아이템들의 모음과

                                   증가분을 전달하기 위한 실행할 수 있는 계획으로 구성됩니다.

 

6-4. 스크럼 팀플 실습

 

4명이 한 조가 되어 팀을 이뤘습니다. 동일한 주제에 대한 UI / UX를 개선하는 요구사항을 받았습니다.

스크럼 팀을 구성하고 역할을 정했어요. 저희 팀은 한 명의 PO와 세 명의 개발자들로 역할이 나눠졌습니다.

저는 개발자 중 한 명의 역할을 맡아 와이어프레임을 작성하였습니다.

 

구글 시트 엑셀을 통해 프로덕트 백로그를 작성했습니다. 

PO와 개발자들은 플로우 차트를 기반으로 개선방향을 논의합니다. 

Epic, Story, A/C, Priority, Points 항목으로 정책과 관련하여 논의된 내용을 작성하였습니다.

 

또한, Jira를 통해 스프린트 계획을 세웠습니다. 

PO는 Jira에 회원가입을 한 후, 스크럼 방식으로 프로젝트를 생성합니다.

 

Jira

Jira | 이슈 및 프로젝트 추적 소프트웨어 | Atlassian

 

 

Jira를 활용한 상세 진행과정은 아래와 같습니다.

 

출처 : 지라 홈페이지

 

 

a) 백로그 메뉴에서 3명의 개발자 팀원들을 초대합니다.

b) [만들기]를 통해 Story 티켓을 생성하여 내용을 입력합니다.

c) [스프린트 만들기]를 선택하여 스프린트를 생성합니다. 

d) PO는 각 Story의 작업 담당자를 할당합니다.

e) 개발자들은 본인이 할당된 Story를 클릭하여 하위 작업(Sub Task)을 생성합니다.

 

 

출처 : 지라 홈페이지

 

 

공유된 피그마 화면을 통해 논의했던 개선방향을 활용하여 개인에게 할당된 와이어프레임을 작성하였습니다.

 

완료 후, 팀별로 발표하는 시간을 가졌습니다. 이를 스프린트 리뷰 라고 부른다고 하는데요,

각자 작성했던 와이어프레임을 하나의 피그마 페이지로 모으고 리뷰 준비를 하였습니다.

 

스프린트 리뷰 후 강사님께서 주신 피드백을 정리하였으며, 팀원들과 공유된 구글 시트에 피드백 내용을 정리하는 시간을

가졌습니다. 이러한 과정을 발전시킨다면 스프린트 회고 가 될 것 같습니다.

스프린트 회고 과정에는 개선점을 찾고 개선 계획을 수립한다고 합니다.

또한 운영 팁 관련된 내용들을 팀원과 나눈다고 합니다. 

 

---

 

프로덕트 설계 강의는 정리하는데 생각보다 오래 걸린 것 같습니다.

강의를 들었던 시간이 긴 편이기도 했고 (총 21시간), 실습 관련된 내용을 정리하는데 꽤 시간이 오래 걸렸던 것 같아요.

8월 말에 들었으니까 딱 한 달이 지난 것 같습니다. 한 달이 지났지만 기억이 보다 선명한 이유는

실습을 해보아서 그런 것 같습니다. 확실히 직접 해보는 것이 기억에 잘 남는 것 같아요.

 

사실 실습 과제를 처음 들었을 때에는 막막하고 개선할 점을 어떻게 찾아야 할지 모르겠다는 생각을 많이 했었는데요,

(특히, 정책을 세워보고 가장 좋은 선택을 해보아야 한다는 점) 

팀원들과 토론을 하면서 몰랐던 점을 알게 되고, 부족한 점을 채울 수 있어서 좋았습니다. 

 

포스팅을 하면서 복습도 되고, 앞으로 가야 할 방향에 대해서 생각해보는 시간을 가질 수 있었습니다.

이게 기록의 장점인 것 같아요. 8월에 들었던 강의에 대한 기록은 여기서 마무리하도록 하겠습니다.

 

다음 포스팅부터는 9월에 들었던 강의와 활동들에 대해 후기를 남겨보겠습니다!! :)