[우테코] 피움(pium) 팀 프로젝트 회고 - 2주차

2주 차 회고에 앞서

이번 2주 차는 1주 차 보다 더 바쁘고 빠르게 지나갔다..

 

회의의 연속의 연속이었다.

 

대략적으로 어떤 일들이 있었는지 생각해 보면 팀 로고와 메인컬러, 주 폰트를 선정했고, 팀에서 공통적으로 적용할 수 있는 컨벤션을 선정했다. 또 백엔드, 프론트엔드 프로젝트 세팅을 했고, 포비와 피움팀 커피챗을 했고, 목요일에는 사용자 인터뷰를 진행했다. 이 인터뷰를 기점으로 기획이 조금 변경되기도 했다.

 

덕분에 1차 데모데이도 무사히 마칠 수 있었다.

---

피움 로고와 색상, 폰트

요즘 슬랙에서 자주 보이는 우리 팀 로고다!

주노가 슬랙 여기저기 이모지를 붙이고 다닌다. 덕분에 광고 효과가 꽤 있는 것 같다 ㅎㅎ

 

다양한 후보들이 있었는데 최종적으로 선택된 로고는 가장 심플하면서 눈에 잘 띄는 로고로 선정했다.

 

중간에 보이는 이모지 같은 로고도 보이는데, 별생각 없이 로비에 앉아서 주노랑 그리다가 태어난 친구다.

로고에는 글자만 있는 게 깔끔해서 로고에서 뺐지만 꽤나 귀여워서 파비콘이나 앱 내에서 사용하려고 생각중이다 !

 

메인 컬러의 경우에는 피움 팀의 색깔을 가장 잘 드러낼 수 있는 녹색 계열로 설정했다.

정확한 컬러 코드는 1BCC66 색인데, 다른 녹색 계열보다 눈에 잘 띄었고 따뜻한 색감이 잘 느껴졌다.

 

강조색과 배경색, 보조색은 어떤 색으로 선정할 지 고민하다가...

우리나라에서 가장 큰 포털의 색 조합을 가져가기로 했다 ! (괜히 이런 색 조합을 쓰지 않을 것이라고 생각해서..?)

 

폰트는 디자인을 선정하는 방식과 동일한 방식으로 결정했다.

각자 마음에 드는 폰트를 찾아와서 피그마에 올린 후, 투표를 통해 결정했다.

우리나라에 이렇게 많고 이쁜 폰트들이 있는지 처음 알았다.

 

에스코어드림, 나눔스퀘어라운드, Gmarket Sans 3개 폰트가 결승전에 올랐고, 최종적으로 나눔 스퀘어라운드로 결정했다 !

 

1주 차 회고에서 느꼈던 것처럼, 팀원들 모두 자신의 의견을 주장하고 다 같이 결과를 만들어 나가는 방식으로 의사 결정하는 부분이 너무 재밌었다.

---

협업 컨벤션

 

우리 팀에서 공통적으로 적용할 수 있는 Github 컨벤션을 먼저 설정했다.

Branch 전략, Issue, PR, commit message 컨벤션을 맞췄다. 

 

Branch 전략

Branch 전략은 Github Flow와 Git Flow의 중간 지점? 인 GitLab Flow로 결정했다.

정확히 GitLab Flow와 동일하지는 않지만, 현재 우리가 개발하는 서비스의 규모에 맞춰서 필요한 장점만 가져왔다.

 

크게 3개의 브랜치로 개발한다.

 

1. 팀원들 각자 맡은 기능을 개발하는 Feature(Refactor, Fix..) 브랜치.

2. 기능 개발을 완료한 이후 완성된 기능을 가지고 있는 Develop 브랜치.

3. 스프린트나 데모데이와 같이 중요한 배포가 이뤄지는 상황에서 버전 관리를 하는 Main 브랜치.

 

위와 같이 결정한 이유는, 팀원들 각자가 개발하는 기능에 집중하기 위한 Feature 브랜치가 우선적으로 필요하다고 판단했다.

그에 따라서, 완성된 기능을 합치는 브랜치가 필요했는데

여기서 Main 브랜치 하나만 가져갈지, Develop 브랜치를 중간에 하나 둘 지 고민했다.

 

