가장 기대했던 시간이다.
개발자 + 디자이너가 한 팀이 되어 실제 서비스를 런칭한다.
사용자 피드백을 기반으로 서비스를 개선해보는 경험은 정말 소중하다.
🤓 무엇에 도전했는가
사용자에게 선보일 실제 서비스를 런칭하다.
💡 현재까지의 성과
도메인 공개 후 11일간
962명의 사용자를 얻었고
채널톡과 구글 설문지를 통해 총 131개의 사용자 피드백을 수집했다.
가장 많이 발생한 page_view 이벤트는 5,578회 발생했다.
💡 마지막 프로젝트의 의미
마지막 프로젝트가 내게 얼마나 의미있는 지를 강조하기 위해 이전 팀 프로젝트를 회고해본다.
프로젝트의 내용은 매우 간단히 언급하고 아쉬웠던 점을 중점으로 적어본다.
-
부트캠프 1일차 : (3-4일간 진행) 자유 주제 JWT 로그인이 가능한 사이트 구현
프론트/백 역할을 나눌 기본지식조차 부족한 채로 어떻게든 기본 구색 로그인, 포스팅 기능을 갖추다. 아쉬웠던 점은 코딩이 익숙치 않아 구글링한 답변을 응용하기가 어려웠다. 구현하고 싶은 것을 구현하지 못하고, 구현한 것 부분 중에서도 이해하지 못한 개념들에 대한 아쉬움이 있었다.
프로젝트명 : 산 넘어 산 -
클론코딩 : (6일간 진행) 실제 사이트를 클론코딩
처음으로 프론트와 백 역할을 나누어 진행함. API를 설계해 데이터를 받아오는 과정을 학습하게 되었고 매번 API를 호출할 필요없이 프론트단에서 상태관리를 하는 연습도 했다. 또한 실제 사이트의 디자인, CSS, 사용자 경험을 개발자의 시선에서 분석해볼 수 있던 시간이었다. 아쉬웠던 점은 사전에 배정된 팀원들이 개인사정으로 프로젝트 시작 직전 하차, 다른 팀원의 절반 인원인 프론트1, 백1의 포지션으로 프로젝트를 수행하게 되었다. 다행히 다른 프로젝트와 달리 아이디어와 디자인을 구상하는데 시간을 덜 쏟을 수 있어 개발 시간을 더 확보할 수 있었다. 다만 구현해보고 싶던 기능과 디테일적인 부분을 기존보다는 스펙아웃할 수 밖에 없어 아쉬웠다. 또한 실제 사이트를 더 개선할 방법을 고민해보고 적용해보고 싶었는데 그러한 시간을 갖지 못했다.
(구체적으로는 실제 사이트에 없던 무한스크롤과 반응형 기능을 추가해보고 싶었다.)
프로젝트명 : DANOSHOP -
미니 프로젝트 : (2주간 진행) 자유주제
부트캠프에서는 이렇게 안내했다.
미니 프로젝트 기간의 가장 큰 방점은 재정비입니다. 달리지 마세요! (don't run)
하지만 달리기를 할 때 가장 주의할 점은 중간에 걸으면 안 된다는 것이다! 걷기 시작하면 멈추고 싶고, 앉아있고 싶고, 눕고 싶어진다.. 특히 배울점이 많고 성실한 팀원들을 만난 덕에 신이 난 나는 이전에 구현해보고 싶던 기능들을 적용해보고 싶었다. RESTful API, 차트 라이브러리와 웹소켓, 동적으로 시간 경과율을 표시해주는 progress bar, 반응형, gamification UX 등을 구현하느라 계속 달렸다. 즐겁게 달렸다.
실전 프로젝트와 달랐던 점은 '개발을 위한 서비스', '내가 해보고 싶은 기능을 구현'한다는 느낌이 강했다는 것이다. 사실 이 서비스에 꼭 필요하지는 않을텐데.. 하면서도 구현해보고 싶은 기능이기에 적용했고 사용자에게 어떤 경험을 줄 지, 나의 의도가 잘 전달될 지를 '추측'하며 코드를 작성했다. 완성 후에 부트캠프의 다른 개발자들에게 사용 후 피드백을 요청하긴 했지만 실제 사용자의 의견이 부족했기에 프로덕트 자체의 완성도와 방향성에 대한 아쉬움이 있다.
프로젝트명 : SPARTA Study Club
💡 마지막 프로젝트 진행과정
이전 프로젝트들에서 아쉬웠던 점을 고려하며
'개발자가 구현하고 싶은 기능'보다 '사용자에게 필요한 기능'을 구현하고자 했다.
그러다보니 오히려 이전 프로젝트보다 기능 자체는 단순해졌다.
다만 실제 서비스 런칭이다보니 퀄리티와 디테일, 기타 배포 시 주의점 등이 많았다.
📍 전 주차에 걸쳐서 서비스의 방향성과 사용자에게 더 필요한 기능, 더 친절한 UX에 대해 계속해서 의견을 나누고자 했다.
📍 MVP는 2주차 중반에 완성되었는데 사용자 피드백 과정에서 우리가 고려하지 못한 새로운 관점, 의견 등이 계속 쏟아져 나왔고 크고 작은 버그 및 기능 개선이 쉼 없이 이루어졌다.
1주차
주제 확정. 디자인/개발 뼈대 잡기
2주차
초기에 목표한 기능 구현이 완료되고 디테일과 버그를 수정하기 시작함.
배포 후 도메인 적용
사용자 피드백 유도를 위해 전 페이지에 보여지는 채팅상담 플로팅 버튼 적용
3주차
디자이너 결과물 적용, 사용자 경험과 버그, 코드 리팩토링을 진행하면서 홍보 방식과 컨셉 구상
지인 피드백 수집하여 서비스 개선 시작
4주차
사용자 요청 많았던 기능 추가
각종 커뮤니티와 오픈카카오톡방 페이스북, 인스타 광고 시작
🧐 무엇을 배웠는가
이터레이션의 중요성
팀 내부에서 고려하지 못했던 관점과 의견이 사용자들로부터 쏟아졌다.
대부분 UI, UX에 대한 제안이었지만 넓게는 서비스의 방향성과 관련된 추가 기능 등 주제도 다양했다. 최대한 반영하려 했지만 반영을 해야할 지 말 지 판단하기 어려운 내용들도 많았다. 회의해야 할 내용들이 끝도없이 늘어만 가는 것 같아 막막한 느낌이 들기도 했다. 이러다 서비스의 정체성이 모호해지면 어쩌나하는 고민도 됐다. 부트캠프 대표자분과 면담하며 의견을 묻기도 하고 다른 블로그 글들도 여럿 읽었다.
그 결과 서비스는 사용자와 함께 만들어가는 것임을 인정해야만 했다.
아무리 사용자 경험을 고려해 개발한다고 해도 실제 사용자의 목소리를 듣지 않는 서비스는 반쪽짜리 서비스일 뿐이라는 생각이 들었다.
블로그 글 중 와닿았던 글 일부를 발췌해왔다.
Q : 프로젝트 초기에 고객이 원하는 것을 확실하게 알고 있다고 가정해 볼까요? 그래도 여전히 이터레이션이 필요할까요?
A : 당연합니다, 고객의 피드백은 당신이 중요한 모든 것을 알고 있다고 생각할 때 더 중요합니다. 아주 쉽고 단순해 보이는 소프트웨어도 고객과 같이 검토하는 것은 항상 중요합니다. 만약 고객이 잘 진행하고 있다고 말해주고 실제로 모든 요구사항에 맞게 일을 시작했다 하더라도 이터레이션은 여전히 제대로 진행되고 있다는 확신을 줍니다. 그리고 고객의 생각은 항상 변한다는 것을 잊어버리지 마세요.
Q : 중간에 항상 고객이 생각을 바꾸도록 하기 보다는 정말 고객이 원하는 것을 파악하는데 시간을더 사용해서 요구사항을 정말 확실하게 받는 것이 낫지 않을까요?
A : 그렇게 생각할 수 있습니다만 이는 재앙으로 가는 방법입니다. 오래 전 나쁜 시기에 개발자들은 프로젝트 초기에 한 줄의 코드나 설계 결정을 내리지 않고 모든 고객의 요구사항에 대해 확실히 하기 위해 몇 년씩 허비하고는 했습니다. 불행히 이런 접근은 실패했습니다. 만약 초기에 고객이 필요로 하는 것을 완벽히 이해했다 하더라도 고객도 가끔 이해를 못하기도 합니다. 그래서 고객도 당신만큼이나 이해하고 싶어합니다. 개발할 소프트웨어에 대한 팀과 고객의 이해를 높일 수 있는 방법이 필요한데 빅뱅이나 모든 사항이 매일 돌처럼 굳어지기를 바라는 초반에 요구사항을 받는 방법으로는 이렇게 할 수 없습니다.
Q : 고객이 나쁜 소식을 갖고 와서 지금 개발중인 게 잘못됐다고 이야기합니다. 어떻게 해야 하나요?
A : 좋은 질문입니다. 잘못이 일어나면 이터레이션 동안에 잘못되었다는 것을 알게 되고 다음 이터레이션 과정에서 되돌아 볼 필요가 있습니다.
출처 : 훌륭한 소프트웨어 개발이란, 비밀은 "이터레이션"
