??? : 우리 이젠 진짜 태초마을이야!

"근데 우리... 이제는 진짜 기능을 정해봐야 되는거 아니야...?"

이는 협업 동아리 Pard에서 3주간 진행되는 해커톤이 시작되고 4일 후에 우리 팀에서 나온 이야기였다

분명히 아이디어도 있고, 솔루션이 있는 것 같지만, 문제정의가 없는 아이러니한 상황...

뭔가... 챗바퀴가 돌고 있는데?

지금와서 생각해보면 놀라울 정도로 동일한 레퍼토리가 반복되고 있었다.

이름하여...

지옥의 문제-솔루션-기능 3순환! (두둥~)

우리의 이상적인(안일한) 사고 방식은 이것이었다.

1. 우리 아이디어가 해결해야 할 문제가 이거저거요거 아닐까?

   1.1 오 좋은데?

2. 자 그러면 이거에 대한 솔루션이 이거저거요거 아닐까?

   2.1 오 좋은데?

3. 이제 우리 기능 만들어볼까?

   3.1 오 좋은데?

.

.

.

여기까지 보면 해피엔딩이다.

적당한 문제정의를 하고, 이에 대한 솔루션을 세워 서비스의 틀을 잡고 기능을 설계한다.

이대로 되면 얼마나 아름다운가...!

하지만!

문제는 여기서부터 발생한다.

내가 이 방법을 지옥의 문제-솔루션-기능 3순환 이라고 명명한 것에는 다 이유가 있다.

문제란...

기능을 파다 보면 문제정의가 명확하지 않음을 금방 깨닫게 되고, 다시 문제점으로 돌아가게 된다.

브레이크 밟아!!!

그리고 이 순환은 중간에 브레이크를 걸고 1단계인 문제정의를 확실하게 하지 않으면 팀원 모두가 서비스에 대해 타협하기 전까지 멈추지 않는다.

아래는 실제로 우리 팀이 중간에 브레이크를 걸기 전까지의 아이디에이션한 과정을 담은 피그잼이다.

잘 안 보일 독자님들을 위해 설명해주자면

우리는 문제-솔루션-기능 순환을 두 바퀴 반 돌고나서 브레이크를 걸었다.

브레이크를 밟았다면 다음은...

두 가지 방향성이 있다.

1. 눈을 가리고 타협한다.

여기서 말하는 타협이란, 유저가 그다지 크리티컬 하다고 느끼지 않는 문제점을 해결해주는 서비스를 만들어 놓고도

와~ 우리가 서비스를 만들어 보았어!

라고 하며 거기서 만족하는 것을 말한다.

사실 쉬운 방법이다. (포기하면 편해...)

사실 나도 우리 서비스가 대충 포트폴리오 하나 채우려고 하는 개인 프로젝트 중에 하나였다면 이 단계에서 포기했을 것이다.

하지만 우리 팀은 이 해커톤에서 1등할 팀이고, 1등하기 위해 모인 팀이다.

여기서 팀 빌딩 타이밍에 진행하는 목표의 Align 의 중요성이 드러난다.

다들 1등이 목표였기 때문에 여기서 대충 넘어간다는 선택지 따위는 애초에 존재하지 조차 않았다.

자 그러면 자연스럽게 두 번째 선택지로 넘어간다.

1. 대정의인 문제정의가 단위원소가 될 때까지 집요하게 쪼갠다.

??? : 그게 뭔말...?

음... 쉽게 설명하자면,

진짜 문제를 해결할 근본적인 방법이 무엇인지를 찾는 과정을 거쳐야 한다는 것이다.

여기서 포인트는 근본적인이다

우리는 표면적인 인과관계를 보고 있다는 점이 문제라는 것이다.

대정의를 쪼개기 - 5 Why

미국의 워싱턴 D.C에는 미국의 3대 대통령인 토머스 제퍼슨을 기념하는 제퍼슨 기념관이 있다.

새로 부임한 기념관장은 어느 날 기념관의 대리석이 다른 대리석 건물보다 부식이 빠르게 진행되고 있는 문제를 발견하게 되었다.

기념관장은 문제를 해결하기 위해 직원들에게 물었다.

(여기서부터는 질문에 대한 대답을 맞춰보며 읽어보면 재밌으니 스포방지를 위해 답변 전에 그림을 끼워넣겠다...!)

"왜 이렇게 대리석들이 빨리 부식이 될까요?"

직원들은 깊게 생각하지 않고 답할 수 있었다.

"그야 대리석을 세제로 자주 닦기 때문이죠"

기념관장은 다시 질문했다.

"그렇다면 왜 대리석이 부식될 만큼 세제로 자주 닦나요?"

그러자 예상할 직원들이 대답했다.

"비둘기들의 배설물을 지우기 위해서는 대리석을 자주 닦아야 합니다"

보통 여기까지 오면 "아! 비둘기가 문제구나!" 하고 비둘기 말살정책을 펼칠 것이다.

