728x90

안녕하세요, 꾸우._.입니다. 이번주에는 패스오더 개선사항에 대한 유저 스토리를 작성해보고, 그에 따른 이해 관계자의 요구사항을 파악 후 정리해보겠습니다.

 

 

📌 패스오더에서 고쳤으면 할 문제와 개선해야 할 기능

줄곧 과제로 분석해 온 패스오더에 대한 개선사항을 찾아보았는데요. 지난 과제에서 MVP 개선안으로 제시했던 내용을 중점적으로 다룰 예정입니다.

 

💡 주문, 결제 시 원하는 시간을 선택해 수령 시간을 설정해도 매장 상황에 따라 제 시간에 못 받는 경우가 있다.

해당 부분에 대해서 네이버 블로그에 후기를 남겨주신 분의 게시글을 참고했습니다. 

출처 : 네이버 블로그

지난 과제 진행 중 발견했던 한 고객님의 경험입니다. 출퇴근 시간에 바로 수령할 때도 있지만 매장이 너무 바쁘면 오히려 기다리다가 출퇴근 시간에 늦을 뻔한 적 있다고 언급하셨습니다.

 

그렇다면 패스오더에 입점한 매장의 사장님들께선 어떤 문제점을 가지고 계실까요?

다음은 패스오더를 실제로 사용하신 사장님들이 언급하신 문제점입니다.

출처 : 네이버 카페

패스오더를 통해 주문을 받고 있으나, 매장에 여러 개의 많은 주문이 한꺼번에 밀려 들어올 경우, 픽업 시간 조절과 피크 관련 공지를 띄울 수 있다고는 하나, 바쁜 상황에서 그런 것을 일일이 설정하거나 패스오더 측에 요청할 여력이 안된다는 것을 주요 문제점으로 꼽고 있는 것으로 파악했습니다. 

 

💡 [자주 가요] 탭에서 별도로 자주 가는 매장을 취급하고 있으나, 사용성이 불편하다.

현재 패스오더에서는 고객의 주문 내역을 기반으로 '자주 가요' 탭을 별도로 분류해 자주 가는 매장을 따로 볼 수 있도록 제공하고 있는데요, 해당 부분에 대해 사용하는 것이 불편하다는 사용자의 경험을 확보했었습니다.

아래는 지난번 6주차 과제를 진행하면서 A/B 테스트 대신 진행했던 설문조사의 답변 일부입니다.

설문조사 응답 일부 발췌

자주 가는 매장 리스트를 제공하고 있음에도 불구하고, 홈 화면에 바로 보이지 않아 불편했다는 응답을 확보했습니다. 이를 통해 자주 가는 매장 리스트를 제공함에 있어 UI 개선이 필요하겠다는 생각이 들어 개선할 기능으로 선택하게 되었습니다.

 

 

📌 유저 스토리 작성하기

위에 정의한 문제점 및 개선해야 할 기능들을 바탕으로 작성한 유저 스토리입니다. 유저 스토리에 대해 정리한 게시물을 첨부하니, 필요하신 경우 참고하시기 바랍니다.

 

35. 사용자의 시스템 사용 이야기, 유저 스토리 (User Story)

안녕하세요, 꾸우._. 입니다. 이번에는 하나의 시스템 사용기, 유저 스토리에 대해 알아보고 정리해보겠습니다. 📌 유저 스토리 (User Story) 유저 스토리는 하나의 시스템 사용에 대한 이야기를 의

jkkou.tistory.com

  As a, I want, So that Given - When - Then
매장에 현재
접수된
주문 건수
  • As a : 출퇴근길에 바쁜 직장인으로서
  • I want : 기다림 없이 원하는 시간에 음료를 받길 원한다
  • So that : 출퇴근 시간이 늦어지지 않도록
  • Given : 메인 화면의 매장 리스트에서
  • When : 고객이 음료를 주문하고자 할 때
  • Then : 각 매장별로 현재 접수된 주문 건수가 보여야 한다
매장 바쁨 정도
(주문 지연 시간)
  • As a : 많은 주문이 밀려들어 온 매장의 사장으로서
  • I want : 매장의 주문 접수 상황을 알리길 원한다
  • So that : 바쁜 와중에 픽업 조절 시간, 피크 관련 공지를 작성해야 하는 번거로움이 없도록
  • Given : 메인 화면의 매장 리스트에서
  • When : 고객이 음료를 주문하고자 할 때, 매장에 밀린 주문이 많을 때 
  • Then : 각 매장별로 지연 예상 시간 (또는 매장의 바쁨 정도)을 표시해야 한다.
