Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: 기본 카테고리 자동 생성 #571

Open
1 of 5 tasks
BurningFalls opened this issue Dec 18, 2024 · 4 comments
Open
1 of 5 tasks

feat: 기본 카테고리 자동 생성 #571

BurningFalls opened this issue Dec 18, 2024 · 4 comments
Assignees
Labels
android We are android>< backend We are backend>< confirm need confirmation! feat 기능 (새로운 기능)
Milestone

Comments

@BurningFalls
Copy link
Contributor

BurningFalls commented Dec 18, 2024

🥸 어떤 기능인가요?

해당 기능은 구현이 급한 기능은 아니어서 우선순위가 밀리므로, 충분한 토의 후 결정해도 될 사안입니다.

동기

현재는 계정을 생성하면 기본 카테고리가 생성되어 있지만, 해당 카테고리는 삭제가 가능합니다.
따라서 사용자가 어떤 이유로 기본 카테고리를 삭제하면, 스타카토를 생성할때 생성이 불가능합니다.
카테고리가 없을 때 스타카토가 저장이 안 되는 상황을 막아, 사용자의 불편함을 개선할 수 있습니다.

기능

카테고리가 없을 때 스타카토를 생성하면, 자동으로 기본 카테고리가 생성되면서 스타카토가 그 안에 포함된다.

기능 구현에 대한 추가 의견

< 의견 1 >

  • (기능 구현) 반대: 기본 카테고리를 삭제한 건 사용자의 잘못이다. 사용자의 실수까지 고려해서 앱을 만들 필요는 없다.
  • (기능 구현) 찬성: 현재 앱은 제대로 된 가이드가 없다. 처음 앱을 설치한 사용자가 이것저것 만져보다가 기본 카테고리를 삭제할 수도 있다.
  • 정리: 처음 앱에 접속했을 때 가이드가 있는지 없는지에 따라서 이 기능의 찬성/반대 여부가 달라질 수도 있다.

< 의견 2 >

  • 반대: 차라리 기본 카테고리를 삭제 불가능하게 만들면, 사용자가 실수할 일이 없고 이 기능을 만들 필요도 없다.
  • 찬성 또는 반대: 내 의지로 만들지 않은 기본 카테고리가 존재하는게 불편하게 느껴진다. 삭제를 할지 말지는 사용자의 자유다.
  • 정리: 기본 카테고리의 삭제 가능 여부에 따라서 이 기능의 찬성/반대 여부가 달라질 수도 있다.

세부 구현

< 방법 1 >

  • 스타카토 생성 버튼 클릭
  • Client -> Back : 카테고리 목록 API 요청
  • Client <- Back : 카테고리 목록 API 응답 (카테고리 목록 획득)
  • Client : 카테고리 개수가 0개인지 확인. 0개라면 아래를 수행
    • Client -> Back : 기본 카테고리 생성 API 요청
    • 기본 카테고리 생성됨
    • Client <- Back : 기본 카테고리 생성 API 응답 (기본 카테고리 ID 획득)
  • Client -> Back : 스타카토 생성 API 요청
  • Client -> Back : 스타카토 생성 API 응답

< 방법 2 >

  • 스타카토 생성 버튼 클릭
  • Client -> Back : 카테고리 목록 API 요청
  • Client <- Back : 카테고리 목록 API 응답 (카테고리 목록 획득)
  • Client : 카테고리 개수가 0개인지 확인. 0개라면 아래를 수행
    • Client : 카테고리에 기본 카테고리 문구를 띄움 (기본 카테고리는 아직 없는 상태)
  • Client -> Back : 스타카토 생성 API 요청 (기본 카테고리 ID를 null로 보냄)
  • 기본 카테고리 생성됨
  • Client -> Back : 스타카토 생성 API 응답

세부 구현 평가

[ 방법 1 ]의 단점

  • 스타카토 생성을 완료하기 전에 기본 카테고리가 DB에도 생성되는데(DB에 저장되는데),
    만약 사용자가 중간에 스타카토 생성을 취소하는 경우, 카테고리 삭제 API를 보내는 롤백 작업이 필요하다.

✅ 작업 내용

논의 후 결정

😇 이때까지 끝낼게요!

