코드스테이츠| PMB 11/Daily 과제

나도 이 순간 만큼은 <배달의 민족> PM과 같은 고민을 하고있다 이거지_코드스테이츠 PMB 11기| W8D1

Sutella 2022. 5. 2. 23:03
728x90

 또 한 주가 밝았다. 이번 주는 드디어 마지막 학습 주간이다. 그리고 다시 시작된 데일리 과제의 날이기도 하다😵 벌써 8주 차라니... 시간이 정말 빠르게 느껴진다. 데일리 과제도 벌써 29일 차에 접어들었다. 게시글로 따지면 28번 째이며, 프로덕트는 연결되는 과제도, 중복되는 프로덕트도 있었기에 22개 째이다. 

 나는 이제까지 뒷심이 부족해서, 시작은 화려했지만 끝은 흐지부지로 맺은 경우가 대다수였다. 하지만 이번 PMB는 그나마? 초심을 지금까지 이어오고 있는 것 같다. 꾸준히 블로그도 써오고 있고, 이제까지 지각도 한 번 없이 과제를 제출한 것에 의의를 둔다면! 스스로 대견하다는 합리화를 조금 해본다:) (꾸준히 열심히 해왔다기보다 '질질 끌고 온' 느낌이 다분하지만, 어쨌든^^ 좋은 게 좋은 거니까!)

 물론 아직 PMB의 끝은 아니지만, 학습 주간의 끝에 다다른 만큼 조금만 더 버텨보자🙂 오늘의 과제 시작-!

 

선정 product: 배달의 민족

오늘의 과제는 원래 "카카오톡 멀티 프로필"을 product로 제시해 주셨지만, 다른 프로덕트도 가능하다는 말이 있어 나는 [배달의 민족]을 골랐다. 폭발적으로 성장한 스타트업이자, 국내에 배달 문화를 조성하고 있는 영향력있는 서비스이기도 하지만, 어제저녁으로 시켜먹었던 치킨이 문득 생각나서 선정한 이유가 크다. (과제 선정마저 돼지런🐷)

 배달의 민족은 기존에 존재하던 배달 '문화'를 배달 '시장'으로 스케일업 시키는 데 큰 몫을 한 서비스이다. 오래전부터 '배달'은 존재했지만 이렇게 본격적으로 시장이 커지고, 특히 펜데믹 시기를 만나면서 배달 시장은 폭발적으로 성장했다. 이 중심에는 "배달의 민족"이 있고, 그들로 인해 파생되는 배달 대행 및 배달 문화(에티켓) 등의 요소들은 또 다른 문화와 시장을 생성하는 데까지 이어지고 있다.

 이러한 명성과 영향력을 바탕으로 오늘의 과제는 [배달의 민족]의 PP(Pain point)를 선택해 유저 스토리와 백로그를 작성해 보고자 한다. 

과제 시작 전, 가정과 한계

 객관적으로 PP를 파악하기 위해서는 고객 인터뷰나 설문조사, 혹은 데이터 분석 등이 근거가 되어야 한다. 특히 배달의 민족은 MAU 2072만 8261명(2022년 1월)이라는 압도적인 이용자를 보유하고 있어, 소수의 고객 보다는 다수의 PP를 해결할 수 있는 요소를 찾아야 한다. 

 하지만 본 과제에서는 임의적으로 PP를 선정하고, 이에 대한 유저스토리와유저 스토리와 백로그를 작성하는 것을 중점으로 하고자 한다. 위클리 과제라면 모를까, 데일리 과제 특성상 '하루' 안에 수행해야 하기에:) 객관적인 PP를 찾는 과정은 조금 무리가 있다. (시간적으로도 그렇고, 직접적인 데이터에 접근할 수도 없다.) 따라서 JUST 나의 아이디어로 PP를 선정하고 유저 스토리와 백로그를 작성할 것임을 서두에 밝힌다.

 