자주 가는 매장
  • As a : 선호하는 매장이 있는 사용자로서
  • I want : 자주 가는 매장 리스트가 한 눈에 보이길 원한다
  • So that : 매장 선택하는 것이 불편하지 않도록
  • Given : 메인 화면에서
  • When : 고객이 선호하는, 자주 가는 매장을 찾고자 할 때
  • Then : 자주 가는 매장 리스트가 보여야 한다
자주 먹는 메뉴
  • As a : 자주 먹거나 선호하는 메뉴가 있는 사용자로서
  • I want : 자주 먹는 메뉴들이 한 눈에 보이길 원한다
  • So that : 메뉴를 일일이 찾아 주문하는 불편함이 없도록
  • Given : 메인 화면에서
  • When : 자주 마시는 음료를 빠르게 주문하고자 할 때
  • Then : 자주 먹는 메뉴 리스트가 보여야 한다

 

 

📌 유저 스토리 우선순위 선정하기

작성한 유저 스토리의 우선순위를 정하기 위해 다양한 프레임워크를 고민했고, 그 결과 ICE 프레임워크와 MoSCoW 프레임워크 중 MoSCoW 프레임워크를 활용기로 했습니다. ICE의 경우, 여러 아이디어에 대한 점수 측정을 저 혼자서 할 수 밖에 없는데, 그럴 경우 MoSCoW에 비해 제 주관이 지나치게 치우칠 것이라 생각했기 때문입니다.

 

💡MoSCoW 프레임워크

MoSCoW는 요구사항의 우선순위를 정하는 간편한 방법론으로, Must Have, Should Have, Could Have, Won’t Have의 줄임말입니다. 즉, 제품 릴리즈에 대한 개발 작업 중 우선 순위를 쉽게 설정하기 위해 만들어진 프레임워크라고 볼 수 있습니다.

  • Must have : 프로젝트, 제품에 있어 반드시 필요한 기능을 의미
  • Should have : 중요하지만 시급성이 Must have 대비 낮은 기능
  • Could have : 있으면 좋지만, 꼭 있어야 할 필요는 없는 기능
  • Won’t have : 가장 덜 중요하고, 효과도 미미한 기능

 

해당 프레임워크를 바탕으로 작성한 유저 스토리의 우선순위와 선정 이유는 아래와 같습니다.

  1. Must have : 매장 바쁨 정도
    • 매장을 사용하려는 고객의 입장에서는 매장 상황이 바쁜지 바쁘지 않은지에 대한 파악이 필요하고, 입점돼있는 점주들의 입장에서는 설정한 수령 시간에 받지 못할 경우에 발생할 고객의 불편함을 감소시키기 위해 고객에게 직관적으로 알릴 수 있어야 한다고 생각합니다.
    • 그래서 매장에 요청한 주문이 고객이 원하는 시간 내에 완료될 수 없을 때, 매장 정보 화면에 매장의 바쁜 정도를 아이콘의 형태로 나타내어 고객이 매장 선택 시 한 눈에 볼 수 있도록 하여 해당 문제를 최우선적으로 개선하는 것이 좋겠다고 생각했습니다.
  2. Should have : 자주 가는 매장
    • 현재 패스오더에서는 [자주 가요] 화면을 별도로 두어 고객이 자주 가는 매장에 대해 한 눈에 볼 수 있도록 리스트를 제공하고 있습니다.
    • 그러나 해당 화면은 매장 리스트를 한 눈에 볼 수 있는 [홈] 화면과 구분되어 있어 화면 이동이 적지 않은 고객의 경우, 또는 패스오더의 사용이 익숙치 않은 고객의 경우 [홈] 화면에서 [자주 가요] 화면으로의 전환률이 자주 가는 매장에 대한 주문 건수 데이터에 비해 상대적으로 떨어질 수 있다고 생각했습니다.
  3. Could have : 자주 먹는 메뉴 
    • 자주 가는 매장 리스트와 다른 형태로 고객이 선호하는 메뉴를 한 눈에 볼 수 있는 리스트가 제공되면 좋겠다고 생각해서 아이데이션하게 된 기능입니다. 해당 기능은 사용자의 주문 내역을 기반으로 가장 주문 횟수가 많은 메뉴부터 나열하여 리스트로 제공하는 것입니다. 
    • 다만, 현재 제공하고 있는 자주 가는 매장 리스트를 개선하여 [홈] 화면에서 제공한다면, 고객은 자신이 선호하는 매장 페이지로 들어가 원하는 메뉴를 자유롭게 고를 수 있도록 할 수 있기 때문에 최우선으로 개선되어야 할 기능이 아니라고 생각해 Could have 에 배치하게 되었습니다.
  4. Won’t have : 현재 접수된 주문 건수
    • 패스오더는 최근 업데이트 이후, 각 매장별로 매장 썸네일에 '주문 수'를 제공하기 시작했습니다. 그런데 해당 데이터가 매장의 '누적된 주문 건수'인지, 일정 기간 동안 발생하는 '평균 주문 건수'인지는 구체적으로 기재되어 있지는 않았습니다.
    • 그러나 '주문 수'를 통해 고객은 해당 매장이 얼마나 많은 손님들이 매장에 주문하고 다녀가는지를 확인할 수 있고, 이를 통해 해당 매장이 고객들에게 인기 많은 매장인지 등을 파악할 수 있다고 생각했습니다.
    • 그래서 해당 기능이 제공될 경우, 현재 제공되는 '주문 수'와 겹칠 우려가 있고, 오히려 고객에게 혼동을 줄 수 있을 만한 기능이라 생각되어 제일 낮은 순위로 두게 되었습니다.

 

 

