유저스토리로 멤버십 서비스 기획하기
이용자 상태가 다양하면 각각의 시나리오를 확인해야 한다.
앞서, 담당하지 않았던 프로덕트에 대한 배경과 목적을 이해하였다.(이전 글 : 하루아침에 유료 멤버십 담당자가 되었다) 그렇다면 실전인 만큼 기획에 착수해야 하는데, 문서가 업데이트되지 않아 또 다른 난관에 봉착하게 되었다.
문서가 다를 땐 PO, PM, 기획자로서 어떻게 해야 할까?
1. 가능한 모든 문서를 찾고, 살펴본다.
관련자료를 모두 수취하여 살펴본다. 예시로 나는 QA팀의 *TC문서를 받아서 봤다. 그동안 과제에서 검증 항목들이 무엇이었는지, 시나리오를 확인할 수 있다. TC만 봐도 대략적인 서비스들이 눈에 들어오기 시작한다.
*TC : 테스트 케이스(Test Case)란 명세 기반 테스트의 설계 산출물로 설계된 입력값, 실행조건, 기대 결과로 구성되어 있는 테스트 항목의 명세서를 의미한다.
2. 개발자와 함께 코드를 까본다.
이 정책이 아직도 유효한지 확인해 보려면 직접 개발자에게 코드를 봐달라고 할 수 있다. 문서는 사람이 지속가능하게 수정하지 않는 한, 업데이트가 끊긴다. 최신 문서라고 확신할 수 없는 것이다. 다만, 라이브 환경에서의 개발 코드는 fact를 말해준다. 해당 동작으로 사용자들이 움직이고, 서비스가 돌아가기 때문이다. 이보다 더한 사실이 어디 있겠는가. 개발자와 함께 코드를 분석하는 것도 현황파악을 하기 좋은 방법이다. (너무 귀찮게 하지 않도록 잘 조절하는 건 센스.)
자, 이제 과거 문서를 통해 대략적으로 파악했으니 기획에 들어갈 시간이다.
각 프로젝트 방식에 맞는 산출물들이 있는데, 나의 상황은 충분한 시간을 갖고 기획하기보다는 정책과 사용자 시나리오, 기능정의를 단 기간 안에 빠르게 쳐내야 하는 상황이었다. 이런 경우에는, UserStory를 가장 잘 활용할 수 있다. 유저스토리(Userstory)를 잘 쓰면 정책과 + 사용자 시나리오 + 기능정의를 한 번에 할 수 있다. User Story는
개발할 내용을 작은 조각(epic)으로 쪼갤 수 있어야 하고,
작게 쪼갠 조각(epic)은 독립적으로 동작할 수 있어야 한다.
이 작은 조각들을 나열하면 개발해야 하는 항목(Task)이 된다.
이 Task들은 모두가 검증할 수 있도록 작성되어야 한다.
(아 어렵네...라고 생각할 수 있지만)
UserStory가 처음이라면, 딱 이 세 가지만 기억하면 된다.
Given When Then.
- 어떠한 상황이 주어지고 (*사전 상황 명시)
- 어떠한 행동을 하면 (*사용자 액션 설명)
- 이런 결과가 나타난다.(*사용자 액션에 대한 결과)
멤버십 가입 플로우를 예시로 들자면, 아래와 같다.
Given : 멤버십 소개페이지 진입
When : 가입 모달 클릭
and : 이용약관 클릭 (*추가적인 사용자 액션 설명)
Then : 멤버십 가입이 완료되어야 한다.
멤버십 서비스에서 '유저 스토리'를 추천하고 싶은 이유는 이용자들의 상태 값이 다양하기 때문이다.
아래는 보편적으로 구분되는 멤버십 이용상태의 '일부'이다.
initial : 구독을 한 번도 안 한 상태
subscribed : 멤버십 구독 상태, 결제일마다 결재 및 구독 일자 갱신 (구독 상태)
unsubscribed : 멤버십 미구독 상태 (구독이력이 있는 해지 상태)
renewal : 멤버십 갱신 성공 상태 (결제 성공)
멤버십 이용자 상태 copyright 조나현이 외에도 1차 결제에 실패한 사람들, 현재는 멤버십에 가입되어 있지만 해지 요청한 사람들 (해지대기) 등 서비스별로 정의 내리는 이용자 상태 값이 있다. 같은 멤버십이어도, 사용자들이 처해있는 각 상황은 다르다. 이 모든 케이스들을 고려하기 위해서는 각각의 시나리오를 확인할 필요가 있다.
A에서 B 동선으로 이동하는데
- 구독을 한 번도 안 한 사용자 들 게엔 이런 결과가
- 구독을 한 사용자들에겐 이런 결과가
- 구독 해지 신청을 한 사용자들에겐 이런 결과가 나타난다. 를 정의해야 하기 때문이다.
유저스토리를 복잡하게 생각할 필요는 전혀 없다. 화면 하나에 Given - When - Then 3가지 조건에 맞춰 기능을 적으면 바로 유저스토리이다. 보통 사용자의 액션이 필요한 버튼이나, 동작 위주로 정의할 수 있겠다.
한 가지 팁을 적자면, 문장을 적을 때 '(사용자는) - 할 수 있다.' 혹은 '(동작은 이렇게) - 되어야 한다'로 기술하는 편이 좋다. 그리고 짧으면 짧을수록 좋다.
다음은 프로젝트 회고를 진행하면서 멤버십 서비스에서 '유저스토리' 사용에 대한 회고 내용 일부를 가공한것이다. (프로젝트 진행 시의 대외비가 섞여있어서 일부만 발췌하게 된 점은 너른 마음으로 양해해 주시길�)
각 기능 조직들에서 생각한 점은 위와 같았다. 물론 장점만 존재한 것은 아니었다. 유저스토리에 너무 세세하게 디자인까지 정의할 경우, 프로덕트 디자이너의 역할과 범위가 좁아지게 되고. 동선을 잘 못 기술했을 경우 QA에서 작성하는 TestCase에 혼란을 줄 수도 있다.
꼭 애자일 하게 일하기 위해 유저스토리를 작성하는 건 아니다. 다만, 하나의 서비스에 사용자들이 처해있는 상황이 다르다면, 유저스토리는 기획 개발에 큰 도움이 될 수 있다. 내가 생각해 본 장점은 아래와 같다.
장점 1. 킥오프 자리에서 자연스럽게 기술 검토와 개발 방향성을 확인할 수 있다.
유저스토리는 사용자 관점에서 시나리오를 작성한 것으로, 사용자 요구 사항과 우선순위를 개발 팀에 전달하기 위해 사용한다. 보통은 이 UserStory를 보며 킥오프 자리에서, BE부터 검증이 들어간다. 개발자가 어떤 코드를 어디에 맞춰 개발할지가 보이는 것이다.
장점 2. PO는 문서를 정리할 시간을 벌고, 개발 착수일을 당길 수 있다.
그렇게 유저스토리를 주말에 작성하고, 월요일에 킥오프에 들어갔는데... 너무나도 평화롭게(?) 개발 싱크를 맞출 수 있었다. 나는 "혹시 개발하시는데 더 필요한 문서가 있으실까요? 정책서라던지...." 물어보자마자
한 개발자분이 "아 이제부터 개발 들어가면 됩니다. 더 이상의 문서는 괜찮습니다"라고 답해주셨다.
그동안의 걱정이 싹 씻겨 내려가는 듯했다.
시간이 부족한 만큼, PO, 기획자를 옭아매는 문서 지옥에서 빠르게 벗어날 수 있었고, 개발자들이 개발을 진행하는 동안 나는 유관부서에게 공유할 정책 자료들을 정리할 수 있었다.
장점 3. PO, PM, 서비스기획자가 작성한 문서를 TestCase 삼아, 검증할 수 있다.
보통 개발을 하게 되면, QA 전 개발자들은 BAT를 진행한다. BAT 진행 뒤, QA에서 TC를 검증하게 되는데, 이때 테스트를 위한 별도의 문서를 작성할 필요가 없다. 기획자 혹은 PM, PO가 작성한 유저스토리가 바로 가장 중요한 사용자 기대 결과이기 때문이다. 스토리를 읽으며 검증을 하는 방식이다.
*BAT(Build Acceptance Test : 빌드 수용 테스트)
빌드 진행 후, 소프트웨어 핵심 기능이 정상 작동되는지 확인, 세세한 테스트를 진행할 준비가 되어 있는지 확인하는 과정.
장점 4. 개발 퀄리티가 올라갈 수밖에 없다.
UserStory의 핵심은, 앞단에서 개발 항목을 명확하게 하여 오류를 줄이는 것이 핵심이다. 개발자들이 유저 스토리 검증을 진행하기 때문에 퀄리티가 올라간다. 기존에는 검증했지만, 예상치 못한 시나리오에서 오류가 발생할 수 있는데, 최대한 앞단에서 확인 후 수정을 진행하기 때문이다. 개발자들도 사용자의 관점에서 테스트해보는 것이다.
여기까지가 멤버십 서비스 담당자가 아니었던 내가, 배경을 파악하고 사용자 관점에서 기능을 기술했던 이야기를 풀어보았다. 생각보다 높은 퀄리티의 개발을 챙길 수 있었고, 빠르게 배포를 할 수 있었다. 멤버십 서비스야말로, 내가 일했던 것 중에 가장 에자일 하게 일했던 프로젝트라고 말할 수 있을 것 같다. (꿈에도 나옴....)
아직 방심하긴 금물. 그 뒤로부터 이제 데이터 지옥에 빠지게 되는데... 이 것 역시 to be continue... 다음엔 멤버십 데이터에 대해서 이야기해보려고 한다!