Pain Point 찾기

 나는 현재 지방에서 배민을 이용하고 있기에 B마트 서비스는 예외이지만, 그 외에 집에서 밥해먹기 귀찮을 때, 혹은 먹고 싶은게 생각나면 가장 먼저 켜보는 앱이 "배달의 민족(이하 배민)"이다. 물론 목적성 뚜렷하게 배민을 이용할 때도 있지만, 나는 배민을 통해 아이쇼핑을 하기도 한다. 주로 식욕의 노예가 돼서 신나게 음식들을 장바구니에 담지만, (1) 주문 최소 금액과 (2) 배달비와 같은 주요 문제에 부딪혀서 고민하는 과정이 길어지기 때문이다. 고민 시간이 길어지면 그냥.. 지쳐서 배민을 이용하지 않게 된다.

 하지만 주변의 친구들에게 물어봤을 때는 대부분 목적성 뚜렷한 이용이 공통적으로 나타났다. '어떤 걸 배달시켜 먹을까?'보다는 "(aa 브랜드 메뉴인) ABC치킨이 먹고 싶다", "ㄱㄴ카페에서 아메리카노와 크로플을 시켜야겠다"는 경우가 많았다는 것이다. 이미 메뉴 선정과 가게(브랜드)는 어플 밖에서 이뤄지고, 실질적인 주문만이 배민에서 이루어지는 것이 일반적이었으며, 카페의 경우 메뉴 선정 정도가 배민에서 고민된다고 한다.

(1) 메인 홈 / (2) 메인홈 - [배달] 페이지 / (3) [검색] 페이지

 우선 어떤 가게의 특정 메뉴를 주문하는 경우를 가정해보자. 유저가 실질적인 주문을 하기 위한 경로는 크게 3가지로 나눌 수 있다.

  1. (접속하자마자 만나는) [메인 홈]의 최상단에 있는검색창을 통해 검색한다. (메뉴 이름으로 검색해도 가게가 노출됨)
  2. [메인 홈 - 배달]을 통해 이동한 [배달] 페이지 하단의 내비게이션 <검색> 탭을 이용하여 검색창으로 진입해 검색한다.
  3. [메인 홈 - 배달 - (카테고리)]로 진입하여 해당 가게를 찾는다.

 유저의 목적은 '특정 메뉴 주문'이지만 여러가지 경로로 나뉘며, 같은 검색창 진입이라도 추가 단계가 생성되기도 한다. 한편으로는 다양한 페이지에서 손쉽게 '검색'을 접할 수 있는 장점이기도 하지만, 검색 결과에서 원하는 바를 한 번에 얻기는 어렵다.

 유저의 본래 목적은 '어떤 가게'보다 "특정 메뉴"에 치중되어 있다. 물론, 대/중분류 레벨의 메뉴라면 가게 이름 노출이 적절해 보일 수 있지만, 가정에서 설정한 것은 '특정 메뉴'이기 때문에 유저는 해당 메뉴를 주문하기 위해서 추가 행동을 실행해야 한다. (1) 해당 가게에 들어가서 스크롤 등을 통해 (2) 메뉴를 찾고 메뉴를 터치해 (3) 메뉴 페이지로 넘어가 (3-1) 필요할 경우 옵션을 추가하며 (4) 장바구니에 담는 과정이 필요하다. (이후 주소 확인과 결제 단계는 여기서 다루는 PP와 관련성이 떨어져 제외하고 논하겠다.)

✅ Pain Point 정리: 유저가 어떤 가게의특정 메뉴를 원할 때, 이를 주문하기 위한 여정이 너무 길다.

 

User Story (유저 스토리)

 앞서 도출한 PP를 바탕으로 유저 스토리를 작성해 보자. 우선 유저 스토리는 3가지 형식을 갖춘다.

  • Who(user): 어떤 유저는
  • What(Action): 무엇을 위해서 
  • Why(Purpose): 어떤 것을 원한다.

 이를 바탕으로 유저 스토리를 작성해 보려면, 보다 명확한 고객(유저) 니즈를 설정해야 할 필요가 있다. 유저가 특정 메뉴를 주문하기 위한 여정이 길다는 말을 보다 쉽게 바꾸면, 더 빠르게 주문하기를 원한다고 다시 표현해 볼 수 있다. 유저가 검색을 통해 메뉴에 도달한다고 가정했을 때, 현재의 여정은 [메인 홈 - 검색창 - 검색 - 가게 유입 - 메뉴 찾기 (- 옵션 선택) - 장바구니 - 주문하기]의 경로를 따른다. 이 과정을 어떻게 줄일 수 있을까?

 만약 검색으로 유저가 접근한다면, 특정 검색어를 입력할 것이다. 물론 요식업 특성상 메뉴 이름이 상호 이름이 되기도 한다. 하지만 결국 유저가 원하는 것은 가게가 아닌 "특정 메뉴"라는 점을 유념하자. 굳이 검색 결과에 가게 이름을 먼저 노출할 필요가 있을까? 메뉴를 바로 노출할 순 없을까? 이 의문을 중심으로 PP를 좁히고, 이에 대한 유저 스토리를 작성해 보자면 다음과 같다.

  • 특정 메뉴를 주문하고 싶은 유저는 (Who)
  • 원하는 메뉴를 빠르게 주문하기 위해서 (What)
  • 바로 메뉴 페이지로 이동하길 원한다. (Why)

 

