제품관리/제로베이스 PM 파트타임 스쿨

[제로베이스 PM 파트타임 스쿨] 4주차 - 6장 서비스 기획자의 역할 & 7장 프로젝트 관리 방법

곰PM 2025. 4. 22. 21:46

【최종수정시각】 2025. 04. 23. 19:37

 

 

목차

     

     

    6 서비스 기획자의 역할

    6.1 서비스 기획자란?

    • 서비스 기획자
      • 사용자의 니즈를 발굴하고 이를 해결하기 위한 방안을 설계하며, 이를 서비스를 통해 증명하는 사람
      • 테크(Tech.), UI/UX, 비즈니스의 교집합에 위치
    • 서비스 기획자의 주요 업무
      1. 서비스 기획: 서비스의 목표를 설정하고 실현하기 위한 프로젝트 전반을 담당
        • 시장 리시처
        • IA 설계
        • 화면 설계
        • 기타 등등
      2. 기술 기획: 서비스 출시를 위해 적용할 기술의 검증 및 적용 범위 검토
        • 스펙 정의
        • 리뷰 및 회고
        • QA
        • 기타 등등
      3. 운영 기획: 서비스의 원활한 운영을 위한 장애대응, CS응대 등의 지원 업무
        • 서비스정책 정의
        • CS 관리
        • 장애대응
        • 기타 등등
      4. 데이터 기획: 서비스 운영 및 개선을 위한 로그 설계, 운영, 데이터 추출 및 분석
        • 로그 설계
        • 데이터 추출
        • 데이터 분석
        • 기타 등등
    • 조직 성격별 서비스 기획자 역할
      1. 제품 개발
        • 가장 일반적인 형태
        • 외부 사용자의 니즈를 정제하여 제품 방향성을 설정
        • 비즈니스 관련 팀과 논의를 통해 피처 리스트 정리
      2. 내부 제품 개발
        • 내부 제품 개발 시 취하는 형태    예) 인하우스 대시보드
        • 사용자가 내부에 위치하고 있어 니즈 파악이 용이
        • 커뮤니케이션 비용이 가장 낮은 형태
      3. 외부 제품 개발
        • 내부에 개발팀이 없거나 외주를 통한 개발팀을 운영하는 형태
        • 내부에서 피처 리스트를 정리하여 외부 개발조직에게 전달
        • 커뮤니케이션 비용이 가장 높은 형태

    6.2 서비스 컨셉과 방향성 도출하기

    • 서비스 컨셉: 어떤 작품이나 제품,공연, 행사 따위에서 드러내고자 하는 주된 생각
      • "넷플릭스는 스트리밍 서비스로서 여러 시상식에서 수상한 다양한 TV 프로그램, 영화, 애니메이션, 다큐멘터리 등등 수 많은 콘텐츠를 보유하고 있으며 다양한 맴버십 제도를 제공함으로써 고객에게 합리적인 가격에 서비스를 제공합니다." → 모두 맞는 말이지만, 장황 → 나쁜 컨셉
      • "영화, TV 프로그램을 무제한으로" → 좋은 컨셉
    • 서비스 컨셉 설계 단계
      1. 문제의식 발굴
        • 시장 트렌드
        • 서비스 모니터링
        • 개인의 경험
      2. 문제의식 검증
        1. 데이터 추출 및 분석
        2. 리서치
        3. 벤치마킹
      3. 개선사항 도출
        • 문제해결 방안 초안 설계
        • 구현 가능성 검토
      4. 서비스 컨셉 설정
        • 서비스 설계를 위한 가설 설정
        • 서비스 제공 가치의 정의
    • 서비스 컨셉 설계 시 고려사항
      1. 획득(Acquistion)
        • 현재 사용자가 어떻게 서비스를 접하고 있는가?
        • KPI: 트래픽, DAU, MAU 등
      2. 활성화(Activation)
        • 사용자에게 좋은 경험을 제공하고 있는가?
        • KPI: CAC, CPC, 이탈률 등
      3. 유지(Retention)
        • 서비스 재사용률은 어떻게 되는가?
        • KPI: 재방문 수 등
      4. 추천(Referral)
        • 서비스가 자발적 확신이 이루어지는가?
        • KPI: 공유 횟수, 초대코드 입력 횟수 등
      5. 매출(Revenue)
        • 서비스가 매출을 창출하고 있는가?
        • KPI: 서비스별 상이

    6.3 기능 조직과 목적 조직

      기능 조직 (Component Team) 목적 조직 (Feature Team)
    뜻 단일 직군으로 구성된 조직 기획, 개발, 디자인, 사업 등 다양한 직군으로 구성된 조직
    목표 가능한 많은 업무를 처리 가능한 많은 고객 가치를 전달
    운용 방식 워터폴 선호 애자일 선호
    업무 범위 복수 프로젝트 동시 수행 및
    각 프로젝트의 일부 담당    		 단일 프로젝트 집중 수행 및
    그 프로젝트의 전반 담당
    규모 대규모 및 점차 확대 소규모 및 유지
    타 조직과의 연관성 큼 작음
    실행 난이도 상대적으로 쉬워 보임 상대적으로 어려워 보임

    표 6.1 기능 조직과 목적 조직 간 차이점

     

    • 기능 조직 속 서비스 기획자의 역할
      • 주로 운영 중인  제품에 대한 기능 개선이 필요한 경우에 배치됨
      • 기획자는 각 기능을 하나의 프로젝트 단위로 할당받음
      • 제품의 방향성 및 요구사항은 정해져 있는 경우가 많음
      • 각 담당 기능의 구현에 집중하는 형태
      • 각 인원이 복수의 프로젝트를 담당하게 되는 경우가 많음
    • 목적 조직 속 서비스 기획자의 역할
      • 신규 프로젝트 혹은 TF 형태에서 많이 보이는 형태
      • 기획자는 하나의 제품 단위로 프로젝트를 할당받음
      • 제품의 방향성 및 요구사항 설정 필요
      • 제품 내 각 기능 간의 상호관계 고려 필요
      • 각 인원은 하나의 프로젝트에 집중하는 경우가 많음

     

    6.4 사용자향 서비스 vs 사업자향 서비스

    • 사용자향(B2C) 서비스
      • 일반 개인이 사용하는 서비스
      • 고객이 사용 가치를 느끼는가?
      • `KakaoTalk`(커뮤니케이션), `Steam`(게임), `배달의민족`(음식), `toss`(금융), `Amazon.com`(쇼핑) 등
    • 사업자향(B2B) 서비스
      • 사업자가 특정 목적을 위해 사용하는 서비스
      • 고객의 사업 활동에 어떤 도움이 되는가?
      • `Slack`(커뮤니케이션), `Unity`(게임), `식권대장`(음식), `Gusto`(금융), `Shippo`(쇼핑) 등
    • B2B2C 서비스: 확보된 사용자 층을 대상으로 사업자가 사업을 전개할 수 있드록 특정 기능을 제공하는 비즈니스 모델
      • `KakaoTalk` - `KakaoTalk Channel` (CRM)
      • `Naver` - `Naver Store` (스토어)
      • `배달의민족` - `배민 사장님` (주문관리)

    6.5 B2C 서비스란?

    • 개인 사용자에게 특정 가치를 제공하고 그에 대한 대가를 받는 서비스
    • 예시
      • 커뮤니케이션: `KakaoTalk`, `Facebook` 등
      • 음식: `배달의민족`, `FreshCode` 등
      • 전자상거래: `네이버쇼핑`, `Coupang`, `TMON` 등
      • 콘텐츠: `네이버웹툰`, `Netflix` 등
      • 주거: `오늘의집`, `호갱노노` 등
    • B2B 서비스의 사업 모델
      1. Free Pricing
        • 사용 대가를 받지 않는 사업 모델
        • 사용자를 모으기 쉬우나, 수익 구조가 불안정한 사업 모델
        • `KakaoTalk`, `Naver`, `Facebook` 등
      2. 'Pay at Time' Pricing
        • 사용 대가를 받고 사용 권한을 부여하는 사업 모델
        • 사용자를 모으기 어려우면서, 수익 구조가 불안정한 사업 모델
        • `PlayStation Store`, `Google TV`, `Ringle` 등
      3. 'Subscription' Pricing
        • 사용 대가를 구독료 형태로 받는 사업 모델
        • 수익 구조가 안정적이나, 사용자를 모으기 어려운 사업 모델
        • `Netflix`, `watcha`, `Melon` 등
      4. 'In-app Pay' Pricing
        • 각 사용자가 자율적으로 서비스(앱) 내에서 (추가)결제를 하는 사업 모델
        • 사용자를 모으기 쉬우면서, 수익 구조가 안정적인 사업 모델  
        • `Zepeto`, 대다수의 모바일 게임, `네이버웹툰` 등

    6.6 B2B 서비스란?

    • 사업자가 비즈니스를 운영하는데 필요한 기능을 제공
    • B2B 서비스의 발전
      • 한정된 한경 혹은 자원을 필요로 하지 않는 형태로 발전
      • 설치형 → 다운로드형 → 클라우드형
    • 예시
      • 결제: 페이팔, 애플페이, 네이버페이 등
      • 포장: 루미, 템퍼팩, 슐라팩 등
      • 배송: Fulfillment by Amazon, 쉬포, CJ대한통운 등
      • 문서: MS 오피스, 어도비 등
      • 사입: 쉐어그라운드, 셀엡 등
      • 재고 관리: 쿠팡풀필먼트서비스, Fulfillment by Amazon 등
      • 직원 관리: 구스토, 패트리어드, 리플링 등
      • 마케팅: 카카오톡, 네이버, 인스타그램 
    • aaS(as-a-Service)의 종류
      1. IaaS (Infrastructure-as-a-Service)
        • 종량제 서비스로 제3사가 스토리지 같은 인프라 서비스를 인터넷을 통해 클라우드로 제공
        • 가상화(virtualization), 서버(servers), 저장공간(storage), 망 연결(networking) 등을 관리
        • `Amazon Web Service`, `Microsoft Azure` 등
      2. PaaS (Platform-as-a-Service)
        • 서비스를 개발할 수 있는 안정적인 환경(platform)과 응용 프로그램을 개발할 수 있는 API까지 제공
        • 실행시간(runtime), 미들웨어(middleware), 운영체제(Operating System), 가상화(virtualization), 서버(servers), 저장공간(storage), 망 연결(networking) 등을 관리
        • `Salesforce`, `Heroku` 등
      3. SaaS (Software-as-a-Service)
        • 클라우드 환경에서 동작하는 응용 프로그램을 클라이언트에게 서비스로 제공하는 형태
        • 응용 프로그램(applications), 데이터(data), 실행시간(runtime), 미들웨어(middleware), 운영체제(Operating System), 가상화(virtualization), 서버(servers), 저장공간(storage), 망 연결(networking) 등을 관리
        • `Sendbird`, `Dropbox` 등

    6.7 사용자향 서비스의 기획자 vs 사업자향 서비스의 기획자

    1. 기획자의 관점
      • B2C 서비스 기획자의 관점
        • 사용자 동선 중심
        • 데이터, 개인의 경험 중요
      • B2B 서비스 기획자의 관점
        • 비즈니스 프로세스 중심
        • 도메인 지식, 전문성 중요
    2. 고객과 사용자
      • B2C 서비스의 고객과 사용자
        • 기획자 스스로가 사용자인 기획
        • 구매자와 사용자가 동일
        • 폭발적 성장
      • B2B 서비스의 고객과 사용자
        • 특정 그룹의 고객을 위한 기획
        • 구매자와 사용자가 다름
        • 꾸준한 성장
    3. 릴리즈 주기
      • B2C 서비스의 릴리즈 주기 → 기능 중심 개선 지향
        • 신규 기능 도입에 대한 사용자 수용력이 좋음
        • UX 개선 등의 업데이트가 비교적 자주 있는 편
        • 업데이트 주기는 촘촘하기 진행
        • 일괄 업데이트에 대한 부담감이 상대적으로 적음
      • B2B 서비스의 릴리즈 주기 → 점진적 개선 지향
        • 신규 기능 도입에 대해 테스트, 직원 교육 등 사용자 비용 발생
        • 신규 기능 도입 시 기존 사용성을 해치는 동선을 배제하는 편
        • 일괄 업데이트 시 사용자 적응에 대한 부담감이 상대적으로 큼

    7 프로젝트 관리 방법

    7.1 프로젝트 우선순위 설정의 필요성

    • 프로젝트 실패 요인에 대한 설문에서 '조직 우선순위의 불안정' 최다 선택

    그림 7.1 프로젝트가 실패하는 요인에 대한 통계 | 출처=제로베이스 PM 파트타임 스쿨

    • 조직의 자원은 한정 → 모든 요구사항 반영 불가능 → 명확한 우선순위 설정 要
    • 제품의 컨셉을 구현에 가장 필요한 기능, 즉 킬러 피처(Killer Feature) → 우선순위 설정의 기준
    제품(서비스) 컨셉 킬러 피처
    `카카오톡(KakaoTalk)` 커뮤니케이션 메시지 전송
    `인스타그램(Instagram)` 이미지 공유 이미지 업로드
    `에어비앤비(Airbnb)` 숙소 중개 객실 예약
    `링크드인(LinkedIn)` 비즈니스 프로필 공유 프로필 작성
    `넷플릭스(Netflix)` OTT(over-the-top) 미디어 영상 재생

    표 7.1 유명 제품(서비스)의 킬러 피처 예시

    7.2 프로젝트 우선순위 설정 방법

    • MoSCoW → 애자일 방법론 기반 프로젝트에서 자주 사용
      • Must-have: 필수(없으면 제품의 성공이 불가능한) 기능   
      • Should-have: 필수인 것은 아니나 가급적 있어야 하는 기능
      • Could-have: 있으면 좋은(성공 여부에 큰 영향을 주지 않는) 기능
      • Won't-have: 있을 이유가 딱히 없는 기능
    •  워킹 스켈레톤 (Walkingf Skeleton) → MVP 개발에 자주 사용 
      • 사용자 스토리에 순위 책정 필요
      • 완전하게 독장하는 제품의 형태를 갖고 있어야 함
      • 비즈니스를 충분히 내포해야 함
    • RICE
      $$
      \text{RICE 점수} = \frac{R \times I \times C}{E} \quad \begin{cases}
      R &:\ \text{ reach (도달} \ \text{범위)} \\
      I &:\ \text{ impact (영향)} \\
      C &:\ \text{ confidence (신뢰)} \\
      E &:\ \text{ effort (노력)}
      \end{cases}
      $$
      • Reach(도달 범위): 특정 기간 동안 이 기능을 사용할 수 잇는 사용자 수를 반영 (DAU, MAU 등)
      • Impact(영향): 절대적인 기준을 제공하지 않으며 상대적인 점수를 책정
      • Confidence(신뢰): 구현하고자 하는 기능이 얼만큼 사용자에게 혜택을 줄 수 있는지에 대한 추정값
      • Effort(노력): 각 담당자의 리소스 소요 시간을 나타냄

    7.3 프로젝트 프로세스의 관리

    • 관리 관점에서의 프로젝트 프로세스
      1. 요구사항 정리: 상위 기획서 작성 → w/ 경영진, 사업팀, 개발팀
      2. 개발 필요사항 정리: 백로그 작성 →  w/ 경영진, 사업팀, 개발팀
      3. 리소스 산정: WBS 작성 → w/ 개발팀
      4. 프로젝트 운영: 간트 차트 작성 → w/ 개발팀
    • 백로그(backlog): 제품/서비스에의 방향성에 부합하는 결과물을 만들기 위한 To Do List
      1. 서비스 요구사항 결정
      2. 백로그 초안 작성
        • 사용자 스토리 ID
        • 사용자 스토리 분류
        • 사용자 스토리 정의(내용)
        • 제약사항: 사용자 스토리의 예외 경우
        • 상세: 사용자 스토리를 구현하기 위해 필요한 작업
        • 우선 순위: 각 사용자 스토리 구현 순서
      3. 백로그 리뷰
      4. 백로그 검토
      5. 개발 준비
      6. 일정 산정
    • WBS(Work Breakdown Structure): 프로젝트의 범위와 최종 산출물을 기준으로 세부 요소로 분할한 문서
      • 프로젝트 수행을 위한 업무 식별
        : 프로젝트 구현을 우한 작업 단위를 세분화 → 작업 누락 등으로 발생하는 비용 낭비 예방
      • 일정 계획 및 산정
        : 직무 할당표를 설정 → 담당자 식별 및 소요기간 수집 용이
      • 팀간 의사소통
        : 전체 작업범위도 포함 → 방향성 및 진행상황 공유 용이
    • 간트 차트(Gantt Chart): 업무 일정의 시작과 끝을 막대 그래프 형태로 표기하여 전체 일정을 한눈에 볼 수 있게 하는 도표
      • 프로젝트 관리
        : 팀원 간 협업 증진 및 개발 일정의 병목 원인 확인 및 개선 용이
      • 작성 틀
        : 내부에 사용하는 프로젝트 관리 툴(Atlassian 社의 Jira 등)의 경우 간트 차트를 제공, 각 웨크패키지를 등록하는 과정에서 자연스럽게 간트차트가 생성 (Jira Plans)

    7.4 프로젝트 진행을 위한 위한 커뮤니케이션

    1. 수직적 커뮤니케이션 → 상위 의사결정권자
      • 상위 기획서
        • 현황 분석 및 동기부여
          : 현 시장 상황 분석 및 제품의 구현 방향 기술
          예) "헤어샵 예약의 경우 독점적 경쟁자가 없으며, 예약 관련 프로세스를 편리하게"
        • 목표
          : KPI를 기준으로 구현하고자 하는 서비스의 목표 기술
          예) 사용성에 기반한 알림 메시지를 통한 소비향 리마인드 제공
        • 유저 시나리오
          : 페르소나를 설정하고 해당 유저의 사용 동선 기술
          예) "20대 남성이 지난 이용으로부터 n달이 지나면 알림 메시지를 수신하여 재예약"
      • 서비스 구현 방향 변경
      • 조직간 이슈 보고
    2. 수평적 커뮤니케이션 → 실무자
      • 상세 기획서
        • IA
          : 구현하고자 하는 서비스 혹은 제품의 전체 설계도
        • 와이어프레임
          : 서비스 및 제품의 사용자 동선을 고려한 UX 시안 정의
        • 상세 스펙
      • 일정 관리
        • 간트 차트
      • 사용자 요구사항 청취
    3. 외부 커뮤니케이션
      • 제품 홍보 페이지
        • 제품 특징
          : 장점 혹은 타사 제품과의 차별성 제세
        • 이용 가이드
          : 제품 설명 밑 이용 방법 설명
      • 고객 관리
        • 고객센터
          : 고객의 문의사항에 대한 대응 가이드 작성 및 제시
        • 공지사항
          : 신규 제품 출시 혹은 업데이트 시 고객에게 공지
      • 리서치
        • 사용성 분석
          : 기존 고객의 사용 데이터를 추출하고 분석하여 개선점 도출

    7.5 커뮤니케이션을 위한 용어 정리

    1. UI/UX
      • 드롭다운 리스트: 화살표를 누르면 숨어있는 항목들이 아래로 펼쳐지며 원하는 항목을 선택할 수 있도록 하는 요소
      • 콤보박스: 입력 필드에 직접 정보를 입력하거나 나열된 항목 중 하나를 선택할 수 있도록 하는 요소
      • 버튼
        • Active: 클릭 가능한 버튼이며 아직 클릭 전인 상태
        • Hover: 마우스를 올린 경우
        • Click: 클릭할 때
      • 라디오 버튼: 선택 옵션 중 하나의 항목만 선택할 수 있도록 하는 요소
      • 체크박스: 동시에 여러 개를 선택할 수 있도록 하는 요소 
      • 입력 필드(텍스트 상자): 직접 텍스트를 입력하는 영역
      • 토글 버튼: 여러 개의 옵션 중 하나의 선택지만 선택 가능한 옵션으로, 각 선택지를 버튼 형태로 제공
      • 토글 스위치: 주로 모바일에서 사용되며, 주로 선택지가 양자택일로 제공됨
      • 스피너: 직접 입력하거나 필드옆 화살표를 눌러 값 조절
      • 슬라이더: 최솟값, 최댓값을 시각적으로 인지하여 드래그를 토해 값 조절
      • 프로그레스 바: 시각적으로 진행상황을 보여주는 요소
      • 툴팁: 마우스 오버 시 해당 영역에 대한 설명이 말풍선 형태로 나타나고 사라짐
      • 노티피케이션: 사용자가 확인하지 않은 정보가 있는 경우, 아이콘 형식으로 알려주는 알림
      • 얼럿: 무언가를 진행하기 전에 확인이나 승인을 필요로 하는 상황을 사용자에게 알려주는 창
      • 팝업: 사용자로부터 단일 선택을 요구하는 대화상자의 가벼운 형태의 창
    2. 개발
      • API (Application Programming Interface): 서버와 데이터베이스의 출입구 역학을 하며, 허용된 인원에 대하여 데이터베이스에 접근할 수 있는 권한 활용에 대한 권한을 부여함
        • Private API: 주로 사내 내부에서 사용되는 API로, 자체 제품과 서비스 개선을 위해 발행되며, 제3자에게 노출되지 않음
        • Public API: 개방형 API로, 모두에게 공개됨
        • Partner API: 데이터 공유에 동의하는 특정인들만 사용하는 API로, 비즈니스 파트너간 스프트웨어 통합하기 위해 사용됨
      • 애플리케이션(Application): 사용자가 서비스 혹은 제품을 사용하기 위해 제공되는 형태 
        • 네이티브 앱: 스마트폰 운영체제에 맞춰 개발된 프로그램으로, 주로 `Google Play`, `Appstore`의 정책에 맞춰 개발
        • 웹 앱: 링크를 통해 접근이 가능하며 별도의 운영체제의 프로그램이 아닌 웹 브라우저를 통해 접근 가능
        • 하이브리드 앱: 네이트브 앱과 웹 앱의 혼합 형태로, 네이티브 앱의 안정과 웹 앱의 유연성을 모두 가진 형태로, 주로 앱의 기본 틀은 네이티브 앱로 구현하되 특정 영역에 대해서는 웹 브라우저를 통해 웹 앱으로 노출
      • JSON: HTTP 요청에서 사용되는 데이터 형식
      • Cookie: 클라이언트 로컬에 저장되는 데이터 파일로, 일정 시간 동안만 사용자의 클라이언트에 해당 데이터를 저장
      • Session: 쿠기를 기반으로 하지만, 사용자 정보를 서버에서 관리하여 브라우저를 통해 웹서버에 접근한 시점부터 종료 시점까지 유지

    7.6 프로젝트 완료 후

    1. 서비스 운영
      • CS 응대 → 사업팀, 운영팀
        • 고객의 요청사항에 대한 답변
        • 서비스 정책 기획
        • 파트너사 관리
      • 개발 관리 → 개발팀
        • 서비스 업데이트 버전 관리
        • 장애 대응
        • 고객문의 확인
      • 데이터 분석 → 개발팀
        • 데이터 추출
        • 데이터 분석
        • 대시보드 기획
      • 어드민 기획 → 운영팀, 개발팀
        : 서비스 운영에 필요한 기능을 추가한 페이졸, 주로 권한 관리, 매출 관리, 통계 등의 기능을 지닌다.
        • 운영팀 요청사항 반영
        • 어드민 관리
    2. 프로젝트 회고
      : 프로젝트 참여자 전원과 함께 진행하면서 겪은 본인의 소감 및 개선필요사항 등을 공유함으로써 다음 차수 프로젝트 프로세스 개선을 이루어내는 과정
      • KPT 회고 방법론
        : 팀원들의 의견을 Keep/Problem/Try로 범주화하여 명시함으로써 프로젝트 회고를 진행하는 방법
        • Keep
          : 프로젝트 진행 시에 좋았던/잘했던 부분이며, 다음 차수에서도 유지되어야 하는 부분
        • Problem
          : 프로젝트 진행 시에 잘 되지 않은/못했던 부분이며, 다음 차수에서 개선되어야 하는 부분
        • Try
        • : Problem에서 확인된 내용을 개선하기 위해 취할 수 있는 조치

    ※ 이 글은 제로베이스 PM 파트타임 스쿨의 강의 자료 일부를 발췌하여 작성되었습니다.