여러 의견을 주고받은 끝에 개발 단계와 배포 단계를 구분하여 운영하자는 의견이 모아졌고, 결과적으로 Develop 브랜치와 Main 브랜치를 함께 가져가는 방향으로 결정했다.

 

Issue

이슈 템플릿을 만들기 전에, 팀원들이 생각하고 있는 이슈의 역할에 대해 먼저 의견을 나눴다.

 

나는 이전에 협업이나 프로젝트를 진행하며 이슈를 개발에 필요한 기능 목록(API 개발 목록) 으로만 생각하고 있었다.

그래서 당연히 이슈에는 개발할 API 목록만 필요하지 않을까 생각했는데, 팀원들과 의견을 나누다 보니 개발에 필요한 기능도 정의할 수 있으면서 자유롭게 의견을 제시할 수 있는 곳이라고 생각이 바뀌었다.

스프링 부트 Github Issue, 스프링 부트와 aws로 혼자 구현하는 웹 서비스 Github Issue

유명한 오픈소스들이나, Spring boot 깃허브를 참고해 보면 깃허브 이슈에는 사용자들이 다양한 의견을 남긴다.

생각해 보면 당연한 부분이기도 하다..?

버그 리포트, 개선점 제안, 트러블 슈팅과 같이 다양한 의견을 남길 수 있다.

 

그래서 이슈 템플릿을 기능 개발에만 초점을 두지 않고, 자유롭게 의견을 낼 수 있는 초간단 템플릿으로 만들었다.

팀에서 필요하다고 생각하는 버그 리포트만 정형화된 형식을 갖춘 템플릿으로 만들었다.

 

 

 

Pull Request

PR의 경우 가장 우선적으로 RCA 룰을 도입하기로 했다.

추가적으로 PR의 유통기간을 설정했다.

협업을 진행할 때 코드 리뷰가 미뤄지면 우리 팀 전체 개발 속도가 느려질 수 있다. 또한 우테코 일과 시간이 보장되어 있기 때문에 비교적 코드 리뷰를 할 수 있는 시간적 여유가 된다.

 

그러므로 PR의 유통기한은 업무시간 기준으로 하루 이내 로 우선 결정했다.

예를 들어 금요일에 올린 PR이면 월요일 6시까지 리뷰하면 된다.

 

커밋 메시지

커밋 메시지 컨벤션은 우테코에서 진행했던 방식에 모두 익숙했기 때문에 그대로 가져갔다.

아마 모든 팀이 거의 동일하지 않을까 생각된다 ㅎㅎ

 

---

사용자 인터뷰 & 서비스 기획 구체화

 

수요일에 포비와의 커피챗을 마친 후 리마인더 기능의 타겟이 모호하다는 생각이 들었다.

우리 팀은 나름대로 뾰족하게 서비스의 목적을 맞춰나가고 있는 것 같아서 인터뷰를 진행하지 않았었는데, 타겟에 대한 모호함이 직접적으로 언급되고 나서야 인터뷰를 해봐야겠다는 생각이 들었다.

 

Q) 어떤 사용자들이 피움 서비스를 사용할 것 같으신가요?

 

A) 반려식물을 키우고 있는 사람들이 더 편리하게 키울 수 있도록 편의를 제공합니다. 라는 대답으로는 우리 성에 차지 않았다.

 

반려식물 초심자가 아닌 꾸준하게 키우고 있는 사람들이라는 대상에 대한 뾰족함은 있었지만, 편리하게  라는 부분을 채울 수 있는 사용자 니즈 분석이 부족했다. 

 

그래서 반려식물을 키우고 있는 크루들을 우선 인터뷰했다. 또한 반려식물과 관련된 논문과 통계 자료들을 찾아봤다.

 

인터뷰 과정에서 공통적으로 찾을 수 있었던 내용은 아래와 같다.

즉, 사용자의 환경에 맞는 물 주기나 흙갈이 주기를 찾는 것이 어렵다는 것이다. 물을 자주 주거나, 자주 주지 않는 경우 둘 다 일일이 기록하는 것이 귀찮다는 의견이 많았고, 그에 따라 기록하는 것이 어려웠다는 점이다.

 

