데이터 문해력
회사에서 Product Engineer가 되면서 기획, 디자인, 화면 개발, 서버 개발 모두를 할 수 있어야 하는 상황이 되었다.
당연히 개발자였던 나에게 기획과 디자인 실력은 정말 엉망이다. 특히 기획을 잘하려면 문제를 제대로 정의하고 다룰 줄 알아야 했다. 그걸 회사도 알았는지 스터디나 세션과 같이 부족한 점을 메꿀 수 있는 여러 시스템이 갖춰지기 시작했다. 그중 하나로 이 책을 읽고 얘기를 나눠보는 시간을 가지게 되었다.
문제 해결 프레임워크
문제 정의 → 그 문제의 원인 파악 → 해결 방안 도출
아주 간단한 프레임워크임에도 지키기 어렵다. 각종 레퍼런스와 귀찮음 때문에 해결 방안이 먼저 떠오르기 쉽고, 그렇다면 그에 맞춰서 원인과 문제가 끼워 맞춰지기 때문이다. 즉 순서가 거꾸로 가기 쉽다.
이렇게 되면 진짜 원인과 문제를 놓치기 쉽다. 그리고 다각도로 파악할 수 있는 기회를 놓치게 된다. 항상 문제부터 정의를 하고, 그 문제가 발생한 원인을 다각도로 파악하고 난 후 마지막에 해결 방안을 도출해야 한다.
저자는 최소한 저 간단한 프레임워크를 지켜보라고 말하고 있고, 익숙해지면 다음과 같이 조금 더 세분화된 프레임워크를 지켜보라고 말한다.
- 겉으로 드러나는 현상 목격
- 무엇을 하고자 하는지에 대한 목적과 어떤 문제를 해결할 것인지에 대해 정의
- 정말 해결되었는지 파악할 수 있는 지표 설정
- 해결에 앞서 현재 상태 파악(데이터 분석이 필요하다면 곁들임)
- 현재 상태가 어떠한지 평가
- 원인 도출
- 해결 방안 모색
방법맨이 되지 말자
읽으면서 정말 시야가 넓어지는 경험을 많이 했는데, 그중 하나는 '방법맨이 되지 말자'라는 내용이었다.
그 문제 상황에 맞든 안 맞든 참신한 아이디어만 내면 된다는 생각을 가지고 해결 방안부터 제안하는 사람을 방법맨이라고 칭한다. 그 참신한 아이디어가 우연히도 문제 상황에 딱딱 맞아떨어지면 다행이겠지만, 문제 정의도 제대로 하지 않고 그에 맞게 데이터 분석도 하지 않은 상태에서 나온 해결 방안은 아무리 참신하더라도 설득력이 없다.
결국 혼자 일하는 것이 아니라면, 그리고 다른 사람의 도움을 얻으려면 설득력이 있어야 하는데 그저 참신하다는 이유만으로는 전혀 설득이 되지 않는다.
읽고 나서 문제를 바라보는 관점이 조금씩 달라졌다.
- 일단 계속 끊임없이 의문을 품게 되었다. 이게 진짜 문제가 맞을까? 고객이 불편한 것이 이게 정말 맞을까? 이 데이터를 분석하는 것이 현재 상태를 파악하기 가장 좋은 데이터인가? 이 지표를 설정하면 내 목적만 반영된 전후 지표를 볼 수 있을까? 의문이 계속 생기면서 조금 더 딱 맞는 문제 해결에 다가가는 것 같은 반면, 경험이 적어서 그런지 어느 순간 의문이 아니라 의심으로 번지면 불안감이 들곤 한다.
- 데이터보다는 내 직관이 더 옳다는 아주 고집스러운 착각이 있었는데, 이제는 데이터로부터 출발하려고 한다. 정량이든 정성이든.