코드스테이츠 [회고 : final project를 끝내고 ]

final project.. 끝이 났네..

내가만든 사이트 "근의공식"

 

 

드디어 파이널 프로젝트가 끝이 났다. 정말 시원섭섭한 기분이 든다. 정말 중간에는 이게 시간이 왜 이렇게 빨리 가지 싶었다. 4인이라는 사람들이 각자의 생각을 섞는 과정이므로 정말 우여곡절이 많았고 얻은 것도 많았다.

 

 

 

프로젝트를 시작하며..

 시작할 때부터 팀원을 어떻게 짜야 할지를 고민하였습니다.

기존의 팀원을 그대로 가야 할지 아니면 랜덤하게 해체해서 팀원을 이루지 못하신 분들을 모아서 프로젝트를 진행할지부터 고민이 많았습니다. 사실 퍼스트 프로젝트를 같이한 팀원분들은 의견 충돌도 없이 잘 진행이 되었고 큰 트러블 없이 진행하였기에 그대로 진행하고 싶었지만, 팀원 한 명의 코드 숙련도가 아주 낮았고 그때는 2주라 어떻게 되겠지만 4주면 구멍이 더욱 크게 느껴지리라고 생각하였습니다. 그럼에도 만약 해체하고 새로운 사람들을 만난다면 운이 좋다면 더 실력이 좋고 성격이 좋은 사람들을 만날 수 있지만 높은 확률로 그렇지 않을 것 같다는 생각하였습니다. 이미 잘하시는 분들은 모여서 팀을 이뤘고 나머지 분은 전의 팀원이 조금이라도 괜찮았으면 그대로 파이널도 진행한다는 내용을 다른 분들에게 들었습니다. 그래서 분위기는 좋게 진행을 할 수 있다는 마음으로 기존의 팀원과 시작하였습니다.

 

 

문제의 발생

 프로젝트를 진행하는 중간에는 4명 중에 한 분의 아쉬움은 생각보다 큰 문제가 발생하였습니다.

팀원분의 스트레스와 일의 분배 문제가 발생하였는데요. 심리적으로 아무도 뭐라고 하지 않았는데 그분도 눈치가 조금 보이고 미안해하시고 또 일을 분배할 때 너무 대놓고 일을 조금주거나 일이 반복되거나 할 수 없었기 때문에 task 분배를 프론트와 백으로 2개로 대충 나누었더니 같은 포지션의 팀원이 일의 과중을 토로하였습니다. 나중에 들어본 결과 디자인을 맞추어야 했기 때문에 토의하고 했던 일을 반려하고 다시 작업 하는 것 때문에 일어난 일이었습니다. 말 그대로 일이 늘어나고 있었습니다. 

해결방안

 그래서 일단 해결점은 제가 client 쪽으로 가서 작업을 돕는 것입니다.

그때 당시에 백엔드는 CRUD 엔드포인트와 엔티티와의 관계는 끝났고 정리만을 남겨둔 상태였기 때문에 제가 client로 가서 몇몇 페이지 부분을 작업하기로 하였습니다.

배운점

 여기서 제가 배운 것은 task의 분배와 타임 리미트를 정해야 한다는 것입니다.

처음에 task를 나눌 때 큰 파트별로 나누고 추가로 시간을 조금 더 들여서 세부 파트로 나누는 방식으로 하여서 

이번 주에는 어디까지. 다음 주에는 어디까지 하는 것을 각 주간 마지막에 분명히 하여야 하고 일의 능력에 따라서 일을 배치하여 일을 여러 번 진행하는 것을 막았어야 했다고 생각합니다.

 

갈등의 발생

 프로젝트를 진행하는 중간에는 갈등이라는 것이 거의 없었는데 아이디어의 부분에서 차이가 생기는 부분이 좀 있었습니다. 디자인적인 사소한 부분에서 사이트의 중요 기능중 하나인 순위에 대한 기준을 정할 때 등의 부분에서 의견 차이가 발생하였습니다. 

단순한 디자인의 의견 차이는 취향의 문제이므로 다수결과 사다리 타기를 통한 결정을 내었고

중요한 아이디어는 단순히 사다리 타기로 해결이 되면 안된다고 생각을 하였습니다.

갈등해결

 이러한 갈등은 프로젝트를 좀더 잘만들고 싶다는 갈망에서 만들어졌다고 생각하기 때문에 각 의견에 따른 장단점을 파악한후 가장 "유저의 입장에서 가장 좋을 것"이 무엇인가를 위주로 생각하여서 토의를 통해 모두가 선택하는 방법으로 해결하였습니다. 

첫번째 의견: 운동시간을 통해 순위를 매기자
 - 장점 : 운동을 좀더 많이 하고자하는 열정을 얻을 수 있음
 - 단점 : 거짓말로 순위를 쟁탈하려는 사람이 생길 수 있음

두번째 의견: 다른사람의 좋아요를 순위로 매기자 
 - 장점 : 운동시간이 적은 처음 하는 사람도 순위에 오를 수 있음
 - 단점 : 운동을 하지않고 좋아요만 원하는 본래의 목적에 벗어날수 있음

였습니다.

그래서 다른사람의 좋아요의 단점은 사이트의 본질을 흐릴 수 있다고 생각을 하였고 다른 팀원들도 동의를하였기에 의견갈등을 해결할 수 있었습니다.

배운점

 여기서 제가 배운것은 이런 프로젝트에서 갈등이 생기는 이유는 프로젝트에 애정이 있고 좀더 잘 만들고 싶었기 때문에 갈등 충돌이 발생한다고 생각합니다. 그래서 장단점을 비교하여서 어떤 의견이 프로젝트에 더 적합한가를 정한다면 프로젝트도 더 좋아지고 갈등도 해결하는 좋은 방법이라고 느꼈습니다.

 

아쉬운점

 추가적인 아쉬움은 git과 github를 제대로 이용하지 못했다는 것입니다. 시작할때는 PR규칙이나 Commit규칙 등을 정했는데 실제로는 제대로 사용하지 않았던것 같고 branch를 나누는 것도 좀더 세부적으로 나누었으면 좋았겠지만 그렇지 못했다는 생각이 자주 들었습니다.

두번째는 추가적인 기능들을 많이 넣지 못했다는 것입니다. 원래는 socket.io나 지도API를 이용하여 추가적인 기능들을 작성하려고 하였는데 여러 이유로 하지 못했다는 아쉬움이 있었습니다.

 

다음에 사이드프로젝트를 할때는 이러한 아쉬움들을 채울수 있었으면 좋겠다는 생각을 해보았습니다.

 

소감

엄청 크지는 않지만 어느정도 사이드 프로젝트를 진행하는 방법을 알게되어서 좋았고 계속해서 다른 사이드프로젝트도 진행을 해보고 싶다.

 

 

 

---

프로젝트명 : 근의공식(MuscleFormula)

설명 : 운동인을 위한 운동 기록 공유 기록 커뮤니티 사이트

기간 : 2022.03.14 ~ 2022.04.10

코드스테이츠 파이널 프로젝트 (4인 / 4주)

GItHub : https://github.com/codestates/MuscleFormula

배포 : www.muscleformula.xyz/