PM_TIL[(내배캠) PM트랙_TIL_23일차] _서비스 기획_챕터3~4-2

1. 오늘의 학습목표 

= 챕터 3 완강

= 챕터 4 절반 (4-2)까지 완강

= 데이터 셋 분석 (전제 데이터 분석 완료, 구매율, 장바구니 담기 율 별로 분석 완료)

[챕터 3]

1) PRD

• PRD는 기능 목록이 아니라 개발 기준 문서
• MVP 중심 기능 우선 개발 중요
• 요구사항은 구체적 수치로 작성 필요
• . PRD에 포함되는 핵심 구성 = 제품이나 서비스에서 제공해야 할 구체적인 기능들을 나열
  • 기능 이름 : 기능 명칭 (회원가입/ 장바구니/ 결제시스템 등)
  • 기능 설명 : 기능 역할 설명 
  • 우선순위 : 중요도 (필수 / 권장 / 선택)
  • 구현 기준 : 기능 동작 방식 

2)  IA (정보구조도)

• IA는 UX 설계의 기본 구조
• 화면보다 구조 설계가 먼저
• 기능 목록 → 카테고리 → 계층 순서 중요
•  연습 : 쇼핑몰에 들어가서 카테고라이즈 된거 살펴보고 다르게 구성 해보기

3) 서비스 정책서

• 서비스 정책서는 기능 동작 기준을 정의하는 문서, 협업을 위한 기준
• 예 ) 비밀번호 규정이나 로그인 제한 정책
• 정책이 명확해야 서비스의 일관성을 유지할 수 있음
• 법적 요구사항 대응에도 필요

4) 에러케이스 정의

• 에러케이스 작성방법
  1단계 에러 케이스 정의 : 기능별로 발생 가능한 오류 예측 (로그인 실패, 세션 만료 등) 
  2단계 에러 발생 조건 명시 : 각 오류가 발생하는 상황 정의 ( 카드 번호 오류, 만료카드 결제 시도 등) 4단계 에러 코드 정의 (선택) : 개발팀이 문제 파악을 쉽게 하기 위해 코드 작성
  3단계 에러 메시지 작성 : 사용자에게 보여줄 안내 메시지 작성 ( "비밀번호가 올바르지 않습니다. 다시 입력해 주세요." )

5) 상세기획 (스토리보드)

- 상세 기획은 실행 가능한 수준까지 기능을 구체적으로 정의하는 단계

-  기능 명세서에는 입력 값과 출력 값까지 포함해야 함
    ( 능이 어떤 조건에서 어떻게 동작하는지를 구체적으로 정의 )

- 서비스 흐름 설계 시 목표 정의, 시작점 설정, 단계 나열, 분기점 추가, 시각화 순서로 진행

[챕터 4]

1) 끊임없는 'Why'

- 5Whys 소개, 이전에 원인분석 프레임 워크 때 배원던 내용이 나와서 반가웠음

- 가설을 미리 정하지 말고 데이터 기반으로 접근해야 한다는 점이 저번강의 부터 반복되어서 나와서 중요한 개념이라고 생각됨

- 프로젝트를 진행할 때 "왜", ":어떻게", "무엇을"을 자주 생각해 보면서, 이해관계자를 설득하고 이끌어 가야한다고 생각함.

- 스파르타 부트캠프에 '왜' 왔는가?
  :  계약직 근무를 마치고, 앞으로 직무를 정해서 자리를 잡아야 겠다는 생각이 들었음. 그러던 중,
    그나마 경험이 있는 PMO경험을 살려볼 수 있는 직무가 있을 까 하고 알아보가다 PM이라는 직무에 관심이 생겼음.
     하지만 직무 특성상, 협업이나 프로젝트 관리를 해본 경험을 중요하게 보는 것 같아서 어떻게 그런 역량을 키울 수 있을까하고
     알아보다가 PM 부트캠프라는 걸 알게됨. 
      부트캠프를 들으면서 팀 협업을 경험하면서 관련 역량을 키울 수 있지 않을 까 해서 지원함

