User Story Mapping
이 글은 Jeff Patton의 User Story Mapping: Discover the Whole Story, Build the Right Product 내용을 번역, 의역 및 재구성한 글입니다.
탁월한 PO는 최고의 의사결정을 위해 필요한 사람들로 자신을 둘러싼다.
Effective product owners surround themselves with the prople they need to make good decisions.
스토리 관리에 대한 오해와 진실
애자일 방법론을 사용하는 팀이 종종 가지고 있는 가장 큰 오해는 뭘까?
바로 제품의 스토리 제작과 관리를 전적으로 하는 사람이 존재한다는 것이다. 흔히 우리는 이 사람을 프로덕트 오너라고 부른다. 그렇다면 그 오해가 왜 잘못이 된다는 걸까?
스토리 관리에 대한 진실 #1 스토리 관리는 PO 혼자 할 수 없는 일이다.
제품의 실제 개발을 위해 만드는 스토리의 층위와 종류는 매우 다양하다. 사용자의 사용 맥락에 따른 정말 작은 수준의 스토리부터 실제 개발에 쓰일 수 있을 정도의 세세한 기술적 부분까지 굉장히 많은 종류를 지닌다.
스토리 관리에 대한 진실 #2 스토리는 다양한 관점을 요구한다.
스토리는 상세 기능 명세서에 쓰이는 제품 스펙만을 의미하지 않는다. 스토리는 실제 사용자의 사용맥락에 어떤 영향을 끼치는지부터, 제품을 만드는 회사에 어떤 의미를 지니는지에 대한 세세한 내용들을 포함할 수 밖에 없다.
스토리는 ‘제품이 현실에서 어떤 의미를 가지는지’에 대한 정보들이 담겨져있는 것이다. 아무리 PO가 스토리에 대한 책임을 가진다고 하지만, 오롯이 PO만이 모든 스토리의 내용을 쓰고 관리한다는 것은 불가능한 일이다.
탁월한 PO는 자신을 최고의 의사결정을 위해 필요한 사람들로 둘러싼다.
제품의 실패 리스크를 줄이는 것 뿐만 아니라, 제품이 더욱 가치있을 수 있게 만드려면 다양한 영역의 전문적인 관점이 필수적이다. 최고의 제품을 만드는 것은 최고의 의사결정을 필요로 한다. 그렇다면 어떻게 그 의사결정을 돕는 사람들로 둘러쌀 수 있을까?
먼저, 제품을 만들 때 가장 크게 고려해야 할 점을 생각해봐야 한다. 제품에 가장 큰 영향을 끼치는 요소는 가치(value), 실현가능성(feasibility), 사용성(usability)이다. 제품은 이 세 가지 요소를 모두 충족했을 때 사용자에게 의미가 있을 뿐만 아니라, 사업적으로도 존속 가능한 형태로 나올 수 있다.
그렇다면 가치, 실현가능성, 사용성에 대한 리스크를 줄여줄 수 있는 사람들이 필요한 것이다. 탁월한 제품을 만드는 팀-제품 발견(product discovery)팀-은 인원수가 적고 교차기능적인 팀원들로 구성되어 있으며, PO는 이 팀을 이끌며 제품 발견 과정을 최적화시키는 역할을 해야한다.
제품 발견팀은 협력의 중심지의 역할을 수행한다. 앞서 ‘대화를 하고 있지 않으면 기획을 하고 있는 것이 아니다.’라고 말한 것처럼, 제품 발견팀은 수많은 이해관계자들과 소통하고 협력한다. 우리의 목적은 고객과 사용자뿐만 아니라 사업적으로도 의미있는 제품을 만드는 것이다. 그렇기에 끊임없는 열정적인 대화가 일어나지 않는다면 이상한 일이다.
제품 발견팀에 포함되어야 하는 필수적인 세 가지 역할
제품 발견팀의 각 팀원들은 책임과 자율성을 가지고 각자의 전문성을 발휘하며, 이를 통해 최고의 제품을 만들어 낸다. 제품 발견팀에는 빠질 수 없는 세 가지 역할이 있다.
1. 검수자(tester)
대화와 논의에서 비판적인 관점으로 리스크를 재빠르게 밝혀내는 역할이다.
2. 이해자
왜 이 제품을 만드는지, 이 제품은 누구를 위한 것인지를 명확이 이해하는 역할이다.
3. 설계자
제품의 전반적인 경험을 설계하고, 제품의 상세 사항들을 처리하는 역할이다.
각 역할에 대해서 한 명씩 필요한 것은 아니다. 하지만 팀을 구성했을 때, 팀이 반드시 이 세가지 영역에 대해서 충분한 역할을 수행할 수 있는지 확인하는 것이 중요하다.
제품 발견은 만드는 과정이 아니다.
실패하는 제품 조직은 ‘제품 발견’ 과정이 없는 경우가 많다. 제품 발견 과정이란, 해결하려는 문제를 정의하고, 가치를 만들 수 있는 방법에 대해서 고뇌하며, 실현 가능하고 사용성이 높은 방법을 솎아내는 과정을 의미한다.
즉,
(1) 문제를 사업화시킬 수 있도록 재정의하며,
(2) 고객과 사용자를 이해하여 그들을 위한 해결책의 기반을 닦고,
(3) 해결책을 구체화시킨 후
(4) 사업성을 검증할 수 있는 최적의 실험 방법을 계획하는 것
이다.
각 제품 발견 단계에서는 어떤 업무를 수행해야 할까?
(1) 문제를 사업화시킬 수 있도록 재정의하기
- 다루고자 하는 문제에 대한 사업적 정의하기
- 사업 지표와 제품 지표 정의하기
- 고객과 사용자에 대한 정의하기
- 가장 큰 리스크와 가설 확인하기
- 이해관계자 및 전문가들과 논의하기
(2) 고객과 사용자를 이해하여 그들을 위한 해결책의 기반을 닦기
- 사용자에 대한 상세한 정의
- 사용자 프로필과 스케치 (페르소나)
- 사용자의 현재 스토리 맵 만들기
- 사용자를 더 상세하게 알기 위한 사용자 조사와 관찰
(3) 해결책을 구체화시키기
- 가능성 있는 해결책에 대한 스토리
- 사용자 시나리오
- UI 스케치와 스토리보드
- UI 프로토타입
- 기능적 프로토타입
- 제품에 관련된 수많은 이해관계자와 치열한 논의
(4) 사업성을 검증할 수 있는 최적의 실험 방법을 계획하기
- 단계적 개발을 위한 스토리 맵 나누기 (slicing)
- 개발에 필요한 자원 측정
탁월한 제품을 만드는 것은 탁월한 제품 발견이 수행됐을 때 가능하다. 누구를 위해 무엇을 만드는 지 이해하지 못하고 무작정 만드는 것은 회사의 자원으로 사치부리는 일과도 같다. 제품 발견을 제대로 마친 후 제품 전달(product delivery)을 수행해야 한다.
제품 발견 과정에서 유저 스토리 매핑이 요긴하게 사용된다는 점을 잊지 말자!
이해가 되지 않는다면, 이전 글을 참고해주세요
이번 글은 과거에 기록했던 Inspired: How to Create Texh Products Cutstomers Love 책의 내용이 기반이 되어, 이전 글을 먼저 읽으시면 이해하는 데에 큰 도움이 됩니다.
PM, PO 개념 - https://brunch.co.kr/@uxn00b/27
서양권(특히 실리콘밸리)에서는 프로덕트 매니저(Product Manager, PM)을 ‘직무’로 칭하며, 프로덕트 오너(Product Owner, PO)는 PM이 수행해야 할 책임(acocuntability)의 일부라고 여깁니다.
PO의 개념은 의미있는 제품을 빠르게 만들기 위해 나온 애자일 방법론에서 나온 것으로. 스크럼 보드, 칸반 등을 활용해 프로젝트를 애자일하게 끌어나가는 역할을 의미합니다. PM은 애자일 방법론뿐만 아니라 상황에 맞게 더 다양한 방법론과 프레임워크를 사용하며, 궁극적으로는 제품을 성공시키기 위해 사업적인 리서치와 의사결정을 진행하는 더 넓은 개념으로 여겨집니다.
‘스토리’ 개념은 애자일 방법론에서 가장 많이 쓰이는 제품 구성 방법이기 때문에, 이 책에서는 PM보다 PO라는 지칭이 더 많습니다.
제품 발견, 제품 전달(Product Discovery) 등 제품 관련 개념 - https://brunch.co.kr/@uxn00b/21
제품 발견 (Product Discovery) 상세 - https://brunch.co.kr/@uxn00b/34