[책리뷰] 사용자 스토리 맵 만들기 (User Story Mapping)

 

올해 초 입사선물로 책을 선물받았다. 이 책은 PO로써 첫 발을 디딘 나에게 '어떻게 공유된 이해(shared understanding)를 만들어야 할지'에 대해 도움을 주었다. 애자일에서는 백로그를 만들 때 단순히 기능을 명시하기 보다는 '스토리'로 표현한다고만 알고 있었는데, 이러한 스토리가 모여 어떻게 스토리맵을 만드는지를 책을 통해 배울 수 있었다. 아래는 책의 일부 내용이다.

---

좋은 스토리 대화는 단지 무엇에 대해서만이 아니라 누구와 왜에 대해 이야기하는 것이다. (...) 스토리는 요구사항이 아니다: 무엇을 만들어야 할 지를 놓고 그 기준이 되는 우리 조직, 고객 그리고 사용자 들의 문제 해결에 대한 토론이다.

 

실질적으로 이야기해야 할 내용에 대한 점검 목록

- '그 사용자'가 아니라 상세하게, 어떤 사용자를 뜻하는지 누구에 관해 이야기하기

- 소프트웨어로 사람들이 하고 싶어하는 것, '무엇'에 대해 이야기하기(사용자 활동으로 스토리를 시작하기)

- 사용자가 관심을 갖는 이유, 회사가 관심을 갖는 이유, 비즈니스 이해관계자가 관심을 갖는 이유 등 '왜'에 대해 이야기하기

- 우리 제품이 어디에 쓰이고, 얼마나 자주 사용되며, 다른 사용자는 누가 있을지 이야기하기

- 시스템이 다운되는 등 잘못되는 경우 사용자가 선택할 수 있는 대안에 대해 이야기하기

- 우리의 가설이 진정 사용자를 이해하고 있고, 정말 그들이 원하는 해결책인지, 사용자의 진짜 문제인지, 이 해결책을 정말 사용할지, 우리의 기술은 무엇이고 어떻게 동작하는지, 위험요소는 무엇이 있는지 이야기하기

- 다시 문제로 돌아가 더 효과적이고 경제적인 방법이 없는지 이야기하기

- 어떻게에 대해 이야기하기

- 얼마나 걸릴지 이야기하기

 

사용자의 관점에서 적절한 크기의 스토리란 요구를 충족시키는 것이다. 개발팀 관점에서 적절한 크기의 스토리란 만들고 테스트하는 데 단 며칠이면 되는 것이다. 비즈니스 관점에서 적절한 크기의 스토리란 비즈니스 성과를 이루게 하는 크기를 의미한다.

---

책을 참고하며 현업에서 User story Mapping 방법을 사용해보았다. 우리 프로덕트를 사용하는 고객이 누구이고, 어떤 문제에 직면해 있으며, 왜 우리가 이 업무를 하는지에 대해 공유된 이해를 만들기 위해 노력했었다. 하지만 이를 적용하기 위해서는 스쿼드원 모두가 애자일 방식에 대해 이해하고 있으며, 적극적으로 참여하는 분위기가 기반이 되어야한다는 것을 몸소 경험했다. 이러한 전제가 충족되었을 때, User Story mapping은 큰 방향을 보고 의사결정하는 데 매우 효과적인 것 같다.

 

번외로 책의 초입부에 이런 말이 있다.

사실을 말하자면 여러분의 일은 세상을 바꾸는 것이다. 여러분이 제품에 덧붙인 좋은 아이디어는 그 제품을 사용하는 사람들의 세계를 작게나마 바꾼다.

내가 하는 일이 누군가의 작은 세상을 바꾼다고 생각하면 사명감이 생긴다. 내가 하는 일은 고객을 위한 서비스를 만드는 것임을 잊지 말아야겠다고 다시 다짐해본다.