W8D1, W8D3 DAILY 과제입니다.
프로덕트 명: 카찹
유저스토리를 바탕으로 백로그를 만든다.
백로그를 '테스크'화 할 때는 유저의 이야기와 더불어 이해관계자의 이야기도 충분히 고려되어야 한다.
유저의 니즈를 실현 가능한 과제로 바꾸어야 하기 때문이다.
유저(=작성자) 요구사항 해석하기
여기서 상품 개발자의 입장은 배제하도록 하겠다. (얻을 수 있는 데이터의 한계, 화면에 보여지는 정보의 수는 일단 생각하지 않는다.)
1. 킥보드 앱에 보이는 예상시간과 대중교통 탭에서 보이는 예상시간이 다르다.
사용자는 이동 예상시간에 맞춰 출발 시간을 정하고 싶다. 만약 시간이 촉박하다면 킥보드 대신 택시를 선택할 것이고, 시간이 여유롭다면 걷기를 선택할 것이다. 그렇다고 예상시간 자체의 정확도가 매우 높아야 한다는 것은 아니다. 그보다는 내가 이동수단과 출발 시간을 결정할 수 있는 기준이 필요한 것이다.
👉 사용자는 이동수단과 출발시간을 정하기 위해 같은 이동수단에 대한 일치된 이동 예상시간이 필요하다.
2. 대중교통 탭은 가격이 안 나온다.
대중교통과 킥보드를 같이 이용하려고 할 때 고민되는 부분 중 하나가 비용이다. 비용을 보고 걸어갈 만한 거리면 걸어가고, 아니면 처음부터 택시를 탈지도 고려해볼 수 있다. "기본" 버스 비용에 "추가로" 비용이 든다고 느껴지기 때문이다. 정말 원하는 것은 비용이 표시되는 것이 다일까? 그것보다는 이동수단 간에 비용을 비교해보고 싶은 것이 더 근본적인 이유라고 볼 수 있다. 필요한 것은 단순히 가격표시 보다는 비교하기 쉬운 정보 표시가 아닐까...
👉 사용자는 이동수단 간 비용 비교를 위해 모든 수단에 대한 가격표시가 필요하다.
3. 다른 경로안내 서비스처럼 버스가 몇 분 뒤에 오는지도 알고 싶다.
"네이버 길찾기에는 있는데 여기는 왜 없지?" (사실 이런 기대?에 대해 어떻게 대응하면 좋을지 모르겠다.)
출발지와 도착지를 입력해 경로를 받는 것은 다른 지도앱의 길찾기 기능과 같다. 그렇다면, 버스 도착시간도 있어야 할 것만 같다. 당연하게 여겨지는 정보 같은 것... 버스 도착시간이 없으면 다시 지도앱을 켜서 찾아봐야 하는 번거로움도 있다.
👉 사용자는 익숙한 사용 경험을 얻고 싶다.
4. 킥보드도 이 앱에서 바로 결제가 되면 좋겠다.
"킥보드 앱으로 이동하면 다시 킥보드 고르기부터 해야하는데 귀찮다."
정확히 어느 지점이 귀찮은가... 가격비교에서 킥보드 예매하기로 넘어갈 때는 특정 킥보드를 정한 상태가 아니기 때문에 킥보드를 다시 고르는 귀찮음이 없다. 여기서 사용자는 킥보드 브랜드와 가격을 기준으로 선택하기 때문이다.
그러나 주변 모빌리티 찾기에서 충전상태, 브랜드, 가격을 보고 결정한 사용자가 앱으로 이동했을 때 다시 '내가 선택한 킥보드'를 찾는 일은 귀찮다. 다시 선택의 상황을 마주해야 하는 피로감, 예약 과정이 번복되는 듯한 느낌을 받는다.
👉 사용자는 예약과정의 피로감을 줄이기 위해 예약 단계의 최소화를 원한다.
각 유저스토리에 대한 백로그를 작성하면 다음과 같다.
'사용자가 발견한 문제'에서 유저스토리와 백로그를 뽑아 앱 사용 경험자로 'WHO'를 한정시켰다.
(과제 요구사항이기도 하지만, 이렇게 하는게 유저스토리, 백로그 작성, 이해관계자 요구사항에 대해 집중하기 좋을 것 같아서!)
1) 문제
킥보드 탭의 시간, 거리와 대중교통 탭의 시간, 거리 값이 불일치함.
동일한 출발지-목적지, 이동수단에 대해 거리를 다르게 측정하고 소요시간도 다르게 예측한다.
문제가 되는 이유는 정보의 불일치로 사용자가 이동시간 예측, 이동수단 선택 목적 달성에 어려움 겪음.
2) 해결방안
ⅰ) 경로 정보를 일치시킴. (킥보드에서 불러오는 정보 VS. 대중교통에서 불러오는 정보 중 하나만 선택하여 표시)
ⅱ) 처음에 일치하지 않게 둔 이유가 있다면
- 두 탭의 값이 일치하도록 계산식/DB 수정
- 시간/거리 불일치에 대한 설명 제공
3) 기대효과
(사용자 입장에서 서비스 신뢰도 향상)
- 서비스 활성화 정도 증가
1) 문제
대중교통과 퍼스널 모빌리티의 조합에 대한 가격 표시 필요.
이동수단 가격비교를 위해 비교 대상이 되는 이동수단에 대해서는 가격 표시가 필요함.
버스/지하철이 이동수단 비교 기준으로 역할을 한다고 본다.
2) 해결방안
이동수단 조합에 대한 가격표시.
(버스 요금은 일정하고 퍼스널 모빌리티 비용은 거리로 계산 가능하므로 표시할 수 있음)
ⅰ) 외부 DB에서 불러온 값을 합하여 클라이언트로 전달, 화면에 표시 (API 수정)
ⅱ) (이런 경우는 없겠지만) 가격의 합을 서버에서 클라이언트로 전달할 수 없는 구조인 경우, 각 이동수단에 대한 가격을 표시??
3) 기대효과
(가격 비교 기능 목적 강화)
- 광고 노출수 증가
- 이동 패턴 데이터 확보
가설이긴 한데... 완전한 가격비교가 가능하니까 특정 가격대/거리 선호 이동수단 선택 패턴이 형성되지 않을까...
패턴을 파악한다면, 이동수단을 추천하거나 상위노출로 비즈니스 모델을 세워볼 수 있지 않을까...
1) 문제
출발지/목적지를 설정하고 경로 결과를 받는 과정에서라면 사용자는 길찾기 기능을 습관적으로 떠올릴 수 있다.
사용자는 길찾기 기능에 포함되는 버스/지하철 도착시간이 표시되지 않을 때 "왜 이게 없지?" 라고 의문을 가질 수 있다.
그런데, 사실 "가격비교" 기능을 제공이 목적이라고 하면 필요한 기능은 아니다. 오히려 목적에서 벗어났다고도 볼 수 있다. 도착시간 표시를 시작하면 다른 "경로"관련 정보도 요구될 수 있다고 생각한다.
백로그에 넣어야 할까?
백로그에 넣을지는 앱 사용자 인터뷰가 따로 필요할 것 같다.
서비스에 대해서 사용자가 어떻게 인식을 하고 있는지,
카찹에서 길찾기 기능까지 기대하고 있는지 알아보아야 한다.
해결해야 하는 VOC인지 판단 후, 문제가 맞다면 백로그로 정의하고 해결방안을 도출해야 함.
1) 문제
사용자 입장에서는 '중복되는 작업'으로 인식된다.
카찹 앱에서 이미 특정 킥보드를 선택하고 "앱에서 대여하기" 버튼을 눌렀는데
case1) 이동한 앱에서 '내가 선택한 킥보드'가 선택되어있지 않은 경우 발생할 수 있음
case2) 사용자가 앱을 설치하지 않은 경우 앱 설치, 등록 과정을 거쳐야 함
2) 해결방안
카찹 앱 내에서 바로 결제할 수 있도록 한다.
티맵의 경우, 결제 시스템을 갖추고 있어 참고자료로 활용할 수 있다.
대공사라는 것을 인지하고 있다.
말로만 하면 매우 심플한 해결방안인데, 고려할 이해관계자가 많다.
만약 직접 결제 기능이 여의치 않은 경우 생각해볼 수 있는 해결방안은 무엇이 있을까?
▶킥보드 결제창 바로 띄우기
앱 설치와 회원가입 절차는 킥보드 서비스를 이용하기 위한 최소한의 절차이기 때문에 줄일 수 없지만
킥보드를 다시 지도에서 찾는 수고는 줄일 수 있다.
킥보드 대여시 QR 코드외에 킥보드 기기코드를 직접 입력하여 대여하는 경로를 이용할 수 있다.
생각해본 구체적인 방법으로는 결제창을 바로 띄우고 앱에서 저장된 킥보드 기기코드를 바로 입력되게 하는 것이다.
더 간편하고, 지속가능한 방법이 있을 것 같아서...의논해보면 좋을 것 같다!
앱 접근권한이 추가되고, 각 브랜드마다 협의할 사항이 발생할 것으로 보인다.
(그리고 카찹이 하지 않은 데는 이유가 있지 않을까... )
3) 기대효과
킥보드 브랜드 내 대여 전환율 증가
카찹 대여 전환율 증가
이해관계자의 요구도 백로그의 중요성을 결정하는 데 영향을 미친다.
각 백로그에 대해 포함될 수 있는 이해관계자를 생각해보자.
** 투자자는 산업 성장성/주도성/수익성을, CEO는 (투자자)+(미션/비전 달성)의 관점을 가진다고 구분하여 생각했다.
투자자의 관점
https://platum.kr/archives/182926
이해관계자 | 요구사항 |
고객 | 동일 이동수단에 대한 일치된 이동 예상시간 표시 |
팀원 | 기존 계산방식에 대한 수정 시간 소요 |
서비스에서 발생한 오류를 잡기 위한 과정에 가깝다고 생각하여 고객과 팀원만 이해관계자에 포함하였다.
문제 해결에 큰 기술적 노력이 들지는 않을 것으로 보이나, 고객의 불편이 크지 않다면(대여 전환을 저해하는 요인) 후순위로 미뤄둘 수 있지 않을까..
이해관계자 | 요구사항 |
고객 | 대중교통탭만 이동수단 가격표시가 되지 않음 |
팀원 | 외부 서버에 요청사항 추가 및 클라이언트 UI 계획 필요 |
CEO | 가격비교 서비스로서 완성도 |
앞의 문제와 비슷하지만, 주력 서비스에 포함되는 기능이기 때문에 CEO도 이해관계자로 포함해보았다.
이 문제와 매출/시장 경쟁력의 상관관계가 크지는 않다고 판단했기 때문에 투자자는 포함하지 않았다.
이해관계자 | 요구사항 |
고객 | 예약 단계에서 발생하는 번거로움 해소 요구 |
팀원 | 결제모듈 추가시 개발/디자인 업무부담 증가 직접 결제 외 해결책은 이후 번복될 가능성이 있지 않을까 |
CEO | 결제모듈 추가시 협력업체와 협의 필요 결제 모듈 관련 비용 |
투자자 | 타 서비스 대비 경쟁력 확보 플랫폼 서비스로서 수익원 논의 필요성 제기 |
카찹에서 바로 결제가 가능하게 되는 경우, 각 브랜드와 협의가 필요하다.
투자자의 입장에서는 유사한 기능을 제공하는 서비스가 이미 도입한 결제 기능을 따라 도입하는 것이 긍정적일 수도 있겠다. 이전 인터뷰에서 카찹 대표는 수수료 외에 먹거리를 찾겠다고 하였다. 가격비교 플랫폼으로 자리를 잡기로 정해졌다면, 이에 맞게 수익원에 대한 구체적인 계획도 제시하여 투자자를 설득해야 할 것으로 보인다.
데이터를 팔겠다는 것? 보험과 연계를 하겠다는 것? 궁금하닷...
참고자료
https://brunch.co.kr/@mojuns/36
https://www.venturesquare.net/773687
[코드스테이츠 PMB 11기] Jira 둘러보기 (0) | 2022.05.08 |
---|---|
[코드스테이츠 PMB 11기] 스크럼 이해하기 (0) | 2022.05.03 |
[코드스테이츠 PMB 11기] 프로덕트 구조 다시보기 (0) | 2022.04.28 |
[코드스테이츠 PMB 11기] 오픈 API 기능과 구조 살펴보기 (0) | 2022.04.27 |
[코드스테이츠 PMB 11기] 앱의 4가지 형태 (0) | 2022.04.26 |
댓글 영역