💦 나만 모르는 프로덕트 관리 이야기
[ 💬 실무에서 쓰는 유저스토리 활용법]
(👀간단 요약)
📌 유저스토리란? : [제품을 통해 사용자가 할 수 있는 행동]
✓ 유저스토리란 ‘사용자가 니즈를 만족하기 위해 우리 제품을 통해 할 수 있는 행동’
✓ “고객은 식당을 검색해서 음식을 배달시켜 먹을 수 있다"정도로
✓ 사용자가 원하는 행동을 직접적으로 담는 것
✓ 결과적으로 프로덕트를 만든다는 것은 여러가지 유저스토리를 쓰고 이것을 현실 세계로 불러오는 과정
📌 왜 쓰나요?
✓ 유저스토리는 사람과 컴퓨터가 대화하기 위해
✓ IT기업이 만드는 것은 결국 프로그램의 코드
✓ 일반 고객들의 생각은 중간에 불순물이 너무 많기 때문에 프로그래밍으로 곧장 치환할 수 없음
✓ 기획자의 일이란 사람들 생각의 핵심을 일반화하여 주어 + 목적어 + 서술어의 형태로 간결하게 만드는 것
✓ 1) 가벼운 생각 → 2) 고객의 니즈 → 3) 유저스토리 → 4) 상세 설계
✓ ‘흠.. 이 식당 맛있는지 궁금한데?’생각을 ‘주변 음식점의 후기를 조회할 수 있다’는 유저스토리로
✓ ‘배달이 언제쯤 오려나?’라는 생각을 ‘고객은 배달원의 위치와 예상 도착시간을 확인할 수 있다’는 유저스토리로
📌 어떻게 쓰나요?
✓ 크게 문장을 3개 요소로 나누어 작성
✓ ‘누가, 무엇을, 왜' (영어로 하면 who, what, why)
✓ 누가(who) : 고객(사용자)은
✓ 무엇을(what) : 점포의 평점 및 리뷰 갯수를 확인할 수 있다.
✓ 왜(why): 구매 의사결정에 참고할 수 있도록
✓ 실무에서는 훨씬 단순한 포멧 활용
📌 실무는 무엇이 다른가요?
✓ 첫째, ‘왜'를 잘 쓰지 않음. 굳이 쓸 필요가 없기 때문
✓ 상당수의 기능이 이미 존재 자체로 목적을 어느정도 설명할 수 있기 때문
✓ 유저스토리 작성 전 제품의 1) 당위성 2) 주요 기능 3) 방향성에 대해 팀원 모두 큰 들에서 합의되는 경우가 많
✓ 둘째, 실무의 유저스토리는 최대한 짧고 간결하게 작성
✓ 1) 안긴 문장, 2) 과도한 형용사, 3) 늘어지는 서술어는 모두 잘못된 유저스토리를 방증
✓ 장황한 유저스토리는 꼼꼼함의 징표가 아니라 명료한 커뮤니케이션을 피하는 무능
📌 조금 더 자세히 살펴보기
✓ 유저스토리에서 필수적인 작성 규칙이란 ‘누가' ‘무엇을' 할 수 있다 뿐
✓ 그 외 정보는 상황에 따라 기획자가 판단해서 추가/삭제해도 무
✓ 첫째, 유저스토리는 위계가 존재, 큰 유저스토리 아래 하위 유저스토리
✓ 원하는 기능을 단도직입적으로 설명하는 대기능 문장과 이를 뒷받침하는 소기능 문
✓ 필요 기능을 생각나는 대로 나열하는 것이 아니라 주요 기능을 먼저 쓰고 상세 기능을 하위에
✓ 둘째, 작은 유저스토리는 화면단위로 세분하여 작성
✓ 디자인 및 개발 직군의 동료들이 기능을 상상하며 작업하는데 유용
✓ 셋째, 하나의 유저스토리에 고객, 판매자, 관리자 처럼 여러 사용자가 존재할 수 있음
✓ 1개 기능의 유저스토리만 작성하더라도 여러 사용자의 입장을 동시에 고려할 수 있어야
📌 인수 기준이란?
✓ 유저스토리와 꼭 함께 나오는 것이 인수기준
✓ 유저스토리를 만들 때 ‘A,B,C 조건이 달성되어야 해당 기능이 만들어진 것으로 판단하겠다’는
✓ ‘주문자는 배달원에게 메시지를 남길 수 있다’라는 유저스토리가 있다면
✓ 메시지는 100자 이내로 작성/편집/삭제가 가능하다.
✓ 메시지 작성 내용을 저장할 수 있다.
✓ 메시지 작성 내용을 재사용할 수 있다.
✓ 유저스토리에는 기능의 요지만 담고 필요한 요건은 인수기준에 나열해 두는 식
📌 누구와 사용하나요?
✓ 유저스토리는 가장 먼저 디자이너와 함께 확인
✓ 기획자는 먼저 자신의 생각을 정리해 유저스토리를 전달
✓ 디자이너는 이를 통해 구체적인 웹/앱의 모습을 상상
✓ 기획자가 제안한 기능의 맹점, 모순된 정책, 논리적인 헛점을 짚고 비판
✓ 드잡이까지 하는 공동 회의를 여러차례 거치면 유저스토리가 깨끗하게 정제
✓ 그 문장을 기준으로 시각적인 화면이 탄생