특강) 입문과제 우수사례 분석 - 평가자는 무엇을 높게 평가했을까?(+ 과제 제출 파일)

• 리뷰 분석 / 문제 정의 / 우선순위 선정 / 가설 검증 ▼

+) 오늘의 인사이트 + KPT 회고

[게시글 목차]

1. 평가 기준 살펴보기

2. 리뷰 데이터 분석

3. 문제 원인 분석

4. 우선순위 선정

5. 해결방안 작성

6. 가설 도출 및 검증

7. 우수사례의 공통점

 

+) 오늘의 인사이트 / KPT 회고

 

활동 내역

• 오늘의 퀴즈 정리
  → 와이어프레임과 프로토타입의 이해 + 노코드 툴의 특성과 활용 시점
• 서비스 제작기
  → 📢 깜놀방지 - 회의 볼륨 평준화 서비스 🙉
• 서비스 기획 숙련 과제 제출(파일 첨부) ▼

[6조-mekite] 서비스 기획 숙련 과제-장바구니 전환율 개선.pdf

14.51MB

• 정보처리기사 실기 공부(D+31)

 

---

 

오늘의 특강
-
입문과제 우수사례 분석

 

 

1. 평가 기준 살펴보기

① 데이터 분석이 문제 정의까지 연결되는가

• 단순히 리뷰를 나열하는 것이 아니라 '그래서 사용자는 어떤 문제를 겪고 있는가?'까지 연결되어야 한다.

② 의견이 아니라 근거인가

• 주관적인 추측보다 리뷰, 데이터, 사용자 행동 근거가 제시되어야 한다.

③ 해결방안이 현실적인가

• 좋은 아이디어보다 실제로 구현 가능하고 검증 가능한 해결방안이 중요하다.

 

2. 리뷰 데이터 분석

◾리뷰는 단순 불만 수집이 아니다

• 우수사례에서는 리뷰를 여러 카테고리로 분류했다.
  ex. 멤버십 혜택 / UI·UX / 추천 / 가격 비교 / 배송 / 검색 / 기타 etc...으로 나누어 분석했다.

◾불만족 리뷰만 보지 않았다

• 많은 사람들이 '불만 리뷰 = 문제'라고 생각한다.
  but, 우수사례는 만족 리뷰도 함께 분석했다.
  cuz '불만 리뷰 → 개선 포인트 발견' / '만족 리뷰 → 사용자가 중요하게 생각하는 가치 발견'이 가능하기 때문이다.

◾데이터는 정리보다 분류가 중요하다

• 특히 인상적이었던 부분은(놀라울 정도로... 리얼 와우 포인트)
  하나의 리뷰를 여러 카테고리에 중복 태깅했다는 점이었다.
  ex. '추천 상품이 마음에 안 들고 UI도 불편하다' → '추천 + UI/UX' 동시 분류
  ⤷ 이런 방식은 리뷰 해석 오류를 줄이는 데 도움이 된다.

 

3. 문제 원인 분석

◾프레임워크는 도구일 뿐이다

• 로직트리, 5 Whys를 썼기 때문에 좋은 과제가 된 것이 아니다.
• 중요한 것은 '왜 이 프레임워크를 사용했는가'이다.

◾로직트리 + 5 Whys

• 우수사례는 '로직트리 : 문제를 넓게 펼쳐보기' → '5 Whys : 근본 원인 파고들기' 순서로 사용했다.
  ⤷ 즉, 넓게 보고 → 깊게 들어가는 방식이었다.

◾사용자 흐름에서 원인을 찾았다

• 좋은 사례들은 기능 중심이 아니라 사용자 행동 흐름 중심으로 문제를 분석했다.
• 예시 사례에서는 추천 상품이 사용자의 현재 관심사와 맞지 않는 이유를
  사용자 행동 데이터와 추천 구조 관점에서 분석했다.

 

4. 우선순위 선정

◾Impact-Effort만으로 끝나지 않았다

• 많은 사람들이 Impact-Effort Matrix를 만들고 끝낸다.
  but, 우수사례는 '왜 Impact가 높은가?', '왜 Effort가 낮은가?'까지 설명했다.

◾'왜?'에 답할 수 있어야 한다

• 해당 문제가 리뷰에서 얼마나 언급되었는지
• 비즈니스 목표와 어떤 관련이 있는지
• 개발 난이도는 어느 정도인지
  → 예시에서는 위 내용을 구체적으로 설명했다.
  ⤷ 즉, 우선순위 결과보다 우선순위 근거가 중요했다.