📌 화면 기획

위의 기능들을 반영해서 설계한 [홈] 화면과 [매장 정보] 화면입니다.

[홈] 화면 개선안

[홈] 화면에 제일 우선적으로 '자주 먹는 메뉴'와 '자주 가는 매장' 리스트를 제공합니다. '자주 먹는 메뉴'의 경우 메뉴 선택 시 바로 재주문을 할 수 있도록 하는 흐름으로 고려했습니다.

'자주 가는 매장'의 경우 별도의 탭으로 제공하던 것을 [홈] 화면으로 옮겨와 한 눈에 보일 수 있도록 하며, 다른 매장 리스트와의 형태에 통일성을 주고자 했습니다.

 

 

[매장 정보] 화면 개선안

매장을 선택해 [매장 정보] 페이지로 이동하면 할인, 적립, 그리고 주문 수 등을 비롯해 매장혜택, 운영 시간 등의 매장에 대한 기본 정보가 제공됩니다. 이 때, 수령 가능 시간 위에 매장의 바쁨 정도를 나타내는 아이콘을 추가했고, 해당 아이콘의 색상 변화에 따라 매장의 바쁜 정도를 고객에게 직관적으로 보일 수 있도록 했습니다.

 

아래는 해당 아이콘에 대한 간단한 디스크립션입니다.

매장 바쁨 정도에 따른 아이콘

접수된 주문량에 따라 매장의 상황을 붉은색, 노란색, 초록색으로 표시할 수 있도록 하며, 해당 기능의 경우 바쁨 정도를 나타낼 때 이에 대한 기준 주문량이 고려해야 할 요소라고 생각됩니다.

 

 

📌 패스오더 이해 관계자의 요구사항

이해 관계자는 크게 내부 관계자와 외부 관계자로 나뉩니다. 내부 관계자는 경영진, PM, 프로덕트 팀원, 마케팅 부서 등을 포함한 프로젝트에 참여하는 사내 구성원을 의미하며, 외부 관계자는 고객을 비롯한 투자자, 계약업체, 공급업체 등 회사 외부의 모든 사람을 의미합니다.

 

저는 패스오더 내부 관계자를 중심으로 요구사항을 정리해보았습니다.

 

💡패스오더의 내부 이해 관계자

저는 패스오더의 내부 이해 관계자를 크게 경영진과 개발자, 디자이너, QA, 마케팅 부서로 꼽았습니다. 개발자, 디자이너, QA의 경우 프로덕트를 위해 지속적으로 커뮤니케이션을 하며 나아갈 팀원이며, 경영진의 경우 패스오더를 통한 수익 창출이 그들의 주요 목적이고, 마케팅 부서의 경우 수익 창출을 위한 효과적인 마케팅 전략 수립이 주요 목적이라고 생각했기 때문입니다.

 

따라서 개발자, 디자이너, QA의 경우 요구사항을 프로덕트 개발, 개선 등에 초점을 맞추어 정리했습니다. 경영진의 경우, 새로운 기능 개발 또는 기존 기능 개선을 통한 핵심 지표 증가 방안을 함께 고려해달라는 요구를 할 것이라 생각했고, 마케팅 부서의 경우 기능의 홍보를 위해 새로운 기능이 개발되거나 기존 기능이 개선되기까지 소요되는 시간을 비롯해 구체적인 개발 및 배포 일정을 알려줄 것을 요구할 것이라 생각했습니다.

 

