회고4 [업무회고] RIZZ 2.0 상담 모델 설계 배경의사와 직접 상담을 하고 병원 예약을 하는 서비스인 2.0 버전의 핵심 모델은 상담이었습니다. 처음에는 상담과 병원 예약이 가능한 서비스의 형태였는데 이것만으로는 고객이 참여할 요인이 없다고 생각하여, AI 얼굴 타입 및 나이 분석 기능과 연계하여 상담과 자연스럽게 연결되도록 구성했습니다. AI 분석에 대한 것은 다른 글에서 다루고, 이번 글에서는 상담에 초점을 맞춰보겠습니다. 이번 글에서 다뤄볼 것은 다음과 같습니다.상담 모델 설계하위 호환성명확한 의도 전달을 위한 API 분리상담 모델 설계도메인 Factor피부 진단에 대한 카테고리입니다. 팩터와 서브팩터로 나눴습니다. 개념상 값객체로 두어도 충분하다고 생각했었지만, 온보딩을 할 때 메인, 서브팩터의 조회가 필요하고 시술 및 이벤트를 조회할 때도 .. 2025. 1. 18. [업무회고] RIZZ 3.0 알림함 & 메시지 예약 발송 기능 설계 및 구현 앱의 알림함 기능 및 파트너가 유저를 선택하여 예약 메시지를 보내는 기능에 대한 회고입니다.먼저, 요구사항은 다음과 같았습니다.요구사항알림함유저는 앱푸시를 받은 메시지들을 알림함에서 확인할 수 있다.유저는 알림들의 읽음 여부를 확인할 수 있다.앱푸시를 클릭하면 알림함의 해당 메시지로 연결된다.예약 메시지병원은 유저에게 보낼 앱푸시 메시지를 지정된 시간에 등록할 수 있다.고민한 것들알림함 모델의 위치알림함 모델을 유저와 파트너 중 어디에 위치를 시켜야 할지를 결정하기 위해 모델의 책임을 생각해습니다. 요구사항에 따르면 알림함은 앱푸시 가 될 메시지의 저장, 읽음 여부 체크를 위한 수정을 담당합니다. 이어서 두 컨텍스트를 보면, 파트너는 알림의 작성, 발송 등 알림의 생성과 관리에 대한 주요 행동의 주체이고.. 2025. 1. 14. [업무회고] RIZZ 3.0 유저의 병원별 추천 코드를 통한 맴버십 관리 배경병원 맴버십앱으로 피봇팅을 결정한 뒤, 가장 핵심이 되는 개념 두 가지는 “단골”과 “추천”이었습니다. 병원은 특정 유저가 본인들의 단골임을 구분할 수 있어야 했고, 유저는 본인의 추천코드를 통해 다른 사람을 해당 병원의 단골로 초대할 수 있어야 했습니다. 또한 고객은 병원을 여러군데 다닐 수 있기 때문에 추천코드도 여러 개를 가질 수 있어야 했습니다. 또한 병원들도 자체적인 추천코드를 가지고 있어서, QR 이나 팜플렛 등을 통해 내원한 고객에게 앱 설치 시 간편한 단골 등록 경험을 줄 수 있어야 했습니다. 최종적으로 정리된 요구사항은 다음과 같습니다.유저는 여러 곳의 병원에 단골로 등록 가능하다유저는 단골인 병원별로 개별적인 추천 코드를 가질 수 있다.유저는 본인의 추천코드를 통해 친구에게 특정 .. 2025. 1. 12. 2년차 끝자락에서의 반성과 다짐 회고를 각잡고 하려니 회고툴을 찾고, 참고해서 초안을 작성하고, 공개해도 되는 것과 안되는 것을 구분하고, 블로그에 공개할만큼 정돈을 하려고 하니 계속 완결이 되지 않았다. 그래서 뭐라도 일단 완결을 짓고 추후 개선해나가는 것이 중요하다고 생각하여 지금 드는 생각부터 천천히 정리해본다. 이번 글은 반성과 다짐의 글이다.주니어와 시니어의 기준은 무엇일까? 가장 공감이 되는 정의는 주니어는 ‘문제를 인지하고 시키는 것을 잘하는 사람’, 시니어는 ‘문제점을 찾고 대안을 제시하고 문제를 해결하는 사람’이라는 정의였다. 단순히 연차로 구분되는 것이 아니고, 문제를 접근하고 그것을 해결하는 방식에 있어서의 차이가 그 경계선의 기준이라고 생각한다.좀 더 주인의식을 가지고 일했으면 좋겠어요 몇 주전 최근 대표님과 CT.. 2024. 10. 1. 이전 1 다음