- 스파르타 부트캠프에서 '어떻게' 할 것 인가?

   :  주어진 과제 및 프로젝트에 최선을 다하는 것은 기본이고, 주기적이로 바뀌는 팀원들과 원활하게 협업하기 위해 
     날선 말투나 까칠하게 반응하지 않고, 적극적이고 긍정적인 태도로 임할것이다.
      매일 평균 10시간은 주어진대로 학습/협업 할 예정이며, AI에 의존하기 보다는 스스로 생각 해보면서
     문서화 하는 능력을 연습해 보려고 한다.
      주어진 커리큘럼에 최대한 빠지지 않고 다 참여할 예정이고, 질문이 필요할 떄 명확한 질문지를 작성해서
     튜터님을 찾아가는 연습을 할 것이다.

- 스파르타 부트캔프에서 "무엇을"할 것인가?

   :  개인과제를 성실히 수행, 4월내로 도메인 확정 및 포트폴리오에 어떤걸 담아야 할지 생각해보기.
     주말에 2~3시간씩 활용해서 포트폴리오 작성 연습 및 주간 스케줄 설정,
     질문하는 연습/ 스스로 생각하는 연습 해보기

2) 커뮤니케이션의 중요성

• 커뮤니케이션은 단순한 소통이 아니라 프로젝트 성공을 위한 핵심 요소
• 팀과 협업할 때 전달 방식이 달라야 함
• 커뮤니케이션을 할 때, 요구사항/ 목표/ 의도 명확하고 간결하게 하며, 오해는 최소화하기
  => 회의 내용을 전달항 때는 불필요한 내용은 생략하고, 중요한 내용을 전달하는 연습이 필요
       (목표, 각 역할, 타임라인, 다음회의 일정 = 이 정도만!)
• 공감과 역지사지의 입장 필요 = 의견충돌 발생 했을 때, 적절하게 조율하는 능력이 필요
• 상대방의 말을 주의깊게 듣기
  무언가 내용을 전달하고자 할 때는 핵심메세지로 한문장으로 요약+ 그 이후에 세부사항을 덧붙이기

=> 보여주신 영상에서 "하트만들기"의 예시가 상당히 인상깊었음. 

  - 이거 듣고, 실무 경험이 떠 올랐다.

    PMO로 근무할 때, 감독자가 중간에 바뀌었는데, 항상 이야기를 두루뭉실하게 해서 협업할 때 상당히 어려웠던 기억이 있었다.

     => 이렇게 해서 저렇게 해주세요 이런식이 아니라,
          "알아서 보기좋게 해 주세요. 뭔 말인지 알죠?" 이런식으로 설명해서 상당히 곤횩이 있었던 경험이 있다.

          이럴 때, 일단 초안 하나를 대충 만들어 가서 깨지든 뭐든 부딫혀 봤고,
          몇번 반복하면서 감독자의 문서 스타일을 체득해 가면서 해결했던 경험이 있다.
          약간  MVP만들어서 계속 업데이트 해서 완성해가는 과정과 비슷하다고 생각했다.

[데이터 셋 분석하기]

- 데이터 셋 분석해서 HTML로 만들고 깃허브 이용해서 URL로 만듬

GitHub Desktop - index.html 배포하기

이거 활용해서 길허브로 만듬

https://soyeon822.github.io/free-homepage/

https://soyeon822.github.io/free-homepage/

 

2. 오늘의 인사이트

1.PRD
PRD(제품 요구사항 정의서)의 모든 것ㅣ뜻, 작성 방법, 포함 요소 - 코드스테이츠 공식 블로그

좋은 제품을 만들기 위한 PRD 작성법과 샘플

1) PRD : 제품을 만들거나 업데이트하기 위해 기능을 기획하는 단계에서 요구사항을 개괄적으로 설명하는 문서

2) 작성방법 (  WHY 기반의 문서 작성 방법 )

• 1. 사용자 문제 및 비즈니스 우선순위 결정의 근거를 포함할 것
  (사용자 조사결과, 다양한 옵션에 대한 토론과 평가, 기술적 한계, UX 고려 사항, 리소스 및 예산,
    타임라인 요구 사항 등 )
• 2. 해결 방안에 대한 세부 정보를 추가할 것
  ( 사용자 조사 결과를 확인할 수 있는 문서, 다양한 옵션이나 아이디어에 관해 토론한 회의 내용,
     기술적 한계, UX 고려 사항, 리소스 및 예산 제약, 타임라인 요구 사항 등 )
• 3. 구축해야 할 기능과 목적을 명확히 하고 UX 및 개발 설계 문서를 참조할 것
• 4. PRD를 업데이트하여 기능 범위를 결정할 것
  ( UX 및 개발 설계 문서와 중복되지 않도록 )
  ( 중요한 결정과 절충안, 기술적 고려 사항, 다른 팀에 대한 종속성, 사용자 개인정보 보호 또는 법적 문제 등을 명시 )
