스토리 매핑: 덜 만들기위해 계획하라

User Story Mapping

이 글은 Jeff Patton의 User Story Mapping: Discover the Whole Story, Build the Right Product 내용을 번역, 의역 및 재구성한 글입니다.

우리가 가지고 있는 인력, 시간, 돈은 우리가 만들고자 하는 제품 수보다 훨씬 부족하다. 무조건.
There’s always more to build than you have people, time, or money for. Always.

덜 만들기위해 계획하라 (Plan to build less)

우리가 스토리를 사용하는 이유는 ‘빠르게’ 만드는 것이 아니다. ‘덜 만들기 위해’ 스토리를 사용한다. (1) 목표 일정에 맞게, (2) 목적에 맞는 최적의 기능을 만들어야 한다. 속도에 관한 것은 부차적인 것이고, ‘목적에 맞는’ 기능을 가장 경제적이고 합리적으로 만들기 위함이다.

제품 출시 계획을 위한 스토리맵의 원칙

제품 출시를 위한 스토리맵 예시

1. 출시하고자 하는 것들을 모두 포섭한다.

2. 출시하고자 하는 기능이 필요로 하는 사용자와 시스템을 인지한다.

3. 사용자와 시스템을 단위로, 이야기의 흐름을 구축한다.

4. 좌→우 순서는 이야기의 순서를 의미하며, 상→하 위치는 스토리의 위계를 의미한다.

5. 완벽한 순서를 시각화 하는 데에 집착하여 시간을 낭비하면 안 된다. 스토리매핑을 공동의 이해를 위해 하고 있음을 기억해야 한다.

이야기를 확장하라

제품의 시스템을 결정하기 위해서는 제품 외부에서 어떤 것이 이뤄지길 바라는지 집중해야 한다.
Focus on what you hope will happen outside the system to make decisiosn about what’s inside the system.

제품 출시를 위한 스토리맵 개괄

제품의 목적을 이루기 위해 필요한 기능의 이야기들을 모두 스토리맵화 한다. 스토리맵의 최상단에는 이야기의 척추가 되는 핵심(backbone) 스토리가 위치한다. 핵심 스토리의 하단에는 해당 이야기에서 사용자가 제품에서 취하는 활동들을 순서대로 적는다. 그리고 각 스토리 활동 하단에는 해당 활동의 상세 설명을 적는다.

스토리를 만들다보면, 스토리가 양적으로 많아질 뿐만 아니라 다양한 층위의 스토리가 발생한다. 이러한 상황에서는 스토리들을 묶고, 묶은 스토리에 대해 더 큰 개념의 요약된 스토리로 표현하는 것이 좋다. 즉, ‘큰’ 이야기와 ‘작은’ 이야기로 나뉘게 된다.

만들고자 하는 제품의 기능은 너무나도 많을 것이다. 그리고 그러한 기능은 수많은 이해관계자의 관여를 요구할 수도 있다. 스토리맵에서는 그러한 이해관계자가 누구인지, 그리고 그것을 어떻게 사용할 것인지, 그리고 스토리간 의존성이 존재하는지에 대한 것들을 모두 시각적으로 표현해야 한다.

Globo.com의 스토리 매핑, https://vimeo.com/102364139

개발 범위가 확대되는 것이 아니다. 우리의 이해가 확장되는 것이다. (Scope doesn’t creep: understanding grows.)

스토리 맵은 머리 속에만 있었던 논리를 시각화함으로써 놓치거나 빈 부분을 빠르게 확인해줄 수 있게 해준다. 뿐만 아니라, ‘이런 경우는?(what about)’의 질문을 통해 발생할 수 있는 위험을 인지할 수 있게 된다.

그런데, 스토리맵을 사용하는 사람들이 자주 불평하는 부분은 겉잡을 수 없이 이야기의 숫자가 많아진다라는 점이다. 모든 가능성에 대해 이야기하게 됨에 따라, 고려해야 하는 것들의 숫자가 기하급수적으로 늘어나면서 ‘개발 범위 확대(scope creep)’ 현상이 나타난다.

하지만 우리는 이 모든 것을 개발한다고 하지 않앗다. 그리고 개발 범위 확대는 본질적으로 어떤 것이 일어났기 때문이다. 바로 ‘이해’다. 우리가 만드는 것들이 야기할 것들에 대해 더욱 이해하게 되는 과정이며, 제품이 발생시킬 수 있는 위험들을 미리 인지하는 것이다.

성과에 집중하여 이야기를 조각내고, 분리한다.

