[사이드프로젝트][사이드176] 상위 기획 피드백 2차 + 개발단과 ERD 논의하기 + 지표 검증을 위한 가설 수립

상위 기획 피드백 2차(디자이너와 개발자와 소통하기)

- 피드백에서 의견이 갈린 내용 : 내 위치+위치별 스팟 리스팅 VS 위치별 스팟 개수 표시+전체 스팟 리스팅

기획파트) 프로덕트 기획의도가 '효율적 시간 활용' => 내 위치를 기준으로 효율적인 서칭 실현

디자인 파트) 미시적인 공간을 선정하여 서비스를 제공하므로 전체의 선택지를 유저에게 공유하여 풍부한 데이터 제공

위치별 스팟 개수 예시 (출처 : 직방)

기획파트는 내 위치 버튼을 없애고 전체 공간을 리스팅 대신 지도에 뿌리기로 결정함.
다만 위치별 스팟 개수 표출은 구현을 하지 않기로 함

- 이유 1. 디자인 파트 의견처럼 전체의 선택지를 보여주는 것이 합리적이라 판단함 => 풍부한 데이터 제공 실현
- 이유 2. 내 위치 버튼을 선택할 회수마다 api를 호출하게 되는데 효율성이 떨어짐.
               또한 이미 유저가 있는 위치를 1:1000 배율로 미시적이게 화면 표출 + 마커 색 표기를 하기로 결정한 상태
               지도 페이지에 접속할 경우 전체 스팟을 보여주는 api를 추가 호출 필요 없음
               ㄴ 위치별 스팟 리스팅은 동적으로 필연적으로 더 많은 이슈가 발생되어 지속적인 유지보수가 요구됨
                    (부하, 데이터 사용량 증가, 응답시간 지연)

- 이유3. 위치별 스팟 개수 표시는 필수 기능이 아니며, 래퍼런스 프로덕트와 공급 스팟양의 차이로 인함

• 초기 프로덕트의 사명 = 가장 필수적인 기능만 조합하여 배포 후 고도화 한다. => 위치별 스팟 개수 표시는 필수 기능이 아님
• 위치별 스팟 개수 표시의 대표 사례는 부동산 어플로 부동산은 우리의 프로덕트보다 거시적 관점에서 서비스를 제공하고 있으므로 필연적으로 ui의 깔끔함을 유지하기 위해 해당 기능이 필요함. 하지만, 우리의 프로덕트의 스팟 개수는 초최대 60개 정도로 집계됨  => 스팟 수가 상이하게 차이남 

실제 줌인을 하면 보여지는 ui (출처 : 직방)

 

=>  파트별(입장)에 따라 의견 차이가 발생하기도 한다. 이 때, 얼마나 합리적으로 상대를 설득하고 가장 효율적인 결과를 도출할 수 있는지를 초점에 맞춰 의견을 재정비해야 한다. 또한 수정 요청 피드백을 100% 수용하기 보단 기획자의 의도를 중심으로 하여 수정 방향을 정의해 가야 한다. 

 

 

개발단과 ERD 논의하기

- 구성해야하는 최소 테이블, 최소 데이터 구분하기

- 최소한의 테이블 조인으로(복잡성을 최소화) 기능을 사용하는 것이 좋음

- 개발자 도구를 활용하여 벤치마킹 사례 확인하여 작성해보기 

개발자 도구로 테이블과 파라미터를 확인하는 모습

 

=>

Q. erd를 기획자가 논의해야 하는 이유?

A. 기획자가 기획한 항목이 아래와 같은 개발단의 어려움을 야기할 수 있다.

1. 특정 기능을 고도화 해야 할 때, 테이블 고려가 안되어 있다면, 앱 서비스 운영에 과부하를 줄 수 있음

2. 테이블이 다른 상태에서 key를 조합하여 기능을 실행시켜야 할 경우가 있는데 이 때, 복잡성이 발생할 수 있음

3. erd에 그려진 테이블과 KEY를 바탕으로 봐야하는 지표 항목이 명확해질 수 있다. 

 

따라서, erd 구성을 함께 고려하는 것이 좋다.

 

 

 지표 검증을 위한 가설 수립

- ERD 작성과 기획 의도를 기반으로 어떤 지표를 보면 좋을지 논의해야 함

- 지표 검증의 이유의 핵심은, 유저 파악 즉 '리텐션' 파악
- 목적 ~ 가설 ~ 측정법 ~ 비고(참고내용)으로 컬럼을 구분하여 작성
(위에 설명한 대한 상세내용은 따로 포스팅 하였으니 생략 : 리텐션을 위한 전략 - AARRR & 아하 모먼트 — 실무와 IT (tistory.com)

리텐션을 위한 전략 - AARRR & 아하 모먼트

=> 서비스기획자는 데이터를 유의미하게 다룰 줄 알아야 하며, 통계를 볼 줄 알아야 함