• 5. 다른 사람들과 공유하여 의견을 구할 것
• 6. 개발 중에도 PRD를 계속 업데이트할 것

 3) 구성요소 7가지

• 1. 제품 개요 (요약과 배경)
  = 어떤 문제를 왜 해결해야 하는지 목적과 근거를 작성.(설문, 인터뷰, VOC, 시장 변화 등)
• 2. 비즈니스 목표 혹은 지표
  = 개발 이유와 기대 성과를 작성 ( 비즈니스 목적 → KPI 설정 → 목표 수치 순서로 구체화)
• 3. 핵심 고객 또는 사용자 정의
  = 제품을 사용할 사용자가 누구인지, 어떤 문제를 겪고 있는지
• 4. 핵심 사용자 여정(CUJ) / 사용자 스토리(User Story)
  = 사용자가 제품으로 목표를 달성하는 흐름
  = 해결 방안 < 사용자 요구
  = User Story 형식: "나는 ~를 위해 ~를 원한다."
• 5. 기능적 요구 사항
  = 구현해야 할 기능 목록과 우선순위
  = Must Have: 없으면 사용 불가한 핵심 기능
     Should Have: 필수는 아니지만 매우 필요한 기능
     Could Have: 있으면 좋은 선택적 기능
• 6. 프로젝트 일정 및 배포 계획
  = 팀원, 이해관계자, 의사결정권자와 함께 수립.
  = 마케팅·영업·CS 등 유관부서도 일정에 맞춰 준비할 수 있도록 공유.
• 7. 기타 참고 문서
  = 와이어프레임, 스토리보드, UX 리서치 결과, 트렌드 레퍼런스 등 첨부.
  = 팀원 정보, 진행 상태, Q&A 등

2. 정보구조도

웹, 모바일을 위한 I.A(Information Architecture, 정보구조도)

1. IA(정보 구조도)란? 서비스의 목차와 같은 개념
- 서비스의 전체 구조를 정리하는 문서, 웹사이트나 앱이 어떻게 구성되어 있는지 한눈에 보여주는 역할

2. IA 작성 시 고려 요소

1) User (사용자) : 사용자의 기존 경험을 분석하여 구조를 설계
 = > 사용자가 어떤 경험을 가지고 있는지, 서비스에 왜 방문하는지, 이용 중 어떤 패턴을 보이는지

즉 사용자 행동을 기반으로 메뉴 구조와 정보 구조를 설계해야 한다.

2) Contents (콘텐츠) :

- 공급자 중심이 아니라 사용자 중심으로 구성, 사용자가 익숙하게 인지할 수 있는 네이밍을 사용

- 기존 사용 경험과 맞는 구조로 설계

3) Scenario (시나리오) : 정보가 전달되는 흐름을 고려하여 설계
- 사용자가 어떤 순서로 정보를 확인하고 기능을 이용하는지를 기반으로 구조를 설계

3. 서비스 정책서

[정책 기획] 서비스 정책서 작성하기

[제로베이스 PM스쿨 18기 학습일지 #11] Ch 10. 서비스 정책서와 요구사항 정의서(PRD)

1. 서비스 정책서 작성 시 고려사항

• 불가항력적인 요소 고려
  - 관련법령 고려, 산업생태계와 인프라 고려,
  - 경쟁사 고려, 내부 환경과 리소스 고려

2. 서비스 정책서 작성하기

- 모든 정책을 한 번에 정리하는 것은 매우 어려우므로
경쟁사의 이용약관, 개인정보 처리방침, 서비스 정책 등을 분석하며 필요한 법령과 정책을 도출해야 함

- 프로젝트 진행 과정에서 필요한 정책을 추가하면서 점진적으로 관리하기

4. 에러케이스

알잘딱깔센 에러 메시지 쓰는 방법

좋은 에러 메시지를 만드는 6가지 원칙

 

5. 스토리 보드

https://basicplan.tistory.com/entry/%EC%95%B1%EC%9B%B9-%EC%84%9C%EB%B9%84%EC%8A%A4-%EA%B8%B0%ED%9A%8D%EC%9E%90%EB%A5%BC-%EC%9C%84%ED%95%9C-%EC%8A%A4%ED%86%A0%EB%A6%AC%EB%B3%B4%EB%93%9C-%EC%9E%91%EC%84%B1-%EC%99%84%EB%B2%BD-%EA%B0%80%EC%9D%B4%EB%93%9C

1. 스토리보드 : 사용자가 서비스를 이용하는 전체 여정을 시각적으로 표현한 문서

2. 스토리보드 작성 전 준비 과정

1) 사용자 리서치 및 페르소나 설정
  = 직무, 관심사, 사용 환경 등을 정의하여 실제 사용 상황을 기반으로 설계

