진행한 일
아티클 스터디
- 나이키에게 30조원 재앙을 부른 데이터 드리븐
서비스 기획 입문 과제
- 문제 현상 원인 분석
- 문제 정의
- Impact, Effort 평가
- 핵심 문제 선정
회고
오늘도 역시 서비스 기획 입문 과제를 수행했다.
결론적으로 내용이 정리되진 않아서 진행한 일들의 모든 내용을 기록하기보단 깨달은 점들을 중점으로 기록하고자 한다.
방법론의 함정?
지금까지 코스 과정에서 그리고 개발자로 일을 하면서 여러 가지 방법론으로 불리는 것들을 접하고 공부했었다. 예를 들어 객체지향설계, 애자일, 스크럼, 5Whys, Logic Tree와 같은 것들 말이다.
이러한 방법론들을 공부하다 보면 항상 시선을 끄는 요소들은 이른바 행동 강령 혹은 원칙 같은 것들이었다. 이것도 예를 들어 보자면
- 객체지향설계 -> SRP (단일 책임 원칙) ...
- 애자일 -> 작동하는 결과물, 주기적인 전달, 단순성 ...
위와 같은 것들 말이다.
당연히 처음 이런 방법론들을 접할 때는
이게 뭐지? -> 설명을 읽어봄(목적이나 의도 파악) -> 음... 그래서 어떻게 하라는 거지? -> 아! 그래서 이렇게 시도해보면 되는구나!(행동 강령, 원칙, 규칙 등)
위와 같이 받아들이는데 어느 순간부터는 중간은 다 스킵되고
이게 뭐지? -> 아! 그래서 이렇게 하면 되는구나!(행동 강령, 원칙, 규칙 등)
의 과정에만 집중했다. 아무래도 확실하게 A=B와 같이 딱 정해진 것들이 아니다 보니 이름도 방법론이라고 붙은 것이기도 하고, 그래서 이렇게 해보세요와 같은 행동 강령들이 존재하는 것이다 보니 지켜야 할 것, 경계해야 할 것 등이 많아서 익숙지 않은 사람인 나로서는 그래서 어떻게 하는데에 집중하지 않았을까....?
근데 오늘 기획 입문 과제와 아티클 스터디를 하면서 팀원분들, 튜터분과 이야기해보기도 하고, 혼자도 고민해보면서 확실하게 느꼈다.
방법론의 목적, 목표가 중요하고 원칙, 행동 강령들은 이 목적을 달성하기 위한 가이드다!
즉, 문제를 분석하는 두 방법론인 5Whys, Logic Tree는 어떻게 진행해야 하고, 어떤 원칙을 지켜야 하는지를 계속 체크하기보다는, 이러한 것들이 문제를 작게 쪼개서 바라보고 근본적인 원인이 무엇인지 찾아본다는 목표에서 어긋나지 않았는지를 계속 체크했어야 하는 것이다......
오늘의 한줄평
Ah Ha! 포인트가 아니라 애매 포인트만 찾은 하루였다.....