하지만, 이 경우가 아까 말했던, 근본적인 원인을 찾아 해결해주지 않은 상황인 것이다.

계속해서 이야기를 진행해보겠다.

직원들의 대답을 들을 기념관장은 거기서 멈추지 않고 다시 물었다.

"그렇다면 왜 비둘기들이 기념관에 많이 있는것이죠?"

그러자 고민하던 직원들은 다음과 같은 답변을 내놓았다.

"그건 주변에 비둘기의 먹이인 거미가 많기 때문입니다."

기념관장이 다시 물었다.

"거미요? 거미가 왜 많을까요?"

그러자 직원들이 대답했다.

"그거야 주변에 거미들의 먹이인 나방이 많이 살고 있어서 그렇죠"

기념관장은 여기서 멈추지 않고 또 물었다.

"왜 나방이 유독 여기에 많을까요?

직원들은 답했다.

"그건 기념관이 주변 건물 중에 실내 전등을 가장 일찍 켜기 때문입니다."

이를 들은 기념관장은 이야기 했다.

"아하! 그러면 기념관의 실내 전등을 조금 더 늦게 키면 대리석이 빨리 부식되는 것을 막을 수 있겠군요!"

결론이 상당히 이상하다고 느낄 수 있다.

하지만, 원인을 찾는 시퀀스를 같이 따라온 사람이라면 이게 억지 주장이 아니라는 것을 알 수 있을 것이다.

즉, 문제를 해결하기 위해서 그 너~~~~얿은 문제만 생각하고 있으면 solution이 나와서 문제가 해결되지 않을 것이라는 것이다.

방법론을 사용하여 문제 설정하기

이제 실제로 이 5-why 방법론을 어떻게 우리 팀에 적용했는지 말해주겠다.

일단 이 5-why 방법론을 적용시키기 위해서는 일단은 Fact가 있고, 그것에 대한 answer을 설정해야 한다.

하지만 이를 기획하는 사람들이 임의로 설정할 경우에 데이터가 오염될 수 있기 때문에 먼저 설문을 받았다.

설문을 통하여 사용자들이 겪고있는 problem들을 카테고리화 해서 sorting했고, 이것들을 5 why의 첫 번째 why들로 설정하였다.

그리고 더이상 why를 물을 수 없을 때까지 이 problem을 쪼갰고,

그러자 하나의 problem이 아래와 같이 가장 날 것의 18개의 problem으로 나누어졌다.

이후에는 이 18가지의 problem을 우리가 현실적으로 구현하고, 해결해줄 수 있는 문제인지를 확인하여 버릴 problem은 버리고, 그 후에는 각각의 문제에 대해 아래의 여섯 가지를 판단해보는 문제 우선순위 설정 프레임워크를 적용시켰다.

• Popular: 많은 사람들이 느끼는 문제인가?

• Growing: 문제를 느끼는 사람들이 늘어나는가?

• Urgent: 시급하게 해결해야 하는 문제인가?

• Expensive: 해결하는 데 돈이 많이 필요한가?

• Mandatory: 꼭 해결해야 하는가?

• Frequent: 자주 발생하는 문제인가?

그렇게 문제점들을 수치화시키고 나니, 18가지 문제점들의 우선순위가 정해졌다.

이제 우리 진짜 솔루션 낼 수 있는 거에요...?

이제는 5-why를 통한 그루핑과 이의 우선순위까지 정했으니

그렇다...! 이젠 솔루션을 낼 차례이다.

가장 근본적인 유저들의 문제들을 해결해주면 되는 것이다.

"어떻게요?"

그걸 이제 또 아이디에이션 해봐야지...ㅎ

그렇게 우리는 솔루션 아이디에이션을 하고, 이를 효과적으로 풀어낼 기능까지 도출해낼 수 있었다.

햎삐앤딩~

이제 진짜 진짜 진짜 태초마을이야!

이건 우리가 4일동안 해온 것을 갈아 엎고 밤샘을 하기로 결정한 후에 팀원 중 두 명과 산책을 하며 흥분하며 한 이야기였다.

남들이 봤으면 드디어 미쳤구나 싶었을 수도 있었다.

4일동안 나온 것이 하나도 없고 처음부터 다시 시작하는 것이 조급할만도 한데 어쩌면 우리는 단체로 미쳐있었는지도 모르겠다.

하지만 놀랍게도 우리는 이러한 과정을 거치면서 카타르시스를 느끼고 있었다.

진짜 서비스 다운 서비스를 만들고 있다는 희열

어쩌면 우리는 이것에 미쳐있었던 것일지 모른다.

우리가 이제는 진짜 제대로 된 길로 들어섰다는 확신이 들었는데 어찌 기쁘지 않겠는가?

나는 성장이 즐겁다.

그리고 우리팀이 같이 성장했다는 사실이 미친듯이 기쁘다.

그리고 성장을 도와주는 수많은 사람들이 있다는 사실에 감사하다.

Pay it Forward

이것이야 말로 카타르시스의 극치이지 않을까 생각한다.