◾판단 기준이 있어야 한다

• 우선순위를 나눌 때도 'HIGH / MEDIUM / LOW'를
  감으로 나눈 것이 아니라 명확한 기준을 먼저 정의했다.

 

5. 해결방안 작성(우수사례 특징)

무엇을 바꿀 것인가

▶

왜 바꾸는가

▶

어떤 지표가 개선될 것인가

▶

어느 정도 개선될 것으로 예상하는가

 

◾목표 지표가 있었다

• 구매 전환율
• 클릭률
• 쿠폰 사용률
• etc...
  → 구체적인 지표가 함께 제시되었다.

 

6. 가설 도출 및 검증

• 우수사례는 경쟁사 분석도 단순 비교에 그치지 않았다.

GOOD ex.	BAD ex.
왜 이 기능을 넣었을까? 사용자 문제는 무엇일까? 우리 서비스에도 같은 문제가 존재할까?	A사는 이런 기능이 있음 B사도 이런 기능이 있음

 

◾사용자마다 가치가 다르다

• '유저라고 다 같은 유저는 아니잖아요.'
• 실제로 우수사례는
  • 신규 사용자
  • 기존 사용자
  • 재구매 사용자
    → 사용자 유형별로 구분하여 해결방안을 설계했다.
• 이는 최근 PM 과제에서 자주 나오는 행동 기반 세분화와도 연결되는 부분이다.

 

7. 우수사례의 공통점

• 정리하면 우수사례들은 모두 같은 흐름을 가지고 있었다.

리뷰 분석 → 문제 발견 → 원인 분석 → 우선순위 선정 → 가설 수립 → 해결방안 제안 → 기대효과 정의(검증 계획 포함)

• 중요한 것은 화려한 아이디어가 아니었다.
• 각 단계가 데이터와 논리로 자연스럽게 연결되어 있었다.
  특히 '왜 그렇게 생각했는가?'라는 질문에 답할 수 있는 과제들이 좋은 평가를 받았다.

 

---

 

오늘의 인사이트

 

'왜?'라는 질문에 얼마나 근거 있게 답할 수 있는가?

이게 우수사례 특강에서 말하고자 하는 내용이었다.

 

리뷰를 왜 그렇게 분류했는지,
왜 이 문제가 중요하다고 판단했는지,
왜 이 해결방안을 선택했는지.

 

결국 평가자는 해결방안보다 그 결론에 도달한 과정과 근거를 보고 있었다.

 

우수사례 예시를 보면서 든 개인적인 생각...

'그래, 저 정도로 준비하고 근거를 제시했으면 반박하는 사람이 할 말 없겠다'였다.

물론 바득바득 우기고 쥐어짜면 또 반박할 거리가 생기겠지만...

왠지 반박하면 그에 대한 근거를 또 저만큼 준비해 올 것 같아서 살짝 호달달이다.

(데이터와 텍스트로 압박하기... 메모)

 

아무튼 입문 과제는 나도 처음이었고, 치료 일정도 있었고,

아주 살짝의 '이 정도면 됐지'라는 자기 평가 이슈로 좀 아쉽긴 하지만 여러모로 배운 게 많았다.

(말이 많아지면 변명이라던데 맞는 것 같기도)

셀프 가스라이팅 가보자고

 

 

---

 

오늘의 KPT 회고

 

Keep	• 특강 내용을 단순 요약하지 않고, 왜 좋은 사례로 선정되었는지 기준을 분석하며 정리했다. • 서비스 제작기, 퀴즈 정리, 특강 내용을 각각 다른 주제로 정리하면서도 꾸준히 기록을 남겼다.
Problem	• 해결방안보다 문제 정의와 근거가 중요하다는 것을 알면서도, 아직은 해결방안 쪽에 먼저 시선이 가는 경향이 있다.(킹치만... 신경쓰이는 걸...) • 자료를 분석하고 내 식으로 해석하는 과정에 시간을 너무 많이 쓰는 편이다. • '이 정도면 됐지'라는 생각이 들면 근거를 한 단계 더 파고들지 못하는 경우가 있다.(이거 고칠 수 있는 걸까...ㅋㅋㅋ)
Try	• 과제나 프로젝트 진행 시 모든 주장에 대해 최소 한 번 이상 '왜?'를 추가로 던져보기. • 앞으로는 결과보다 근거와 의사결정 과정을 설명하는 연습에 조금 더 집중하기.