기능 개발 완료 예상 날짜를 작성해주세요. 신중하게 생각해요!

논의 후 결정

🙇‍♀️ 이슈 확인했어요:)

팀원에게 이슈 확인을 부탁해요! 이슈를 확인한 팀원은 체크 표시를 해주세요!

@BurningFalls BurningFalls added android We are android>< backend We are backend>< feat 기능 (새로운 기능) confirm need confirmation! labels Dec 18, 2024
@BurningFalls BurningFalls added this to the sprint-7 milestone Dec 18, 2024
@BurningFalls BurningFalls self-assigned this Dec 18, 2024
@linirini
Copy link
Contributor

linirini commented Dec 18, 2024

사용자의 피드백을 모두 수용하고 서비스에 반영하기엔 한계가 있기 때문에 우선 해당 기능 개발이 필요한지에 대한 의견을 공유해볼게요:)
저희가 기본 카테고리를 제공하기 시작했던 이유가 "추억"과 "스타카토" 정의의 모호함을 해소하기 위함이었습니다. 그리고 이제는 "추억"이라는 용어 대신 "카테고리"를 사용하기로 결정한 상태입니다.
그렇다면 용어 변경을 적용했을 때 사용자 반응을 우선 살펴보면 어떨까요?
또한, 아직 해당 방식으로 기능 개발이 필요하다고 판단 내리기에는 데이터가 부족하다고 생각이 들어요. (개발 비용에 비해 데이터가 부족한 느낌?)
제이슨의 DDD 강의를 들으셨나요? ㅎㅎ 당시에 엘리베이터 문제가 기억에 남는데요, 이젠 단순히 사용자가 원하니까!를 넘어서 그 속에서 사용자가 느끼는 불편의 본질이 무엇인지 생각해보고, 나아가 그 문제를 해결해서 서비스에서 취하고자 하는 점은 무엇인지 생각해보아도 좋을 것 같아요! (저도 아직 잘 안된답니다....그래서 자꾸 느낌느낌 거리네요.....ㅎㅎ...)
비스무리한 관련 글도 공유합니당!
https://brunch.co.kr/@editssn/125
https://brunch.co.kr/@zungyeonlee/13

@Junyoung-WON
Copy link
Contributor

Junyoung-WON commented Dec 18, 2024

그렇다면 용어 변경을 적용했을 때 사용자 반응을 우선 살펴보면 어떨까요?
또한, 아직 해당 방식으로 기능 개발이 필요하다고 판단 내리기에는 데이터가 부족하다고 생각이 들어요. (개발 비용에 비해 데이터가 부족한 느낌?)

저도 리니의 의견에 동의합니다!
추억스타카토의 혼용을 막고자 기본 추억을 제공했고, 이 둘을 더 명확하게 구분짓고자 추억 대신 카테고리라는 용어를 사용하기로 했으니, 사용자의 반응을 보고서 개발 여부를 결정해도 늦지 않다고 생각합니다.
그럼에도 사용자가 불편해한다면, 그 때 위와 같은 다양한 방법을 고민해봐도 좋을 것 같아요!

카테고리가 없을 때 스타카토가 저장이 안 되는 상황을 막아, 사용자의 불편함을 개선할 수 있습니다.

다만 지난 회의에서 언급되었던, "기껏 스타카토 정보를 작성했는데, 카테고리가 없다는 이유로 처음부터 다시 작성해야해?!" 라는 불편함을 해소하고자 하는 목적에서는 폭포가 기능 구현을 제시한 이유가 타당하다고 생각합니다.
그래서 우선 제 의견을 드리자면,

  • 기본 카테고리는 삭제가 가능하되(이는 순전히 사용자의 자유 의지 영역!),
  • 카테고리가 없는 경우에 스타카토를 만든다면, 자동으로 카테고리를 만들어 담아주자
    • 작성해놓은 스타카토 정보가 사라진다는 불편함 제거
    • 또는 클라이언트 측에서 카테고리를 생성하도록 유도하는 것도 방법일 것 같아요~

@linirini
Copy link
Contributor

linirini commented Dec 18, 2024

