출처 : A Three-Step Framework For Solving Problems
문제 해결을 위한 3단계 프레임워크
- 에어비앤비에 입사해 배운 점 중 하나는 무엇보다도 문제 정의를 올바르게 하는 것이 중요하다는 것입니다.
- 프로젝트를 실패로 이끄는 많은 요인이 있지만 해결 중인 문제를 오해하는 것보다 더 확실한 건 없습니다.
- 에어비엔비에서 저와 팀이 해결해야 할 진짜 문제는 “여행자가 다른 여행자와 어울리고 싶어한다”가 아니라 “여행자는 관광지가 아닌 양질의 일을 찾고 싶어한다”라는 사실을 너무 늦게 깨달았습니다.
- 다른 여행자들과 어울리는 것은 실제 문제가 아니라 이에 대한 한 가지 해결책이었을 뿐입니다.
- 문제를 해결하는 가장 중요한 단계는 문제 정의를 완성하는 것입니다.
- 문제 정의를 위해선 세 가지 간단한 단계만 거치면 됩니다.
- 이 프레임워크는 새로운 제품이나 새로운 기능을 염두에 두고 프로젝트를 구상할 때 가장 효과적이며, 엔지니어링 전에 수행해야 합니다.
- 1단계: 해결하려는 문제 구체화
- 2단계: 팀 및 이해관계자와 문제 조율
- 3단계: 다시 문제로 돌아오기
1단계: 해결하려는 문제 구체화
먼저 다음 질문에 답해 보세요.
- 설명: 무엇인가요?
- 문제: 어떤 문제를 해결하려 하나요?
- 왜: 이것이 진짜 문제이고 해결할 가치가 있는지 어떻게 알 수 있나요?
- 성공: 이 문제를 해결했는지 어떻게 알 수 있나요?
- 청중: 누구를 위한 것인가요?
- 대상: 제품에서 어떤 모습으로 보여줄 건가요?
설명: 무엇인가요?
이 프로젝트가 무엇에 관한 것인지 빠르게 파악할 수 있도록 간략하게 작성하세요.
문제: 어떤 문제를 해결하려 하나요?
문제를 가설처럼 생각하세요. 해결하려는 문제가 무엇이며 해결하려는 이유는 무엇인가요? 이후에도 추가적으로 더 많은 컨텍스트를 추가하세요.
[효과적인 문제 정의의 특징]
- 짧다 : 실제 문제를 설명하는 한 문장을 찾으세요. 설명해야 할 것이 많을수록 문제는 불명확해집니다.
- 집중 : 우리 팀이 갖고 있고, 합리적인 시간 내에 해결할 수 있는 단 하나의 명확한 문제만 포함하세요.
- 필요 : 사용자 요구 사항에만 초점을 맞추되, 필요한 경우 비즈니스 요구 사항도 포함할 수 있습니다. Jobs-To-Be-Done 프레임워크를 사용하세요.
- ‘무엇’과 ‘왜’ : 무엇이 잘못되고 있으며 왜 문제가 되는 지 기술하세요.
- 해결책 : 반드시 해결책을 포함해야 하는 건 아닙니다. 너무 일찍 해결책을 찾으려 하지 마세요.
[좋은 문제 정의의 예]
- Lyft의 드라이버가 승객이 너무 멀리 떨어져 있다는 이유로 콜을 너무 자주 취소하고 있다.
- 에어비앤비 호스트는 개선을 원하지만 방법을 못 찾고 있다.
- 사용자가 가입의 마지막 단계에서 너무 높은 비율로 이탈하고 있다.
[잘못된 문제 정의의 예]
- 사용자 증가가 둔화되고 있다.
(문제가 너무 광범위합니다. 또한 사용자 중심적이지 않습니다.)
- 로열티 프로그램 구축하기
(너무 빨리 해결책을 가정하고 있습니다. 로열티 프로그램이 해결하고자 하는 문제는 무엇인가요?)
- 사용자가 가입 흐름에서 이탈하고 있습니다.
(문제가 날카롭지 않고, 이유에 대한 가설이 없습니다.)
왜: 이것이 진짜 문제이고 해결할 가치가 있는지 어떻게 알 수 있나요?
- 문제 정의(가설)을 뒷받침하는 증거를 수집하세요. 처음에 이것이 문제라고 확신한 이유는 무엇인가요? 이 문제를 해결해야 하는 이유는 무엇인가요?
- 어쩌면 이 단계에서 문제가 지금 당장 해결해야 할 가치가 없거나 문제에 대한 의견을 조정해야 한다는 것을 깨닫게 될 수 있습니다. 그렇게 되더라도 거부감을 갖지 마세요.
- 해결해야 할 문제들은 무궁무진하고, 여러분의 목표는 어디까지나 이 문제가 지금 당장 팀의 시간을 할애할 가치가 있다는 확신을 갖는 것입니다.
[팁]
- 양적/질적 증거를 모두 확인하세요
- 양보다 질 의미있는 3~5개의 데이터가 여러개의 관련성 낮은 데이터보다 훨씬 낫습니다. 종종 많은 증거를 보여주기 위해 사소하고 관련 없는 데이터로 채우는 경우가 있습니다.
- 악마의 대변인이 되어보세요 (의도적으로 반론을 제기하는 전략) 이 문제가 심각하거나 큰 문제가 아니라고 스스로를 설득해 보세요. 찾은 증거에 빈틈이 있나요? 증거가 정말로 여러분의 가설을 증명하고 있나요?
성공: 이 문제를 해결했는지 어떻게 알 수 있나요?
- 기능 X가 설정한 목표에 기여하나요? 그렇지 않은 경우 과감히 배제하세요.
- 먼저 목표가 정의되어 있고 쉽게 측정할 수 있는 구체적인 지표가 있어야 합니다.
- 팀의 KPI와 직결되는 것이 가장 좋으며, 기회 규모나 투자 규모 혹은 과거 실험에서 얻은 휴리스틱 등에 관한 하드 데이터를 기반으로 하는 것이 가장 이상적입니다.
[팁]
- ‘3개월 이내에 X 10% 증가, Y 50% 감소, Z 기능 채택률 20%’ 처럼 구체적인 숫자로 만드세요.
- 실현 가능하되 큰 목표를 정하세요.
- 목표에 맞는 구체적인 메트릭이 없다면, 이 기능이 크게 성공했을 때 세상이 구체적으로 어떻게 바뀔지를 기준으로 하세요.
청중: 누구를 위한 것인가요?
- 당연히 모든 사용자는 아니어야 합니다. 그렇다면 신규 또는 재사용자를 위한 것인가요? 혹은 일반 사용자용인가요? 그것도 아니면 paid 사용자용인가요?
무엇을: 제품에서 어떤 모습으로 보여줄 건가요?
- 여기에서 문제에 대한 해결책을 설명하세요.
- 제 경험에 비추어 볼 때, 여기서 핵심은 디자이너와 조율하는 일입니다.
- 디자이너가 얼마나 많은 세부 사항을 원하며, 그리고 그 과정에서 가장 도움이 되는 것이 무엇인지 파악해야 합니다.
2단계: 팀 및 이해관계자와 문제 조율
- 팀원 모두의 머릿속에는 각자 버전의 문제가 있습니다. 때로는 거의 동일하지만, 때로는 매우 다릅니다.
- 프로젝트가 크고 복잡할수록 다를 가능성이 높습니다. 2 단계에선 이러한 불일치를 조기에 근절하는 것입니다. 1단계를 수행했다면 10배는 쉬울 것입니다.
[접근법]
- 1 단계를 수행합니다.
- 이 프로젝트에 참여할 전체 팀과 초안을 공유하고 피드백을 요청하세요. 이후 피드백을 통합하고 다시 공유합니다.
- 피드백이 모아지고 의견이 일치한다면 넘어가세요. 그러나 그렇지 않다면 모든 사람을 한데 모아 의견 불일치를 직접 논의해야 합니다.
- 팀이 조율되면 이해관계자와 공유하세요. 디자인이나 엔지니어링 단계에 너무 깊게 들어가기 전에 팀 그리고 프로젝트의 성공 유무를 판단하는 사람들과 해결하려는 문제를 조율해야 합니다.
- 대면으로 문제 정의를 다시 검토하고, 질문을 받고, 팀이 해당 업무를 수행하는 데 필요한 것들을 갖추고 있는지 확인하세요.
3단계: 다시 문제로 돌아오기
- 제품 개발에서 생기는 고전적인 함정은 ‘시작은 원활하지만 가장 중요한 순간, 즉 작업이 실제로 수행될 땐 해결하고자 하는 문제를 고수하지 않는 경우가 많다.’는 것입니다.
- 몇 년 전, 전 에어비앤비 호스트를 위한 대시보드를 만드는 프로젝트를 진행했습니다.
- 저희가 정의하고 해결한 초기 문제는 호스트가 게스트의 메시지에 응답하는 평균 시간을 줄이는 것이었습니다. 우리의 가설은 ‘읽지 않은 메시지가 더 두드러지고, 응답 시간이 검색 순위에 영향을 미친다는 것을 상기시키면 호스트가 더 빨리 응답할 것이다’ 였습니다.
- 결국에는 우리의 가설이 옳았지만, 프로젝트 전반에 걸쳐 복잡성이 증가하고 문제의 범위가 점점 넓어졌습니다.
- 따라서 저는 팀원들에게 우리가 해결하고자 하는 문제가 무엇인지 반복해서 상기시켜야 한다는 것을 알게 되었습니다.
- 문제 정의와 성공 지표로 돌아가는 것만큼 프로젝트를 성고적으로 수행하는 데 도움이 되는 것은 없습니다.
- 여러 가지 방법으로 많은 문제를 해결할 수 있지만, 오히려 어떤 문제도 해결하지 못하는 멋지기만 한 제품을 만들 수도 있습니다.
[제품 개발의 함정 방지하기]
- 디자인 리뷰는 디자이너가 문제 정의를 검토하는 것에서부터 시작하세요. 만약 그게 명확하지 않다면 “우리가 어떤 문제를 해결하려고 하지?”라고 질문하세요.
- 이해관계자에게 진행 상황을 업데이트할 때마다 문제 정의를 검토하여 모든 사람이 결과에 동의하고 있는지 확인하세요
- 디자인을 마무리하기 전에 스스로에게 물어보세요 “이것이 우리가 해결하고자 하는 문제를 해결할 수 있을 것이라고 확신하는가?”