Portfolio

1. 오늘 해야할 일 확인

자전거 함께타요 VS 전문 라이딩 팀원 모집✅

매칭 관리자 권한(지원 프로세스 결정) 즉시예약

알림(메일 vs 폰) ⇒ should

2. `자전거 함께타요` VS `전문 라이딩 팀원 모집`

💡

우리가 생각하는 우리 서비스 제1의 고객은 누구인가요? 추상적 자전거를 같이 타고 싶은 20~30대 구체적1 : 간단한 운동과 친목을 위해 자전거 모임을 하고 싶은 20대 구체적2 : 같은 종류의 자전거로 전문 취미 생활을 나누고 싶은 20-30대

사진

제1의 타겟은 누구? 우리의 페르소나는 무엇?

자전거의 취미를 강하게 가진 직장인, 로드 자전거의 매력에 심취해서 같이 매력을 전파할 정도로 빠져있는 사람

도싸를 사용해 볼 정도로 자전거에 흥미를 가지고 있지만, 도싸의 기능이 불편하다고 느끼는 20~30대

20 ~ 40대의 자전거를 좋아하는 직장인

메이커가 제1의 타겟

조건

어떤 매체?

도싸

2.1 자전거 함께 타요

따릉이 동네 운동용/친목용

자전거는 만남을 위한 수단

사람 만남의 방점

신뢰성이 더 중요

단거리 위주 만남

2.2 전문 라이딩 팀원 모집

중장거리 전문취미용 ( opt 식사)

자전거 자체가 목적

성별남녀 정보 불필요 & 자전거 실력 및 기종 중요

중장거리 코스 위주

전문성

추가 아이디어 도입

안건 별 논의

승인제 vs 자동 신청 ✅

주변 운동을 좋아하는 지인들에게도 물어봤고,
호스트가 사람이 모여야 시작할 수 있는 입장이라는 것을 감안했을 때
자동 신청이 맞다고 느낌

Tree

근본적으로 두 방향성 구별에 가깝다고 봄
가볍게 같이 타기 vs 전문 라이딩 팀
만남의 수단 vs 만남의 목적
사람의 중요성: 중요하기에 필터링 필요 vs 자전거만 좋아한다면 OK
가벼운 만남(전자)을 타겟으로 삼자

산책 메이트

너무 자전거 도메인을 살리려 해서 타겟이 자전거 beginner → expert로 바뀌었다.
20~30대 only beginner? ⇒ no

20~30대 자전거 ‘매니아’가 적을까? No

후자의 경우 개발할 수 있는 기능들이 많다.

강점 포인트: 쉽고 빠르게

UI적으로 쉽고 빠르게 모임을 만들 수 있게 해야 한다.(select box 등 UI 컴포넌트 적극 활용)

우리가 생각해야 하는 제 1의 타겟 : 모임을 만드는 사람(메이커)

메이커가 많을 수록 신청자들은 알아서 붙을 가능성 높음

전자의 경우 애플리케이션의 기능을 심화시킬 여지가 크게 없음.
타겟을 구체적으로

자전거를 좋아하는 20~30대도 포괄적

당근마켓에서 간단한 자전거 모임을 하는 사람
실제 자전거 부품을 사고 팔고 하는 매니아(?)

이들의 행위를 분석해야 한다.

우리 서비스의 페르소나를 정하자.
매니아 ✅

취미에서 한 발자국 더 나와 있는 사람
주말에 혼자 타기도 하지만
같이 즐길 사람을 찾고 싶음(가까운 지인 중에는 자전거 매니아가 없다.)

자전거가 메인이 아닌 사람

공시생
운동용
이야기 나누기
모임 중심

Kant

타겟 20~30대 논의
카페 서비스 대체 이유

낙후돼있다.
중장년층은 쉽게 못 옮길 것 같다.

웹서비스

기존의 레거시와 구분돼야함
신청 → 바로 받기가 맏는 것 같다.

가볍게 만나는 사람들 위주로 갔으면 좋겠다.
전문가 중심으로 할 경우는 카페와 큰 차이가 없을 것 같다.
초보자, 여성, 20~30대 ⇒ 클릭으로 바로 진행
후자로 진행됐을 때 우려 사항

카페와 차별화 할수 있는 것이 없는가?

기획이 추가적으로 필요하다.

Matt

자전거 종류를 고려하기 시작한 순간부터 expert 방향성을 가졌다고 본다.

Didi

전자는 번개 모임 느낌
우리가 다루는 것은 mobile app이 아니기 때문에 어울리지 않는 것 같다.

웹이기 때문에 비동기적 애플리케이션

Pray

전문가 중심

커뮤니티에 글을 올릴 만큼 열성적인 사람

기존 UI가 너무 지저분하고 진입 장벽이 높아서 기존 커뮤니티를 사용하지 못하던 매니아

승인 절차가 필요할 수도 있다.

우리는 매니아 사이트니까
Tree : 필터링 시스템은 당연히 있어야 하나, 그것이 승인 절차 필요는 없다. 투머치?

KIKO

전문가 중심
자전거 도메인이 깊게 가는 거지만 가볍게 갈 경우 번개 앱과 차별점을 두기 힘들 것 같다.
승인제는 너무 빡세다. 특히 애플리케이션에 처음 접하는 사람들에게는
도싸

댓글 : 참여합니다 ⇒ 바로 승인

Github / Zenhub 컨벤션

에픽 - 이슈 단위임!

Jira의 에픽 - 스토리 단위에 대응
Jira의 Task는 없다고 생각하자
이슈당 PR

결정사항

자전거 함께타요 VS ✅ 전문 라이딩 팀원 모집

제1의 타겟은 누구? 우리의 페르소나는 무엇?

✅ 메이커가 제1의 타겟
✅ 자전거의 취미를 강하게 가진 직장인, 로드 자전거의 매력에 심취해서 같이 매력을 전파할 정도로 빠져있는 사람
✅ 도싸를 사용해 볼 정도로 자전거에 흥미를 가지고 있지만, 도싸의 기능이 불편하다고 느끼는 20~30대

✅ 매칭 신청 시 메이커 승인 없이 자동 신청되도록

✅ 자전거 사진 필수 등록 여부 ⇒ [”should”]

✅ 알림(메일 vs 폰) ⇒ [”should”]

✅ 다음 단계 진행 방향은

공통은 도메인 지식 공부하기
프론트는 와이어프레임 만들기
백엔드는 erd, api 초기 설계하기

와이어프레임 역할 분담

Tree

와이어프레임 제작 과정= 도메인 학습

하지만 8명이 한 화면을 쳐다보고 진행하기에는 매우 비효율적이다.

기획 확정 회의