2) 서비스 목표 및 핵심 가치 정의  
  = 서비스가 해결하려는 문제와 제공하려는 가치를 명확히 정의

3) 사용자 시나리오 작성  

  = 페르소나 기반으로 실제 사용 상황을 시나리오로 작성  

   ( 사용자가 언제, 어떤 상황에서 서비스를 사용하는지 )

 

3. 스토리보드 작성 단계

1) 핵심 기능 정의 및 우선순위 설정

모든 기능을 동시에 구현할 수 없기 때문에 MVP 관점에서 핵심 기능과 추후 기능을 구분.

2) 정보 구조 설계

서비스 전체 구조를 트리 형태 또는 사이트맵 형태로 설계 

3) 핵심 화면 와이어프레임 작성

주요 화면 레이아웃을 간략하게 스케치 // 디자인보다는 기능과 구조에 집중

4) 사용자 플로우 정의

화면 간 이동 흐름과 사용자 경로를 정의 // 예외 상황도 고려

5) 스토리보드 템플릿 구성 및 작성

실제 문서 템플릿을 만들고 화면별 상세 내용을 작성

 

4. 스토리보드 필수 포함 요소

• 화면 정보 : 화면 ID, 화면명, 화면 유형
• 시각적 요소: 와이어프레임, 화면 흐름도, 인터랙션 표시
• 설명 요소 : 화면 설명, 사용자 액션 리스트, 시스템 반응, 데이터 요소, 예외 처리

5. 스토리보드 작성 팁

사용자 중심 설계 : 기술보다 사용자 경험 흐름을 우선 고려해야 한다.

단계적 상세화 : 처음부터 완벽하게 작성하기보다 점진적으로 구체화하는 것이 효율적이다.

반복 개선

스토리보드는 작성 후에도 피드백을 반영하여 지속적으로 수정해야 한다.

스토리보드는 한 번에 완성되는 문서가 아니라 반복적으로 개선되는 문서이다.

 

3. 오늘의 느낀점/회고

• 잘한점

- 목표로 설정한 학습 범위를 끝까지 완료한 점

- 강의 내용만 듣지 않고 추가 아티클과 자료를 찾아보며 보완한 점

- 강의 내용을 단순 정리가 아니라 개인 경험과 연결하여 이해하려고 노력한 점

(Why/What/How 구조로 스파르타 부트캠프 참여 목적과 학습 방향을 스스로 정리해 봄)

(커뮤니케이션 사례 영상을 보고 실제 경험과 비교하며 문제 원인을 생각해 봄)

- 데이터 셋 분석한 점 (전체 데이터 그래프 분석 및 장바구니 담기율, 구매율 분석)

• 아쉬운점 :

- 학습 시간이 남아 있었음에도 추가 강의를 진행하지 못하고 휴식 시간을 길게 가진 점 

- 개념 정리에는 시간을 많이 사용했지만 추가 실습까진 이어지지 않은 점

- 학습 내용을 정리하는 데 집중하면서 실제 적용이나 활용까지 연결하지 못한 점

• 원인분석 :

- 학습 계획을 너무 여유롭게 설정하여 남는 시간이 발생함

(평소에 강의를 들으면서 학습노트를 적어서, 강의 시간의 약 2배 정도 학습시간이 드는 편임

 그러나 이번에는 내용이 많이 어렵진 않아서 시간이 별로 안 들었음)

- 남는 시간에 수행할 추가 학습 계획이 사전에 준비되어 있지 않았음

- 거의 한 자리에 계속 앉아서 학습을 진행하다 보니 목표 달성 이후 피로도가 상승하여 추가 학습을 이어가기 어려웠음

• 개선사항 (액션포인트) :

- 학습 계획 수립 시 예상 학습 시간 외에 추가 학습 시간을 포함하여 계획을 세우기 (보조 학습 목표 1개 설정)

- 1시간 정도 학습을 했으면 10분정도는 쉬는시간을 가지기