Back log (백로그) 

 정의한 유저 스토리에 이어, 이와 관련된 백로그를 작성해 보자. 다만 이에 앞서, 어떤 기능을 개발할 수 있을지 다양한 가능성에 대해 리스트업 하는 작업을 먼저 시행하려 한다. 

List up: 유저가 바로 메뉴 페이지로 이동할 수 있는 방법
  • 메인 홈에서 최근 주문한 메뉴 노출
    • 현재 최근에 주문한 가게 히스토리가 노출되고 있다. 하지만 최근에 주문하지 않은 메뉴일 경우 해당 기능이 니즈를 충족해 주지 못한다.
    • 가게가 아닌 '메뉴'를 노출하더라도, 앞서 언급한 '최근 주문' 조건을 충족하지 못할 경우 유용하지 못하다.
    • 변형으로, 자주 주문한 메뉴를 노출할 수 있다.
  • [메인 홈 - 찜] 리스트에서 확인
    • 이 역시 기존에 찜하지 않은 가게의 메뉴일 경우 유용하지 않다. '메뉴'가 아닌 '가게'를 찜하는 것이기에, 결국 부가적인 절차가 필요하다.
    • 변화를 준다면 '메뉴' 찜하기 기능을 추가할 수 있다.
  • 검색 결과에서 바로 메뉴 노출
    • 검색어 입력 시 해당 메뉴를 판매하고 있는 가게가 검색 결과로 노출된다. 하지만 해당 가게에 들어가 다시 탐색을 해야 하는 번거로운 과정이 존재한다.
    • 신규 기능을 추가한다면 검색 결과에 메뉴를 노출하는 방법이 있다. 

 크게 3가지 가능성을 생각해 본 결과, 나는 "검색 결과"에서 답을 찾았고 이와 관련된 백로그를 작성해 보고자 한다. 경로로 따지면 [검색-가게유입-메뉴찾기]가 될 것이며, 이를 단축시키는 효과를 예상해 본다. 이를 이름 붙이자면 <검색 결과 - 메뉴 노출> 기능이 될 것이며, 글의 편의를 위해 <메뉴 검색 노출>이라 명명하고 서술하겠다. 

 

백로그: 메뉴 검색 노출

