사용자 스토리 맵 만들기를 하는 이유

    "사용자 스토리 맵 만들기(제프 패튼 지음)"를 읽고 있다. 상당히 흥미로운 이야기였다. 기획자로 일하면서 답답했던 것 중 하나는 언제나 수십페이지짜리의 거대한 기획서를 작성해야 한다는 것이었다. 내가 만든 기획서 혹은 다른 기획자분들이 만든 기획서를 보면서 이걸 과연 개발자들이 다 읽고 이해할 수 있을까?라는 의문을 가졌던 적이 많았다. 문서화를 하느라 기획자는 엄청나게 많은 시간을 들인다. 그리고 개발자는 이 문서를 이해하느라 또 다시 엄청나게 많은 시간을 들인다. 그리고 끝끝내는 완벽한 이해를 공유하지 못하는 상황들이 펼쳐진다. 기획자와 개발자 모두 문서에 너무 많은 시간을 써버리는 바람에 정작 중요한 요소인 '고객'에 집중하지 못하는 경우도 많다. 사용자 스토리 맵은 바로 이런 문제를 해결해주는 획기적인 방법이다. 제품과 관련된 사람들이 모여서 사용자를 중점에 놓고 그를 위해 어떻게 제품을 만들어가야할 지를 논의한다. 포스트잇이 붙어있는 이상적인 회의실이 사용자 스토리 맵을 만드는 과정에서 구현된다. 내가 가졌던 답답함을 풀어주는 것이었고 당장 활용하고 싶다는 생각이 들었다.

 

    그러나 막상 이것을 실전에 도입하자니 조금은 막막하게 느껴졌다. 도대체 실전에서는 어떻게 써야한단 말인가. 무작정 스토리를 그리고 포스트잇을 회의실 벽에 붙이기만 하면 끝나는 것인가? 사실 사용자 스토리 맵의 구성 자체는 간단하다. 목표로 하는 사용자, 사용자들의 행동(Activity), 그리고 행동을 이루는 작은 이야기(Story)들, 이야기를 구현하기 위해 필요한 과업들(Task), 마지막으로는 각 릴리스가 목표로 하는 성과가 있다. 스토리 맵을 만드는 것 자체는 별 것 아니다. 누구나 사용자가 제품을 쓰는 흐름을 예상해볼 수 있고 이를 기반으로 단계별로 필요한 과업을 적을 수 있기 때문이다. 그런데 스토리 맵이라는 것이 이렇게 단순히 포스트잇을 붙이기 위해서 만들어진 것이 아니라는 점이다. 왜 스토리 맵을 쓰기 시작했는지 그 이유를 명확히 파헤쳐야 스토리 맵을 실전에 적합하게 적용해볼 수 있을 것이다.

 

    유저 스토리 매핑의 본질은 무엇일까? 하나는 '공유된 이해'를 만드는 것이며, 다른 하나는 '최소 투자, 최대 성과'를 거두는 것이다. 공유된 이해를 만든다는 것은 문서의 한계에서 출발했다. 방대한 분량의 문서는 기획자와 개발자 사이의 명확한 이해를 공유하는 것을 가로막는다. 실제 대화를 하면 글로는 느낄 수 없는 무언가를 느낄 수 있다. 스토리 맵은 참여자가 하나의 이야기를 만들어가는 과정 속에서 자연스레 공유된 이해를 만드는데 도움을 준다. 또 다른 목표인 '최소 투자, 최대 성과'는 '언제나 만들 수 있는 것보다 만들고 싶은 것이 더 많다.'는 원칙에서 출발한다. 사용자를 중점에 두고 면밀히 분석하지 않으면 아무도 사용하지 않을 기능들을 만들게 될 가능성이 높다. 유저 스토리 맵은 사용자를 중심에 두기 때문에 어떤 기능이 가장 필수적인지 그리고 어떤 기능이 가장 부차적인지를 생각해볼 기회를 제공한다. 그래서 투입량은 줄이고 성과는 늘리는 방향으로 프로젝트를 조정할 수 있게 된다.

 

    유저 스토리를 맵을 실전에 적용하는 방법을 아직 완전히 익히지는 못했지만, 반드시 적용하고 싶다는 생각을 하게 되었다. 스토리 맵 기법을 쓰면 이전보다 몇 배는 효율적인 작업이 가능할 것이라 믿는다. 내가 회사에 꼭 유저 스토리 맵의 정신을 불어넣어보겠다.

 

 

2023.01.09.