위를 바탕으로 요구사항과 그에 따른 유의사항을 정리한 표입니다.

 

  요구사항 유의사항
경영진 사업적 가치에 부합하는지에 대한 여부 확인
  1. 제품이 추구하는 방향성과 일치하는가
  2. 제품의 미션과 비전에 어긋나지 않는가
  3. 달성하고자 하는 비즈니스 목표에 부합하는가

기존 기능 개선 및 신규 기능 개발에 따른 핵심 지표 증가 방안 고려
  1. '매장 바쁨 정도' 기능 추가에 대한 NPS 증가 방안
  2. '자주 먹는 메뉴' 기능 추가와 '자주 가는 매장' 리스트 개선을 통한 재결제율 증가 방안
  3. 스마트오더 중개 플랫폼으로서의 수익 창출 방안
  4. 신규 고객 유입률 증가 방안
  1. 진행 상황에 대한 주기적인 보고가 이뤄져야 한다.
  2. 정량적 데이터 확보와 분석을 통해 신규 개발 기능, 또는 기존 기능 개선의 필요성을 제시할 수 있어야 한다.
개발자
  1. 배포 시 서버에서 발생하는 이슈, 트래픽 파악
  2. 문제 사항에 대한 솔루션 제시
  1. 발생하는 문제 상황에 대해 그때 그때 구체적으로 전달할 수 있어야 한다.
  2. 지속적인 커뮤니케이션을 통해 제품 개발에 대한 방향성과 목표를 인식할 수 있도록 한다.
  3. 어떤 형태로 해결되면 좋겠다는 형식으로 의견을 전달하고, 개발자가 그에 맞춰 로직을 짤 수 있도록 한다.
디자이너
  1. 더 나은 UX를 위한 UI 개선 방안 및 방향성 제시
  1. UX에 대한 지속적인 커뮤니케이션이 필요하다.
  2. 유저 리서치, 시장 조사 등을 통한 데이터 확보 후, 분석을 통해 UI 방향성을 수립하도록 한다.
QA
  1. 테스트케이스 작성 및 기능 테스트를 위해 신규 개발 되는 기능 및 개선된 기능에 대한 플로우 차트 작성
  1. 기능 동작 시 발생할 수 있는 에러 상황, 예외 처리 등을 모두 고려하여 플로우 차트를 작성할 수 있어야 한다.
마케터 기존 기능 개선 또는 신규 기능 개발 시 홍보를 위한 구체적인 일정 파악
  1. '매장 바쁨 정도' 기능 홍보를 위한 구체적인 일정
  2. '자주 먹는 메뉴' 기능 홍보를 위한 구체적인 일정
  3. '자주 가는 매장' 기능 개선 완료 기한 및 구체적인 일정
  1. 마케팅 팀에서 홍보 전략 수립을 원활하게 할 수 있도록 프로덕트 개발 또는 기능 개선 상황을 지속적으로 공유한다.

 

 

📌 애자일 도구, Jira 알아보기

다음은 애자일 프로세스를 통한 제품 개발 시 많이 사용하는 협업 툴인 지라 (Jira)에 대해 알아보고 정리해보겠습니다. 지라는 애자일 프로세스 진행 시 필요한 스크럼, 칸반 등의 템플릿을 제공하고 있으며, 그 중 하나를 선택해 프로젝트를 관리할 수 있습니다. 저의 경우 스크럼 템플릿을 선택해 분석을 진행했습니다.

 

💡 Scrum 템플릿 둘러보기

아래는 스크럼 템플릿을 통한 프로젝트 생성 후 나타나는 화면입니다. 크게 로드맵, 백로그, 보드 등으로 구성되어 있으며, 백로그 화면에는 기본으로 스프린트가 한 개 생성되어 있음을 알 수 있습니다.

Jira Scrum 템플릿 생성 후 화면

 

스프린트 박스 우측의 ∙∙∙ 버튼을 눌러 스프린트 편집이 가능하며, 스프린트의 이름과 날짜, 목표를 설정하거나 편집할 수 있습니다.

스프린트 편집 화면

 

이렇게 스프린트가 만들어지면 백로그를 생성해 관리할 수 있습니다.

 

생성된 백로그는 드래그를 통해 스프린트로 옮기거나, 스프린트 내에서 이슈 (해야 할 일)를 만들 수 있습니다.

 

 