타겟 고객군의 고통, 필요, 욕망을 해결하고 원하는 작업을 완수할 수 있도록 하는 것이 제품의 ‘성과(outcome)’다. 우리가 생각해낸 스토리들은 그 성과를 충분히 이루기 위해 필요한 것인지에 대해 고민해봐야 한다.

물론, 화려한 애니메이션이나 부가적인 컨텐츠들이 제품의 매력도를 끌어올리거나 다른 기능과 시너지를 낼 수도 있다. 하지만 우리의 자원이 턱 없이 부족하며, ‘매력’을 올리기 위해 기본적인 것도 챙기지 못 하는 상황이 발생하면 안 된다.

기능을 우선순위화 하는 것이 아니라, 성과를 우선순위화 한다.

적정한 범위의 이야기를 포함하는 제품을 만들기 위해서는, 제품이 달성해야 하는 목표 성과에 대한 순차적인 구분이 필요하다. 사용자의 목표 성과를 중요도에 따라 순차적으로 단계화 시키고, 각 단계에 맞는 스토리의 상세 설명들을 각 목표 성과에 맞게 분류한다.

각 목표 성과는 출시 로드맵이 된다. 목표 성과가 성취되면 다음 목표 성과로 넘어가며 업무를 진행하면서, 점진적인 출시 전략을 만들어 낼 수 있다.

세부적인 우선순위를 결정하는 방법

스토리 단위뿐만 아니라 상세 설명이나 기능 단위에서도 우선순위가 존재할 수 있다. 이러한 미시적인 단위의 결정을 위해 해당 상세 사항들을 구분하는 분류는 다음과 같다.

차별화 요소(differntiator): 경쟁사와 차별화되는 특징

모방 요소(spoiler): 다른 경쟁사가 가지고 있는 차별화 요소를 모방하여 그 경쟁사의 우위를 잠식하려는 특징

비용 절감 요소(cost reducer): 조직의 비용을 줄일 수 있는 특징

필수 요소(table stakes): 해당 시장에서 경쟁하기 위해 반드시 갖추어야 하는, 없으면 경쟁에서 뒤처지는 기본적인 특징

하나의 상세 사항이 누군가에겐 ‘차별화 요소’일 수도 있고, ‘비용 절감 요소’일 수도 있다. 목표 성과를 상기하고 각 상세 사항에 대해 논의해보면서, 각 상세 사항들에 대한 우선순위를 세우는 것도 큰 도움이 된다.

최소 기능 제품은 가설을 검증하기 위한 것이다.

‘Viable’이라는 영어 단어는 ‘실행 가능한’이라는 뜻도 있지만, 생물학적으로는 ‘스스로 생존 가능한’이라는 뜻을 가지고 있다. ‘최소 기능 제품’이란, 기능적으로 최소로 적용된 제품이 아니라, ‘사용자의 목표 성과를 이뤄내어 스스로 자생 가능한 소프트웨어’을 의미한다.

그렇기 때문에 최소 기능 제품은 고객과 사용자의 정보가 뾰족하고 뚜렷하며, 그 사람들이 무엇을 이루고자 하는지가 명확할 수밖에 없다. ‘불특정 다수가 수행하는 어떤 일’의 수준으로 구축된 제품은 ‘목표 성과’를 지니고 있을 수 없다.

최소 기능 제품은 ‘제품’의 역할을 위해 만들어진 것이 아니다. 우리가 스토리 매핑을 수행하고 제품에 점차 가까워지면 ‘제품을 만드는 것’에 대해 집착하게 되어 잠식적으로 주객전도되는 현상을 겪는다.

물론, 우리가 성공적인 제품을 만들기 위해 스토리 매핑을 하고 MVP를 계획하는 것이지만, MVP는 우리가 다룰 수 있는 수많은 사업적 기회들의 일부에 불과하다. 우리는 그러한 사업적 기회들이 정말 유용한 기회인지 빠르게 밝혀내고, 더 나은 기회가 필요하다면 그 기회로 이동하기 위한 결정을 하기 위해 스토리 매핑을 수행하는 것이다.

우리가 잊지 말아야 할 스토리 매핑의 진짜 사업적 목적은 다음의 질문으로 해소할 수 있어야 한다.

‘우리가 가지고 있는 가장 큰, 혹은 위험한 가설은 무엇인가?

‘불확실성이 가장 큰 지점은 무엇인가?’

‘우리가 실제 정보를 마주했을 때, 우리는 이 정보를 통해 무엇을 배울 수 있을 것인가?’