회고

redux를 사용한 첫 팀 프로젝트이다. 이제는 시작단계가 부드럽다.

가장 먼저 아이디어 회의!!
이 부분은 팀원 중 한 분이 생각해두신 아이디어가 있어서 바로 채택했고, 피드백을 거쳐 목적과 필요한 기능을 정렬했다.
작업하면서 필요한 기능은 추가하고 합칠 수 있는 기능은 합치며 진행하기로 했다.

회의 내용을 토대로 이제는 와이어 프레임을 짰다.
노션에서 API 설계와 함께 진행했는데,
디자인에 능숙하신 분이 와이어프레임을 너무 완벽하게 만들어 주셔서 무엇을 어떻게 만들어야할지 한눈에 확 들어왔다. 그것을 토대로 각 페이지를 나누고 페이지별로 필요한 API설계도 순조롭게 진행됐다.

그리고 마지막으로 컴포넌트(파일)별로 각자 파트를 나눴는데, 이 부분이 조금 아쉬웠다.
이전 프로젝트도 그랬지만 초보 입장에서 파트나누는 것이 가장 어려웠다.
어느 부분이 겹치게되고 어느부분이 독립적으로 짤 수 있는가에 대한 이해도가 떨어지다보니, 효율적 배분이 되지않았다. 컴포넌트 별로 나누면 해결될 것 같았지만, react - redux 리팩토링하는 과정에서 겹치는 부분이 많이 발생했고 결국 겹쳐서 함께하는 작업이 많아졌다.

아직 프로젝트가 끝나진 않았지만 각자 맡은 부분을 잘 해결하고 부족한 부분은 동료들이 메꿔주며 잘 해결해 가는 중이다. 프로젝트를 진행하며 소통을 많이했는데 장점은, 진행 방향과 속도를 계속해서 체크하고 도움을 줄 수 있었다는 점이다.
하지만, 특정 동료에게 작업량이 많아지면 부담이 되고 불만도 쌓일 수 있다. 소통을 하다보면 그런 부분을 어떻게든 덜어주기 위한 방법을 고안하게 되고 그리고 어떤 방식으로든 도움이 된다는 점이다. 그래서 서로 의지하며 작업할 수 있었다.
아무것도 할 수 있는게 없다고 판단해서 끙끙 앓는 것 보다 옆에서 시간이라도 함께 보내며 자료라도 함께 봐주고, 3자 입장에서 피드백 해주는게 좋다는 말이다.

느낀점

와이어프레임의 중요성!!
와이어프레임을 완성본 모습으로 만들어 주셨다. 나는 와이어프레임은 전체적 html뼈대와 기능적 특징만 서술하면 된다고 생각했는데, 완성본의 모습을 피그마로 구현해놓은 것을 보고 생각이 바뀌었다. 완성본으로 만들어 놓으니 무엇을 어떻게 구현해야할지, 어떤 API가 필요한지 더 뚜렷하게 다가왔다. 그래서 노션의 API정리도 수월하게 진행할 수 있었다.

소통
소통은 늘 강조했지만 크게 와닿은 적은 많지 않았다. 물론 늘 도움이 되긴했지만 차라리 혼자 할 때가 더 효율적이었던 부분도 있었기 때문이다. 하지만 효율을 떠나서 팀프로젝트는 함께 발걸음을 맞춰나가야 하는 것이 더 중요하다는 것을 깨달았다. 혼자 효율적으로 앞서나가며 진행해봐야 결국 못쓰게 되는 부분이 많았었는데 (기초 프로젝트에서 느낌)
소통을 많이하게 되니 서로의 파트에서 더 효율적인 UI, UX의 의견들이 나오기도 하고, 내가 짠 코드들이 불필요하게 되는 일이 거의 없었다는게 좋았다.