프로덕트 개발 방법론 4D:Discover&Define
독일 글로벌대기업 프로덕트매니저가 따르는 4D 방법론
1:1 온라인 커피챗, CV 리뷰, 영어 모의 면접, 포폴/과제 리뷰 서비스는 이 링크를 통해 신청하시면 됩니다.
내가 일하는 잘란도는 유럽 최대 패션 이커머스 플랫폼&풀필먼트 테크 기업이다. 잘란도의 프로덕트(소프트웨어 서비스 혹은 제품) 개발과정은 4D프로세스를 지향하고 있다. 이 글에서는 위 4D프로세스를 소개하는 잘란도 Article의 소개해 본다.
4D는 총 네 가지의 D를 가지고 있어, 4D라고 부른다.
Discovery(문제발견)
Define(문제정의)
Design(솔루션 디자인)
Deliver(솔루션 딜리버, 즉 개발/릴리즈)
먼저 이 글에서는 Discover와 Define에 대해 정리해 보려 한다.
Discover '문제 발견'
고객 발견, 유저 인터뷰&리서치, 데이터 분석, 마켓/경쟁사 리서치, 연관 부서나 팀 담당자와의 미팅을 통한 히스토리와 정보 습득, 비즈니스 케이스 리서치 등등의 과정이 이 단계에 속한다.
Discover는 문제를 '발견'하는 과정이다. 문제를 발견한다는 것은 현재 존재하는 여러 가지 보이는 '현상'말고, 정말 '원인'을 제대로 파악하는 과정이며, 이 문제 발견 단계의 끝에는 이 문제를 지금 풀어야 하는지, 미룰지, 등에 대한 비즈니스적, 프로덕트적 계산을 통한 결정(Decision making)이 이루어진다. 또한 '왜' 내가 이 문제를 풀어야 하는지 스스로 충분히 납득을 넘어 그 문제 이후의 상황까지 고려한 '이상적인 비전'을 세우는 단계이다.
이 Discover 단계가 사실 4D 단계 중에 가장 중요하다고 생각하는 이유는, 문제를 제대로 파악하는 단계이기 때문이다. 문제를 제대로 파악해야만, 그 후에 남은 3단계가 쓸모없는 짓이 되어버리지 않고, 제대로 비전과 솔루션을 제시할 수 있다. 내가 느끼기에 약간 '주춧돌'을 제대로 세우는 단계인 느낌. 또한 효율적, 비용적 측면에서도 이 단계는 중요하다. 제대로 문제를 파악하면 솔루션 디자인단계(Design)에서 솔루션을 흔들리지 않게 기획할 수 있어 시간을 단축할 수 있고, 개발을 해놓고 '엇 이게 아닌데'라고 실패할 확률이 낮아지기 때문이다. 특히, 개발 기간과 인력이 많이 들어가는 프로덕트 솔루션은 회사입장에서 부담스러운 투자이기 때문에, 특히 PM들이 문제 정의에 시간이 좀 걸려도 제대로 하길 원한다.
이 과정은 그 문제의 복잡도와 규모에 따라 아주 짧을 수도 있고, 반년이 걸릴 수도 있다. 또한 당장 급한 Discovery topic이 아니라면 잠시 멈췄다가 진행하기도 하고, 큰 Discovery 프로젝트와 작은 Discover프로젝트를 다수개 병행하기도 한다. 가장 이상적인 PM의 업무 비율은 1개의 Design / Delivery 단계의 제품개발 프로젝트를 주도하면서, 2개 정도의 크고 작은 Discover/Define 단계의 제품 개발 프로젝트를 동시에 맡는 것이다, (개발 60/ 리서치 40 느낌으로...)
Discover단계의 아웃풋은 2가지 정도로 보통 나온다.
1. Vision Document (PRFAQ: Press Release and FAQ 언론보도와 질문 답변. 그런데 FAQ는 추후 Define단계에서 쓰는 경우가 많고, 실제로는 언론보도자료 1page를 쓴다)
2. Topic paper (with Decision Making)
첫 번째 아웃풋인 비전제시 문서는 여러 가지 형태로 쓸 수 있으나, 잘란도에서는 가상의 '언론보도자료'를 1페이지로 쓰길 권장한다. 가상의 '언로보도자료'를 씀으로써 이를 읽는 모든 뷰어들(프로덕트 팀이 아닌, 그리고 이 토픽을 모르는 회사 동료들)이 쉽게 1) 어떤 문제가 있고 2) 어떤 디지털 프로덕트로 해결이 되어서 3) 무엇이 개선이 되었는지, 바뀌었는지를 쉽게 읽고 이해할 수 있다는 장점이 있다. 기능설명이 자세하게 들어가는 것은 아니며, 프로덕트의 비전이 잘 보일 수 있도록 중기/장기적 시점으로 접근해서 쓴다. 어떤 프로덕트 릴리즈를 홍보하는 기사를 쓰는 정도기 때문에, 실제 이게 가능할지 가능하지 않을지 등에 대한 실질적 고민은 이 단계에서 크게 하지 않아도 된다.
두 번째 아웃풋인 토픽페이퍼는, 비전제시 문서를 쓰기 전에 Discover단계의 아웃풋들을 정리하기 위해 혹은 그 토픽을 다음단계로 가져가지 않기로 했을 때 보통 쓴다.
첫 번째 아웃풋인 PRFAQ문서의 내용을 1페이지로 정리하고 빠르게 이해관계자들과 공유하기 위해 추가로 작성하여 공유하는 것이 일반적이고, 이 문제를 보류하거나 현재로서 포기하기 위한 '결정'을 공유하기 위해 쓰기도 한다는 이야기다.
문제현상을 보고 문제의 원인을 파악해 보니 이 문제가 우리가 풀 수 있는 영역에서 너무 벗어나서, 혹은 그 문제를 풀 수 있는 대략의 솔루션들 옵션이 현실적으로 가능하지 않아서, 혹은 지금 솔루션 개발에 들어가는 비용에 비해 그 효과가 크지 않아서... 등등 다양한 이유로 Define 단계로 넘어가지 않기로 PM이 최종적으로 결정할 수 있다. (물론 이는 비즈니스 이해관계자들과 미리 Align이 잘 된 상태여야 하지만, 최종 결정은 프로덕트팀/담당자가 한다.)
이때 1) 어떤 문제가 있고 2) 그 원인이 무엇인지 굵직하게 3-4개 불렛포인트나열 3) 어떤 솔루션 옵션들이 가능한지 4) 이 토픽에 대한 결정(Decision), 왜 그런 결정을 내렸는지를 쓴다. 즉, 비전 제시보다는 Discover단계에서 무슨 문제를 어떻게 파악했고 결론이 뭔지를 명확하게 보여주는 문서를 작성하는 거다.
Define '문제 정의'
문제 Scoping, 우선순위 설정, Mvp 설정, 유저 스토리와&인수조건(Acceptance Criteria) 설정하는 단계이다.
문제 정의 단계로 넘어갔다는 건, 앞선 Discovery 단계에서 이미 이해 관계자들에게 피드백과 리뷰를 받고, 이 문제를 풀만하다고 판단했다는 것을 의미한다. 문제를 어떻게 단계적으로 얼마나 effort를 들여서 해결할지에 대한 Scoping을 한다. MVP, MRP, MLP... 등을 크게 나누면서 이해관계자들과 이해를 맞춘다.
(이때 비전 도큐먼트를 바탕으로 개발팀 리드/Principle 엔지니어 그리고 디자인 팀 리드와 논의할 Topic paper를 작성해서 논의하기도 한다)
그리고 PRFAQ 비전제시 문서에서 'FAQ'에 해당하는 것들을 채운다. 좀 더 실질적인 것들을 이때 묻고 답하기 형식으로 서술하는 것이다.
예를 들면 아래와 같은 질문들이 FAQ로 들어갈 수 있다.
- 이 문제를 풀면 이에 대한 사업적 수익 혹은 내부적 효율성은 얼마나 증가하나요? (Business Impact)
- 솔루션은 어떤 단계로 Deliver 될 예정이며 각 단계별 임팩트는 어떻게 되나요? (product delivery phase, scoping, roadmap)
- 이 문제를 푸는 데에 있어 Risk는 무엇이며 어떻게 이를 어떻게 해결할/대응할 예정인가요? (Risk Mitigation)
- 이 문제를 풀 솔루션의 타 팀 의존도는 얼마나 되나요? (Internal / external dependency) 등..
다음 글에서는 Design & Delivery에 대해 써보겠다.