사용자가 느끼는 불편함을 키워드로 추려보면 사용자 환경에 맞는 주기 찾기, 기억, 기록 등을 추릴 수 있었다. 기록에서 왜 어려움을 겪는지 원인을 찾아보면 가장 큰 부분이 귀찮음과 까먹음이었다.

 

관리의 소홀함과 기록의 귀찮음을 함께 해결한다면 사용자가 원하는 서비스를 만들어 볼 수 있다고 판단했다.

 

또한 최대한 UX/UI를 직관적으로 만들어야 한다고 판단했다. 앱 내에서 버튼 하나에 따른 화면 depth 추가는 사용자들이 쉽게 피로감을 느낄 수 있다. 피움 서비스의 메인 페이지를 리마인더 페이지로 가져간 후, 해당 화면에서 바로 체크할 수 있도록 한다.

 

인터뷰와 논문, 통계 자료를 바탕으로 우리 팀 서비스의 목적과 대상을 더 구체화했다.

반려식물 관리 리마인더를 제공 -> 미루기, 물 주기 등 사용자 환경에 따라 유연하게 관리 가능

리마인더를 체크하면 자동으로 기록으로 남김

최대한 간단하고 직관적인 UX/UI

---

1차 데모데이

금요일에 1차 데모데이를 진행했다.

 

쵸파와 둘이서 1차 데모데이 발표를 맡게 되었다.

열심히 피피티를 만들고 있었는데 방향이 안 잡히기도 하고, 둘 만의 의견이 많이 담기는 것 같아서 팀원들에게 SOS 요청했다..

 

데모데이 전 날 팀원들 모두 너무 열정적으로 피피티 제작에 도움을 줘서 정말 고마웠다.

팀원들과 함께 발표자료를 만들면서 기획에 대한 뾰족한 방향성을 잡아갈 수 있었다. 또한 발표자료를 함께 만들면서 팀원들 간의 싱크를 하나로 맞춰갈 수 있다는 장점이 느껴졌다. 앞으로 데모데이 발표자료도 함께 만들기로 결정했다 😀

 

데모데이 진행 전에는 테코톡처럼 편안한 분위기에서 진행하는 줄 알았는데...

굿샷 강의장이라서 그런가 엄근진 분위기였다. 발표전에는 크게 긴장되지 않았는데 발표하러 올라가니 급긴장했다.

이 날 굿샷 정전 이슈로 발표자에게만 조명을 비춘 채 진행했는데, 그래서 더 주목받는 느낌도 들었다 ㅎㅎ

담당 코치님들이 포비, 크론, 제임스, 브리 여서 더 긴장된 것 같기도 하다 😅

 

그래도 다행히 무사히 발표를 마쳤다.

팀 문화에 대해 칭찬도 받았고, 2주간 기획에만 몰두했던 부분이 성과로 보인 것 같아서 팀원들과 셀프 축하를 했다.

개선점으로 제시받은 리마인더 알림 기능은 개발을 진행하며 점차 개선해 보기로 했다.

---

2주 차를 마치며 

2주간 우리 서비스를 만들어 나가기 위해 팀원들과 매일 회의하고 기획하며 시간 가는 줄 모르고 지냈다.

정신없이 바쁘고 회의를 거듭하다 보니 체력적으로 힘들기도 했지만, 무사히 1차 데모데이를 마쳤다는 것이 뿌듯했다.

 

1차 데모데이를 마치고 팀원들과 감정회고를 했는데, 나도 그렇고 팀원들이 우리 서비스에 대한 주인 의식을 가지고 있다는 점이 좋았다.

주노와 클린과도 퇴근길에 이야기 했던 부분인데, 우리 서비스를 반드시 구현하겠다는 욕심히 생긴다고 했다.

열정있는 팀원들과 함께하고 있다는 점이 스스로 더 동기부여가 되고 열정을 갖게 되는 것 같다.

 

벌써 레벨 3의 1/4이 지났다.

 

다음 주 부터는 본격적인 개발을 시작할 것 같고, 부족한 개인 공부도 함께 병행할 것 같다.

시간이 제한적이고 체력도 제한적인 만큼 시간 분배를 잘 해야겠다.