좋은 유저스토리란 무엇일까?
왜 쓰는지 알고 쓰는 유저스토리
PM은 유저스토리라는 단어를 자주 접합니다.
하지만 의외로 1. 이게 뭔지, 2. 왜 쓰는지, 3. 어떻게 쓰는지 차근차근 알려주는 경우는 흔치 않습니다. 그냥 남들도 다하니까 관성적으로 쓰는 경우가 많다고 할까요? 이번 챕터에서는 유저스토리에 대해 간단한 예시와 함께 짚어보겠습니다.
1. 유저스토리란?
유저스토리란 [제품을 통해 사용자가 할 수 있는 행동]을 말합니다.
사용자는 현실에서 다양한 문제를 만납니다. 문제는 니즈로 이어집니다. 예를 들어 '배고프다, 치킨 시켜 먹고 싶은걸?' 정도의 가벼운 문제가 발생했다 하겠습니다. 이런 생각은 '주변에 치킨 맛집 찾아서 주문하고 싶다'는 구체적인 니즈로 발전할 수 있습니다.
유저스토리는 니즈를 만족시키는 행동입니다. “고객은 식당을 검색해서 음식을 배달시켜 먹을 수 있다"처럼요. 프로덕트를 만든다는 것은 여러개의 유저스토리를 쓰고 이것을 현실 세계로 불러오는 과정입니다. 마법으로 치자면 주문서와 동일한 역할이라 하겠습니다.
2. 왜 쓰나요?
유저스토리는 사람과 컴퓨터가 대화하기 위해서 씁니다.
IT기업이 만드는 것은 결국 프로그래밍 코드입니다. 유저스토리는 사용자의 잡념을 코드로 바꾸기 전 불순물을 제거하는 과정입니다. 1) 현실의 문제 → 2) 고객의 니즈 → 3) 유저스토리 → 4) 상세 설계서 → 5) 프로그래밍 순으로 발전합니다.
예를 들어 아래 2개의 사례를 비교해 보면 어떤 문장이 프로그래밍에 적합한지 보일겁니다.
사용자 : 이 식당 맛있는지 궁금한데?
유저스토리 : 고객은 주변 음식점의 후기를 조회할 수 있다
사용자 : 배달이 언제쯤 오려나?
유저스토리 : 고객은 배달원의 위치와 예상 도착시간을 확인할 수 있다
엔지니어들은 유저스토리를 보고 자신이 해야 할 과업을 정확하게 이해합니다.
3. 어떻게 쓰나요?
유저스토리는 [누가], [무엇을], [왜]로 나누어 씁니다.
영어로 하면 who, what, why입니다. 배달 프로덕트를 예시로 설명해 볼까요?
누가(who) : 사용자는
무엇을(what) : 점포의 평점 및 리뷰 개수를 확인할 수 있다.
왜(why): 구매 의사결정에 참고할 수 있도록
이렇게 쓰면 교과서대로 쓴 유저스토리입니다. 하지만 실무에서 한 번이라도 유저스토리를 직접 작성해 본 PM은 정석대로 쓰는 것이 굉장히 어렵다는 것을 압니다.
4. 실무만의 특징은?
첫째, [왜]를 잘 쓰지 않습니다.
굳이 쓸 필요가 없습니다. 예를 들어 앞서 예시로 든 [사용자는 점포의 평점 및 리뷰 개수를 확인할 수 있다, 구매 의사결정에 참고할 수 있도록]이라는 문장에서 마지막 절을 빼보겠습니다. 이해하는 데 문제가 없습니다. 상당수의 기능이 이미 존재 자체로 목적을 설명합니다.
PM은 유저스토리를 작성하기 이전 상위기획서로 프로젝트의 컨셉을 동료들에게 공유해 둡니다. 앞으로 만들 제품의 1) 당위성 2) 주요 기능 그리고 3) 미래 방향성에 대해 팀원 모두 큰 들에서 합의를 봐 놓았다는 뜻입니다. 이런 상황에서는 목적을 부연할 필요가 없습니다.
둘째, 최대한 짧고 간결하게 씁니다.
PM은 작업은 모두 가독성이 최우선입니다. 1) 안긴문장, 2) 과도한 형용사, 3) 늘어지는 서술어는 모두 잘못된 유저스토리를 방증합니다. 유저스토리가 긴 이유는 생각이 지저분하기 때문입니다. 유저스토리는 꼭 퇴고합니다. 걷어낼 거품이 끼어있을겁니다.
유저스토리가 자세하다고 제품이 잘 만들어지지 않습니다. 오히려 반대입니다. 프로젝트는 팀플레이입니다. ‘일단 나는 잘했는데, 너만 잘하면 돼’는 없습니다. PM이 생각하고 있는 내용이 디자인, 개발, 나아가 QA, 운영에게까지 정확하게 전달되어야 또렷한 제품이 만들어집니다.
5. 예시를 들자면?
유저스토리에서 필수 작성 규칙이란 ‘누가' ‘무엇을' 할 수 있다 뿐입니다. 그 외 정보는 상황에 따라 PM이 판단해서 추가/삭제해도 무방합니다. 예시를 한번 살펴볼까요?
이 케이스는 제가 예전에 리뷰 기능을 도입할 때 썼던 유저스토리를 조금 각색해 본 것입니다.
사용자 입장
Depth 1
사용자는 점포의 평점과 리뷰를 확인할 수 있다.
Depth 2
사용자는 점포 상세에서 평점 및 리뷰개수를 확인할 수 있다.
사용자는 리뷰 상세에서 리뷰 목록을 확인할 수 있다.
사용자는 내 정보에서 내가 쓴 리뷰 목록을 확인할 수 있다.
… (이하 생략)
관리자 입장
Depth 1
관리자는 점포의 평점과 리뷰를 관리할 수 있다.
Depth 2
관리자는 어드민 리뷰 탭을 조회할 수 있다.
관리자는 개별 리뷰를 활성 / 비활성 / 삭제할 수 있다.
관리자는 점포 별 리뷰 서머리를 조회할 수 있다.
… (이하 생략)
점포 입장
Depth 1
사장님은 점포의 평점과 리뷰를 관리할 수 있다.
Depth 2
사장님은 점포의 리뷰를 조회할 수 있다.
사장님은 점포의 리뷰에 답글을 달 수 있다.
사장님은 점포의 리뷰를 신고할 수 있다.
… (이하 생략)
여러 유저스토리가 나열되어 있지만 크게 보았을 때 ‘고객은 점포의 평점과 리뷰를 확인할 수 있다'라는 하나의 유저스토리에서 출발한 하위 문장입니다. 예시를 통해 알 수 있는 실무팁은 크게 3가지입니다.
첫째, 유저스토리는 위계가 있습니다.
큰 유저스토리 아래 하위 유저스토리가 있습니다. 원하는 기능을 단도직입적으로 설명하는 대기능 문장이 있고, 소기능을 부연하는 상세 문장이 있습니다. 유저스토리 작성 은 필요한 기능을 생각나는 대로 나열하는 것이 아닙니다. 주요 기능을 먼저 쓰고 상세 기능을 하위에 적어 넣습니다.
둘째, 화면단위로 세분하여 쓸 수 있습니다.
디자이너, 개발자와 소통하며 일하다 보면 화면 단위로 유저스토리를 쓰는 경우도 있습니다. 처음 유저스토리를 쓸 때는 큰 기능 단위의 문장만 쓰더라도, 프로덕트 설계가 구체화되면 화면 단위로 유저스토리를 쪼개는 것입니다. 디자인 및 개발 직군의 동료들이 기능을 상상하며 작업하는데 유용합니다.
셋째, 하나의 유저스토리에 여러 사용자가 존재할 수 있습니다.
배달 플랫폼의 사용자는 고객만이 아닙니다. 고객이 보는 화면은 전체 프로덕트 설계의 50% 이하일 겁니다. 단순히 리뷰를 노출하는 것은 쉽지만 그 리뷰에 점포 사장님이 답글을 다는 기능, 필요하다면 관리자가 삭제하는 기능까지 가능해야 제대로 운영할 수 있는 제품이라 할 것입니다. 유저스토리는 여러 사용자의 입장을 동시에 고려합니다.
위 3가지 특징이 실무 유저스토리 작성 방식의 정답이라는 것은 아닙니다. 함께 일하는 디자이너, 개발자들이 작성된 기획서를 잘 이해하고 의도대로 제작한다면 어떤 형태로 유저스토리를 작성하더라도 문제가 없습니다. 결국 [정제된 요구사항을 이해하기 쉽게 만든다]가 일의 핵심입니다.
6. 인수기준은 무엇인가요?
유저스토리와 꼭 함께 나오는 것이 인수기준(Acceptance Criteria)입니다. 쉽게 말해 유저스토리를 만들 때 ‘A, B, C 조건이 달성되어야 해당 기능이 만들어진 것으로 판단하겠다’는 뜻입니다. 과거 외주 개발이 일반적이던 시기 용어로 정착되었습니다. 같은 회사 안에서 인수하고 말고 가 어디 있겠어요.
예를 들어 [주문자는 배달원에게 메시지를 남길 수 있다]라는 유저스토리가 있다면
메시지는 100자 이내로 작성/편집/삭제가 가능하다.
메시지 작성 내용을 저장할 수 있다.
메시지 작성 내용을 재사용할 수 있다.
이런 식으로 인수기준을 작성할 수 있습니다. 즉, 유저스토리에는 기능의 요지만 담고 필요한 요건은 인수기준에 나열해 두는 식입니다.
인수기준은 완벽할 필요도, 그렇게 될 수도 없습니다. 앞서 유저스토리는 프로덕트 개발 초기에 작성하는 것이라고 말씀드렸습니다. 실무에서는 교과서처럼 완벽한 유저스토리가 작성될 수 없습니다. 대부분의 PM은 천재가 아니기에 기획 초기 필요한 모든 스펙과 기준을 알지 못합니다.
이럴 때는 오히려 생각나는 유저스토리와 인수기준만 가볍게 나열한 뒤 동료 기획자나 디자이너/개발자에게 빠르게 의도를 공유하고 피드백을 받아 수정하는 게 낫습니다. 꼼꼼함이라는 자원을 소모해야 한다면 인수기준보다는 상세설계서 작성에 쓰는 것이 경제적입니다. 최종적인 요구조건은 상세설계서로 전달하는 요령을 발휘해야 합니다.
7. 누구와 사용하나요?
유저스토리는 가장 먼저 디자이너와 함께 봅니다. 회사마다 일하는 방식이 조금씩 다르지만 상당수의 IT기업에서 PM과 디자이너는 짝꿍입니다. 대개 PM이 1) 산업 현장 파악, 2) 데이터 분석, 3) 사업 의사결정을 담당하면 제품의 상세 설계는 프로덕트 디자이너들의 눈과 손이 합니다.
PM이 먼저 유저스토리를 전달합니다. 디자이너는 이를 통해 구체적인 웹/앱의 모습을 상상합니다. 그리고 PM이 제안한 기능의 맹점, 모순된 정책, 논리적인 허점을 짚고 피드백합니다. 공동 회의를 여러 차례 거치면 유저스토리가 깨끗하게 정제되고 그 문장을 기준으로 시각적인 화면이 탄생합니다.
유저스토리는 개발자와도 사용합니다. 개발자는 대개 티켓(작은 일의 단위) 형태로 과업을 관리합니다. 쏟아지는 업무를 체계적으로 관리하기 위해 백로그(티켓 더미)를 운영하는데요. 티켓을 유저스토리 단위로 작성해 두면 현재까지 처리한 작업과 앞으로 해야 할 과업을 논리적으로 구분하기 편리합니다.
개발자가 작업을 완료한 뒤 프로덕트를 배포할 때 “이번에 1,2,3번(유저스토리) 나갑니다”라는 식으로 커뮤니케이션하면 동료들이 버전을 관리하고 제품의 현황을 파악하는데 유용합니다. 결국 뒷단에서 아무리 복잡한 설계가 있다고 하더라도 세상에 나가는 제품은 사용자들이 원하는 기능(문장)을 만들었다고 정리할 수 있습니다.
8. 정리
유저스토리는 기획 실무에서 굉장히 자주 쓰는 개념입니다. 하지만 개념을 잘못 이해하면 ‘왜 하는지 모르고 하라니까 하는 일'이 되기 십상입니다. 정리하자면 유저스토리는 프로덕트팀이 할 일을 개발 조직, 나아가 기계까지 함께 이해할 수 있는 문장으로 다듬기 위함입니다.
유저스토리 작성 목적을 똑바로 이해하면 형식에 얽매이지 않습니다. ‘다른 직군 동료와 동일한 프로덕트를 생각하기 위해'라는 목적이 모든 형식에 앞섭니다. 기본적인 내용만 잘 담은 뒤 상호 이해하기 좋은 형식이 있다면 어떠한 커스텀도 무방합니다. 작업의 본질을 잘 살려서 사업적인 목표를 개발 설계로 연결하는 교두보 역할을 할 수 있다면 어떤 문장이든 [충분히 잘 쓴 유저스토리]라 하겠습니다.
yve.atelier