[Data Analysis] 문제정의 방법
데이터 분석에 앞서 문제 정의 방법
문제
데이터 분석 관점에 문제란 무엇인가?
- 현재 상황에서 주목해야할 것
- 해결해야할 과제
- 미루면 문제가 발생할 것
이러한 문제를 발견하고 해결하기 위해서는 정의가 필요하다. 고로 문제 정의 프레임워크를 통해 확실히 문제를 인지하고 상황에 맞게 활용하는 것이 중요하다.
문제 정의 프레임워크
- MECE
- Logic Tree
- 5 Whys
- So What? Why So?
- S-Is-Q-A
- Airbnb 3-step
MECE & Logic Tree
MECE(Mutually Exclusive Collectively Exhaustive)로 중복이 없고 상호 배타적이며 합이 전체가 될 수 있는 요소의 집합을 의미한다.
즉, 대한민국 전체 인구를 모집단으로 잡고 범주화를 하여(0~20, 20~40, 40~60, 60~) 서로 중복되지 않고 합치면 전체가 될 수 있는 것을 말한다. 이를 Logic Tree와 함께 사용하여 문제 정의를 적용할 수 있다.
Logic Tree란 나무가지를 뻗는 구조로 각 개녕을 논리적으로 연결지어서 주장이나 솔루션을 구조화한다.
주의 : MECE가 맞는지 시간을 많이 소비하지 말 것 & Depth를 적당히 유지할 것
5 Whys
5 Whys는 Logic Tree와 유사하며 1단계부터 5단계까지 “왜”를 반복하면서 문제를 깊이 파고든다.
- 왜 1: 초기 문제 또는 현상에 대해 “왜?”를 묻습니다. 예를 들어, “왜 자동차가 멈췄는가?”
- 왜 2: 1단계의 답변에 대해 다시 “왜?”를 묻습니다. 예를 들어, “왜 엔진이 고장났는가?”
- 왜 3: 2단계의 답변에 대해 다시 “왜?”를 묻습니다. 예를 들어, “왜 엔진 오일이 부족한가?”
- 왜 4: 3단계의 답변에 대해 다시 “왜?”를 묻습니다. 예를 들어, “왜 엔진 오일 공급 장치가 고장난가?”
- 왜 5: 4단계의 답변에 대해 다시 “왜?”를 묻습니다. 예를 들어, “왜 엔진 오일 공급 장치가 고장난 이유는 무엇인가?”
So What? Why So?
So What? Why So? 는 말 그대로 그래서 무엇을 해야하고 왜 해야하는지를 자각하고 탐색하는 방법이다.
So What을 통해 그래서 문제가 무엇이고 우리는 무엇을 해야하는지 결론을 말하고, Why So을 통해 왜 그런지 생각하고 논리적으로 타당한 대답을 할 수 있게 검증할 수 있게 유도할 수 있다.
EX) 그래서 매출하락의 원인은 이탈율이 늘어나서야. 왜 이탈율이 늘어났지?(Why So?) 그럼 우리는 무엇을 해야지(So What?)
S-Is-Q-A
S-Is-Q-A는 바바라 민토의 피라미드 SCQA(Situation Complication Question Answer)에서 상황 - 전개 - 질문 - 답변에서 “전개”(Complication) 대신 “이슈”(Issue)로 대체한 것이다. S-Is-Q-A는 SCQA프레임워크 의미를 크게 벗어나지 않는다.
개념 | SCQA | S-Is-Q-A |
---|---|---|
상황 Situation | 1. 해당 주제와 관련된 배경 정보를 간략하게 설명 2. 고려해야 할 주요 사항은 누가, 무엇을, 언제, 어디서 | 1.수집한 사실(fact)을 토대로 단문의 ‘상황 기술문’을 쓴다. |
Complication / Issue | 1. 상황 내의 도전이나 장애물을 소개 2. 어떤 혼란이 일어나고 있나요? 3. 편견이나 가정을 피하고 객관적으로 구성 | 1. 상황 기술문을 토대로 ‘생각해 볼 만한 거리’를 목록화 한다. 2. “상황 기술문이 사실이라면 어떤 끔직한 일이 일어날까?’라는 의미 |
질문 Question | 1. 합병증에서 비롯된 명확하고 집중적인 질문을 공식화 2. 이 질문은 청중을 해결책이나 원하는 결과로 안내해야 3. 잘 만들어진 질문은 호기심을 불러일으키고 참여를 유도 | 1. ‘어떤 일을 해야 끔찍한 일을 막을 수 있을까?’라는 의미의 질문을 만든다. |
답변 Answer | 1. 문제를 해결하는 답변을 전달 2. 증거, 데이터 또는 추론을 통해 답변을 뒷받침 3. 답변은 체계적이고 설득력이 있어야 | 1. 그것이 문제였구나라는 의미 |
참고 | 경향신문 이용균 기자의 칼럼 https://m.khan.co.kr/sports/baseball/article/201303252201355#c2b | S-Is-Q-A 실습 ① ② ③ ④: https://blog.naver.com/hfeel/221826703878 |
Aribnb 3-step
Localmind의 창업자이며 Airbnb에 매각 후 프로덕트 매니저로서 활동하고 있는 Lenny Rachitsky이 블로그에 작성한 Airbnb에서 사용한 방법이다. (원문)
이 프레임 워크는 새 제품이나 새 기능 중 하나를 염두에 두고 있는 프로젝트가 있을 때 가장 효과적이다. 기획 또는 개발에 뛰어들기 전에 다음과 같은 단계를 수행하여 프로젝트 성공적으로 이끌 수 있다고 한다. 팀이 명확한 비전(i.e. 어디로 가는지)이나 전체적인 전략(i.e.도달 방법)이 없는 경우 여기에서 잠시 멈추고 먼저 다음과 같은 상황을 파악하면 도움이 될것이다.
- 1단계: 풀고자 하는 문제를 구체화하기 (Crystallize the problem you are solving)
- 2단계: 팀원 및 이해관계자들과 문제에 대한 눈높이 맞추기 (Align on the problem with your team and stakeholders)
- 3단계: 끊임없이 문제로 돌아오기 (Keep coming back to the problem)
1단계: 풀고자 하는 문제를 구체화하기
- Description(설명) : 무엇인가?
- Problem(문제) : 어떤 문제가 해결되나?
- Why(이유) : 이것이 실제 문제이고 해결할 가치가 있다는 것을 어떻게 알 수 있나?
- Success(성공) : 이 문제가 해결되었는지 어떻게 알 수 있나?
- Audience(청중) : 우리는 누구를 위해 문제를 해결하려고 하나?
- What(무엇) : 제품에서 이것은 어떻게 생겼는가?
2단계: 팀원 및 이해관계자들과 문제에 대한 눈높이 맞추기
같은 문제임에도 불구하고 팀우너들의 생각은 다를 수 있다. 프로젝트가 더 크고 복잡할수록 서로 다를 가능성이 더 크다.
- 1단계를 시작한다(하지만 특정 문제에 대해 열정적인 팀원은 누구나 가능하다.)
- 해당 프로젝트에 참여할 전체 팀과 초안을 공유한다. 피드백을 요청하고(댓글, 이메일, 혹은 직접)피드백을 통합하고 다시 공유하라.
- 피드백이 수렴되고 팀이 정렬된 것처럼 보인다면 좋다. 그렇지 않다면 모든 사람을 모아서 의견 차이를 통해 직접 대화하라.
- 팀이 조정되면 이해관계자와 공유하라. 당신의 팀과 당신의 성공을 판단하는 사람들이 당신이 디자인 혹은 개발에 너무 깊이 들어가기 전에 당신이 해결하고 있는 문제와 일치하는 것이 매우 중요하다.
- 문제 정의를 다시 검토하고, 미해결 질문에 답하고, 팀에 시작하는데 필요한 모든 것을 갖추고 있는지 확인하는 킥오프를 위해 팀을 모아라.
3단계: 끊임없이 문제로 돌아오기
당신은 예약하는 방법을 알고 예약을 유지하는 방법을 모를 뿐이에요. 그리고 예약을 유지하는 건 예약에서 제일 중요하죠. 유지!!! 누구나 예약은 할 수 있습니다.
여러가지 방법을 많은 문제를 해결할 수 있지만 문제를 해결하지 않아도 되는 아름다운 제품을 만들 수도 있다.
몇가지 함정을 피하기 위한 좋은 습관 :
- 모든 설계 검토에서 설계자가 문제 설명을 검토하여 시작하는지 확인하라. 명확하지 않은 경우 “해결하려는 문제가 무엇입니까?”라고 질문하라.
- 모든 진행 상황이 이해관계자에게 업데이트 될 때마다 문제 설명을 검토하여 모든 사람이 계속해서 결과에 부합하는지 확인하라.
- 디자인을 마무리하기 전에 다음과 같이 자문하라. “이것이 우리가 해결하려고 했던 문제를 해결할 것이라고 확신한가?”