[팀] 겸상 - 3주차 전체미팅: 애플리케이션 기능/서비스 설계(220522)

| 애플리케이션 기능/서비스 설계

기능목록, 사용자 분석, 사이트 맵

애플리케이션 기능/서비스 설계에서는 "기능목록, 사용자 분석, 사이트 맵"을 작성해야 한다. 개발자의 품격에서 제공하는 영상을 먼저 학습한 후 진행하였다. 관련 영상은 다음과 같다. 

https://youtu.be/RYJtdnorzxE

 

https://youtu.be/MCVgUSNyc8g

 

https://youtu.be/odhNcgE1l4s

 

피드백에 대한 생각

이번에 우리 2팀은 멘토님으로부터 "지난주와 전혀 다른 팀이 되었다!"라는 평가를 받았다. 그 덕분에 지금도 자축하는 분위기이다. 사실 지난 벤치마킹 과정에서 준비와 발표를 그렇게까지 못했다고 생각하지는 않는다. 오히려 다양한 시도 중 하나라고 생각한다. 지난 3주의 모든 과정에서 우리 팀은 매우 충실했다. 그 시간 동안 우리는 구성원의 특성을 알아가고 팀 프로젝트라는 과녁의 정중앙을 맞추기 위한 영점을 조절했다. 따라서 이번 애플리케이션 기능/서비스 발표에 대한 멘토님의 긍정적 평가는 모든 세팅이 잘 마쳐졌음에 대한 방증이며, 우리는 심판이 언제 옐로 카드를 꺼내는지 확실히 알게 되었다!

멘토님의 피드백은 크게 세 가지이다. 

1. 채팅방은 구현하기에도 어렵고 구현이 가능하다고 하더라도 혼밥 매칭이라는 용도로 사용할 때 이점보다는 혼란을 만들 것 같다. 다만 메시지 전송 기능 정도는 허용해도 좋을 것 같다.
2. 혼밥은 계획적이기보다는 즉흥적인 경우라고 본다. 따라서 즐겨찾기 기능이 불필요해 보인다.
3. 식당 관계자가 밥상을 생성하는 등 상술에 악용될 여지가 있다. 식당 관계자가 아니라는 것을 어떻게 확인하여 필터링할 것인가?

 

1번의 경우에는 애초에 게시판을 생각하다가 특색 없는 서비스가 될 것 같아-무리하게-채택한 기능이다. 멘토님 덕분에 채팅을 생각하지 않아도 되어 부담이 줄었다.

2번의 경우 전체 모임 후 팀 회의 끝에 즐겨찾기 기능을 포기하지 않기로 했다. 혼행에서 혼밥을 생각한 것이기 때문에 여행의 계획적인 특징을 혼밥에도 적용해야 한다고 보았기 때문이다.

3번은 우리 서비스에 많은 유저가 유입되고 사용되면 그때 고민하기로 했다.

그 밖에도 다른 팀 리뷰 시 "회원가입과 로그인은 카카오 로그인 API 기능만 써도 충분하다. 개인정보를 자체적으로 보관하는 것은 이점보다 리스크가 크다."라고 코멘트하셔서 우리 팀도 카카오 로그인 API를 통한 로그인만 적용하기로 하였다.

 

3주 차 애플리케이션 기능/서비스 설계 풀영상

https://youtu.be/OT_Zz8QX9xU

 

※ 참고: 발표자료, 보고서

개발자의품격4기-2팀-3주차-기능_서비스설계-발표자료.pptx

4.27MB

개발자의품격4기-2팀-3주차-기능_서비스설계-보고서.pdf

0.50MB