다만 지난 회의에서 언급되었던, "기껏 스타카토 정보를 작성했는데, 카테고리가 없다는 이유로 처음부터 다시 작성해야해?!" 라는 불편함을 해소하고자 하는 목적에서는 폭포가 기능 구현을 제시한 이유가 타당하다고 생각합니다.

해당 불편함에 저도 동의합니다!

나아가 카테고리가 없을만한 상황에 대해서 생각해보았는데요! 생각의 흐름대로 좀 적어보겠습니다...ㅎㅎ

  1. 기본 카테고리를 삭제한다 -> 아래에서 이 부분에 대해서 더 언급해놓았습니다.
  2. ... 떠오르지 않았어요 ㅜㅜ 지난 사용자 피드백에서 기간이 없는 카테고리에 대한 수요가 더 많았던 걸로 기억합니다. 그렇다면 카테고리가 전혀 없거나 기간 없는 카테고리가 1개 이상 존재하지 않을까?
  3. 기간이 있는 카테고리만 만들었다면? 기간이 없는 카테고리 1개만 만든다면 스타카토 작성 후 카테고리가 없다는 이유로 다시 작성하는 일은 일회성으로 일어나지 않을까? 기간이 없는 카테고리 하나만 만들어놓아도 어느정도 극복 가능한 문제라고 상상해보았어요
    이러한 생각도 한 번 해보았습니다..! 말이 잘 정리되지 않는 것 같아서 여기까지 할게요 ㅋㅋㅋ

그리고 저는 만약에 한다면, **클라이언트 측에서 카테고리를 생성하도록 유도하는 것도 방법일 것 같아요**가 개인적으로는 끌리네요!
전에도 말씀드렸다시피 자동으로 카테고리 생성되는 전략은 현재 비즈니스 정책(중복 이름 불가능, 기간 설정 등등)에서 시나리오가 다양할 수 있겠다는 생각이 들어요!
저번 회의에서 말했듯, 간단하게 제목만 사용자가 직접 입력할 수 있게 유도하면 좋을 것 같아요! 그렇다면 하나의 트랜잭션에서 처리할 수 있으니까 만약 사용자가 중간에 스타카토 생성을 취소하는 경우, 카테고리 삭제 API를 보내는 롤백 작업이 필요하다. 문제도 방지할 수 있을 것 같기도 하고요!

현재는 계정을 생성하면 기본 카테고리가 생성되어 있지만, 해당 카테고리는 삭제가 가능합니다.
따라서 사용자가 어떤 이유로 기본 카테고리를 삭제하면, 스타카토를 생성할때 생성이 불가능합니다.

저번 회의에서는 기본 추억이 왜 있는지 몰라서 일단 삭제하고, 스타카토를 생성하려니 못 만들었다! 라고 했던걸로 기억하는데요,
여기에서 가설을 하나 생각해보자면
**기본 카테고리라고 명칭이 바뀌면 더 직관적이기 때문에 삭제하지 않는다.**는 가정도 가능할 것 같아요. 더불어, "기본 추억이 어떤 것인지 모르니 일단 삭제한다 VS 일단 둔다"도 어떤 사용자가 많은지 저희에겐 데이터가 없기 때문에 해당 기능 개발의 이유가 되기엔 조금 부족하다고 생각했었습니다. 그래서 이에 대한 사용자 반응을 지켜보고 싶기도 합니다.
더 많은 사용자 반응을 본 후에 결정해도 좋을 것 같아요!

@BurningFalls
Copy link
Contributor Author

BurningFalls commented Dec 19, 2024

추억을 카테고리로 변경하면서 기본 카테고리의 이름을 기본 카테고리로 변경해볼 수 있겠네요!
리니 말대로 이렇게 변경하고 나서 사용자 경험을 다시 받아보고 판단해야할 것 같습니다.

클라이언트 측에서 카테고리를 생성하도록 유도한다의 방법에 대해서도 동의합니다.
저도 온보딩이 제대로 이루어진다면, 카테고리 자동 생성을 굳이 만들지 않아도 될 것 같다고 생각해요.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
android We are android>< backend We are backend>< confirm need confirmation! feat 기능 (새로운 기능)
Projects
Status: No status
Development

No branches or pull requests

3 participants