회의준비
우리팀은 Notion과 Slack을 사용한다. 팀 전용 Notion Workspace를 만들고 Slack과 연동하여 기록해 놓는다.
아이디어 나열
노션을 통해 실생활에서 불편했던 점을 전부 나열하였다. 노션 템플릿에 표 형식으로 한번에 작업하니 좋았다. 나열한 후 팀원 모두가 처음부터 끝까지 각각의 아이디어에 대해 논의해보는 시간을 가졌다. 후보군을 3개로 줄이고 3개의 아이디어를 모두 구체화 하였다. 1차적으로 패션, 헬스케어, 건강 관련 아이템이 나왔고 해당 아이템을 의논하였다.
- 참고할만한 레퍼런스가 있는지?
- 만들게 된다면 어떤 점이 어려울지?
- 어려운 점을 다른 방안으로 대체할 수 없는지?
- 사용자가 정말 필요로 할지?
위 3개에 대해 각각의 아이템마다 생각해보았다. 패션과 관련된 아이디어는 기존에 좋은 레퍼런스가 있다는 이유와 레퍼런스를 개선할 수 있는 방안을 고려해보았지만 유통비용이 발생하는 이유로 부결되었다. 건강 관련 아이템은 서비스를 운영하려면 전문지식이 필요했는데 전문성을 커버해줄 인원이 없었다. 헬스케어는 팀원 대부분이 헬스장에서 PT를 받아본 경험이 있었기에 쉽게 공감할 수 있었다. 또한 많은 팀원의 경험속에서 서비스의 필요성이 인정되면서 "헬스케어"관련 서비스를 진행하기로 하였다.
MVP모델
MVP 모델을 선정하는 과정에서 논란이 많았다. 서비스를 잘 만드는 것도 중요하지만 서비스를 누가 사용하는가? 명확하게 짚고 넘어가는게 중요하다고 생각하게된 날이다.
고객이 누구야?
우리는 헬스장의 트레이너선생님(PT쌤)과 회원간의 소통을 위한 서비스를 준비 중이다. 근데 PT쌤을 위한 서비스인지? 회원을 위한 서비스인지? 각자 생각은 하고 있었지만 당시에는 모호한 결과를 초래했다. PT쌤과 회원 모두를 위한 서비스를 만들자고 생각했던 것이다. 물론 틀린말은 아니지만 두 카테고리의 고객이 존재하다는 것은 마케팅을 하던 MVP모델을 제작하던 서비스를 구현하던 서비스의 주요목적이 흔들릴 수 있는 큰 이유였다. PT쌤이 고객인 경우 PT쌤이 본 서비스를 회원에게 권유하여 여러 회원을 자연스럽게 늘려갈 수 있었다. 회원이 고객인 경우 사용자들에게 마케팅하여 PT쌤에게 해당 서비스를 이용하고 싶다고 요청하거나 해당 서비스를 지원하는 헬스장으로 방문해야 한다. 해당 내용만 보기엔 PT쌤을 통해 회원에게 마케팅하는 방법이 좋은 방법이라고 생각했다. 하지만 본 서비스의 본래 목적 자체가 PT쌤이 편하기보다 회원이 편하기위함이 컸기 때문에 MVP모델은 회원이 사용하는 페이지를 주로 이루게 되었다.
초반 진행
디자이너, AOS, IOS, 벡엔드 모두가 함께 진행하는 프로젝트인 만큼 대략적인 일정이 필요했다. 먼저 진행한 작업은 디자이너의 WorkFlow 작성이다. 디자이너의 WorkFlow는 개발의 전체적인 흐름을 관여한다. WorkFlow의 완성에 따라 클라이언트는 해당 디자인을 각자 퍼블리싱하고 제작할 기능을 고려한다. 벡엔드는 API 명세와 CI/CD를 준비한다.
이후 진행
이론으로 배운 "소프트웨어 공학"을 실무에서 사용할 생각을 못했었다. 하지만 IOS 팀원의 의견으로 너무 좋다는 생각을 받았다.
지금은 첫째 주에 만들 일정만 정하고 1주 ~ 2주간격으로 하나씩 계획하고 개발하자
위 한마디로 우리는 "로그인 페이지"에 대한 계획을 구체적으로 작성했다. 재밌는 논란이 많았는데
- 이메일 로그인을 넣을 것인가?
- 소셜 로그인을 넣을 것인가?
- 어떤 정보를 수집할 것인가?
- 이용정보 동의화면과 권한 설정화면은 어떻게 할것인가?
- 회원과 PT쌤을 어떻게 구분할 것인가?
많은 논란이 있었지만 1번, 2번의 경우 노드 팀원의 좋은 아이디어로 전화번호 인증을 통한 로그인으로 계획되었다. MVP모델인 만큼 소셜 로그인은 모두 제외시켰으며 정보는 이름과 전화번호만 수집하기로 하였다. 4번의 경우 어쩔 수 없이 개발해야하는 상황이며 5번의 경우 MVP모델을 회원으로 잡았기때문에 PT쌤과 구분하는 버튼을 비활성화 시켜놓은 후에 개발이 완료되면 활성화 시키기로하였다.
내가 해야할일
일정이 다가올때까지 사용할 기술에 대해 논의하고 이해가 필요하다.