* 오름차순으로 정렬 (상단에 정렬된 로그의 우선순위가 더 높음)

  1. "메뉴 검색 노출" 기능 추가
    • 메뉴를 노출할 때 어떤 정보를 노출할지 (ex. 메뉴 이미지, 가격, 사장님 설명, 관련 리뷰, 메뉴 추천 빈도 등)
    • 검색어와 메뉴의 '적합성' 판단 기준 결정 (기능의 효과 및 작동성 파악을 위해) 
    • 가게들 간 중복되는 메뉴명이 있을 때의 메뉴 노출 기준 (ex. 주문 빈도라면 해당 유저인지, 전체 고객인지)
    • 검색어(메뉴/가게 등) 인지 알고리즘 개선 (검색어에 따라 메뉴 노출 유무 결정을 위해)
    • 사용자의 기존 주문 이력과의 연관성 파악 기준 논의 (반영 유무 및 정도)
  2. [메인 홈] "최근 주문한 메뉴" 구성 (현재의 '최근 주문한 가게'를 벤치마킹하여 설계할 때)
    • 유저의 주문 히스토리 중 n개의 주문 메뉴 노출 (ex. 각 주문건 별 대표 메뉴 1개)
    • 주문 메뉴가 여러개 일 경우 어떻게 표현할지 결정 (ex. 가격 정렬, 해당 가게의 메뉴 순서 등)
      • 결정 사항 코드 반영
    • 메뉴의 사진이 없을 경우 어떤 이미지를 노출할 것인지 결정/반영
  3. [메인 홈] "자주 주문하는 메뉴" 구성 (현재의 '최근 주문한 가게'를 벤치마킹하여 설계할 때)
    • 해당 섹션의 정렬 기준 결정 (ex. 주문 빈도, n회 이상 주문 시 노출 등)
    • 노출 메뉴 갯수 결정
    • 노출 메뉴의 단품 유무 결정
      (ex. 특정 메뉴만 노출, 기존의 주문 이력을 바탕으로 한 가게에서 주문하는 조합을 묶어서 노출할 것인지)
    • 사용자 편집 기능 추가 유무 논의
  4. "메뉴 찜하기" 기능 추가
    • 메뉴 페이지 내 찜하기 CTA 추가
    • Admin(배민 사장님) 프로덕트
      • [메뉴 찜하기] 데이터 연결 (수치 확인)
      • 대시보드 편집 기능 반영

 

 앞서 유저 스토리에서 리스트업 했던 기능들을 위주로 백로그를 작성해 보았다. 당연히 사전 논의를 통해 해당 기능들의 실현 가능성, 유효성 등에 대해 평가한 후 일부에 대해서만 실행에 옮겨질 것이다. 예를 들어 "최근 주문한 메뉴"나 "자주 주문한 메뉴"의 경우 비슷한 성격을 띠고 있어 두 가지가 동시에 실행될 가능성은 낮다고 생각한다.

 또한, 현재 배민이 집중하고자 하는 것은 기존의 '배달'이 아닌 "배민쇼핑라이브"이기 때문에, 메인 홈에 추가적인 콘텐츠를 삽입하는 것을 꺼릴 가능성도 있다. 내부 데이터를 보면 메뉴에 직접 도달하고자 희망하는 유저들의 니즈가 그리 강력하지 않을 수도 있기에, 위의 백로그가 무의미할 수도 있다.

 하지만 서두에 밝힌 대로 다양한 가능성을 배제하고 주관적으로 백로그를 작성해 보았다. 백로그 역시 나름 생각할 수 있는 범위 내에서는 최대한 촘촘하고 디테일하게 작성하고자 노력했으나, 당연히 부족하거나 누락된 부분이 있을 것이다. (페어님 부탁해요!)

출처: 코드스테이츠 PMB 11기 스터디클럽 내 토론 칸반 (재편집)

 

 만약 현장에서 위의 백로그들이 실행에 착수한다면 아마 '칸반'을 이용해 이슈 관리를 할 것이라 예상된다.  아마 일반 유저들에게 칸반은, 노션(Notion)의 '데이터 베이스 보기' 기능이나 화이트 보드의 포스트잇을 붙이는 방식으로 접해보았기에 익숙할 것이다. 

칸반 보드 (출처: Jet Brains/ 브런치 '이지섭')

 현장에서는 JIRA나 Confluence와 같은 툴을 이용하며, 사내 자체 이슈 관리 SW가 존재할 수도 있다. 위의 예시처럼 다양한 기준의 열(Column)이 존재하며, 열 내부 칸반 카드에는 이슈와 처리 담당자가 배정되는 것이 일반적이다.

+ TMI
(내 기억이 맞다면) JIRA, Confluence는 개발자와의 협업 및 이슈 관리 시에 유용한 툴이며, 범용적으로 사용되는 이슈 관리 SW이다. 두 SW 모두 Atlassian 사의 제품이다. 

이게 맞나 싶은 오늘의 과제

 오늘도 여차저차, 어떻게 과제를 마무리했다. 사실 마무리라기보다는... 그냥 내 맘대로 끝냈다는 표현이 맞는 것 같다. 학습 내용에서 배운 '백로그'의 예시와, 과제에서 수행해야 하는 '백로그'가 달라서 아직도 약간의 혼란이 있다. 과제를 마무리한 후 추가적인 탐색이 필요하겠지만, 일단은 내 기준대로? 맘대로 써내려 보았다. 진짜 이게 맞나?

 오늘의 과제도... 수행한 것과 제 시간 내에 끝낸 것에 의의를 두고 (양심 아야!) 여차저차 마무리^^ 오늘의 과제가 수요일의 과제와도 이어진다고 하니 또 미래의 너굴맨에게 과제를 떠넘긴다! 오늘 과제 끝!

😊 페어님 미안해요! (그래도 해맑으면 욕은 안해주시겠지....?)

fin.

728x90
저작자표시