백로그 추가 후 우측 '에픽 추가'를 통해 상위 태스크를 생성하고 이슈를 포함시킬 수 있습니다.

 

새로 추가된 에픽과 그에 속하는 이슈는 로드맵에서 한 눈에 확인할 수 있습니다.

 

스프린트를 시작하면 [보드]에서 진행 중인 스프린트에 대한 해야 할 이슈, 진행 중 이슈, 완료된 이슈에 대해 한 눈에 볼 수 있습니다.

 

💡애자일 원칙 수행 시 도움되는 지라 (Jira)의 기능

애자일 원칙에 도움되는 지라의 기능을 선정하기 전, 애자일의 12가지 원칙을 정리하고 가겠습니다.

애자일의 12가지 원칙

제1원칙 : 초기부터 지속해서 고객 만족
제2원칙 : 요구사항 변경 수용
제3원칙 : 짧은 배포 간격
제4원칙 : 함께 일하기
제5원칙 : 동기 부여된 팀원들로 프로덕트팀 만들기
제6원칙 : 얼굴 보고 대화하기
제7원칙 : 동작하는 프로덕트로 진도 측정
제8원칙 : 지속 가능한 개발 속도 유지
제9원칙 : 좋은 기술, 설계에 관심
제10원칙 : 단순성
제11원칙 : 자기 조직화 팀
제12원칙 : 정기적으로 효율성 제고

 

여기서 제가 느꼈던, 지라를 통해 효율적으로 수행할 수 있는 원칙은 크게 4가지로 꼽았습니다.

  1. 제4원칙 : 함께 일하기
  2. 제7원칙 : 동작하는 프로덕트로 진도 측정
  3. 제8원칙 : 지속 가능한 개발 속도 유지
  4. 제12원칙 : 정기적으로 효율성 제고

지라를 통해 협업하면서 '함께 일하기'가 가능하고, 이슈 및 버그 관리를 통해 프로덕트의 기능별 구현 상태와 개발 진행 상황을 파악함으로써 '동작하는 프로덕트로 진도 측정'을 진행하며,

로드맵과 백로그 등을 통해 설계 및 개발 현황과 진행 속도를 파악하여 '개발 속도를 유지'하고,

스프린트가 끝나는 날마다 일정에 맞춰 원활하게 개발이 이뤄지고 있는지, 보완해야 하거나 아쉬운 부분은 없는지 등을 회고를 통해 파악할 수 있도록 하여 '정기적으로 효율성 제고'를 유도할 수 있다고 생각했습니다.

 

 

📌 정리

아이데이션은 다양한 방면에서 여러 가지가 도출되었으나, 해당 아이데이션을 정말로 개선안으로 꼽을 수 있는지, 가능하다면 어떤 것이 먼저 우선순위로 개선이나 개발이 진행되어야 하는지 선별하는 과정이 꽤 어려웠습니다. 지난 주차 과제를 진행할 때 멘토님께서 ICE 프레임워크에 대해 알려주셨는데, 피드백을 고려하여 적용해보고 싶었으나 점수를 매겨 선정하는 형태였고, 혼자서 매긴 점수로는 신뢰성이 떨어질 것이라 생각해 사용하지 못한 점이 아쉽습니다.

지라의 경우 평소 협업 시 많이 사용하는 툴이라고 익히 들어왔지만 실제로 다뤄본 적은 처음이라 많이 헤맸습니다. 지라 튜토리얼 영상을 보고 어떤 식으로 활용하는지에 대해 정리도 해봤으나 아직 낯설어서 프로젝트를 하면서 다뤄보는 연습을 해야할 것 같습니다.

 

8주라는 길다면 길고, 짧다면 짧은 기간을 거쳐 패스오더를 다뤄보았는데요. 매주 과제를 해내는 것이 쉽지는 않았지만 그만큼 얻어가는 인사이트도 많았던 것 같아 뿌듯했던 것 같습니다. 

서비스 분석의 전체적인 단계를 파악하고, 정량적 데이터 확보에 대한 중요성과 아이데이션을 통해 고안한 기능들을 어떤 기준으로 선별하여 개발하고 적용해야 하는지에 대해 배울 수 있었던 시간이었습니다.

그동안의 경험을 바탕으로 앞으로 어떤 서비스를 사용할 때 꼼꼼히 분석할 줄 아는 자세를 가질 수 있게 꾸준히 노력해야겠습니다.

 

 

적극적인 피드백은 언제나 환영입니다:)

 

 

티스토리툴바