프론트엔드 개발자로서 처음 팀 프로젝트를 진행하면서 프론트엔드 팀원들 뿐만 아니라 백엔드분들과도 소통하며 새로운 기능들을 구현해보는 동시에, 프로젝트 매니저로서 프로젝트 일정 관리 및 멘토님들과의 소통까지 담당하다보니 쉽지는 않았지만 그만큼 많이 성장할 수 있었던 프로젝트였다.
PM으로서의 회고
[GOOD] 기존 일정 관리 방식을 보완하기 위한 GOOGLE SHEETS 양식 도입
팀 프로젝트 일정 관리 툴인 TRELLO로 첫번째 스프린트를 진행하면서 TRELLO만으로는 각 카드별 세부 업무에 대한 진척도를 파악하는데 어려움이 있다고 판단했다. 그래서 첫번째 스프린트 회고 미팅 후 팀원별, 카드별 세부 항목에 대해 확인할 수 있는 구글 시트를 작성하여 추가로 도입하였다.
나에게 할당된 카드 뿐 아니라 다른 팀원들의 진척도도 한번에 확인할 수 있었고, 전체 카드 대비 진척도도 수치화하기 수월해져 데일리 미팅에서나 멘토님과 스프린트 미팅을 진행할 때도 더 명확하게 팀 진행상황에 대해 소통할 수 있었다.
Front-End 개발자로서의 회고
[GOOD] 이번 프로젝트에서는 Carousel, Checkbox 등 새로운 FE 기능을 구현하는 것에서 더 나아가 어디까지 FE에서 구현할지 논의하거나 실제 통신을 진행하는 과정에서 서버 end-point에 맞게 코드를 수정해가는 등 백엔드 팀원들과 소통하는 방법에 대해서도 배울 수 있었다.
예를 들어 실제 통신 전 장바구니 페이지에서 Mock data를 바탕으로 기능을 구현했을 때는 가독성에 초점을 두어 하나의 수식에서 수량 변화(Count component)가 이루어지게 작성했었는데, API 명세서를 확인해보니 실제 증가 및 감소에 대한 End point가 상이한 것을 확인하고 수량 변화에 대한 코드를 전체적으로 수정해야하는 경우가 있었다.
또한 백엔드에서 총 구매 금액에 대한 산출을 FE에서 구현했으면 좋겠다는 요청을 받고 reduce 메서드를 통해 직접 산출하는 경우도 있었다. 이러한 과정을 통해 BE-FE 간의 협업 시에는 다양한 변수가 발생할 수 있어 항상 자세하고 적극적으로 소통하는 프로세스를 경험할 수 있었다.
추후 프로젝트에서의 GOAL
- 이번 프로젝트에서는 일정 내 기능 구현을 완료하는 것에 중점을 두었었는데, 팀원마다 개발 속도나 중점을 두는 부분(디자인 혹은 기능 구현)이 다르다 보니 미팅에서 논의되었던 사항들과 다르게 진행되는 경우가 있었다. 기한 내 프로젝트 완료가 먼저이다 보니 팀원과 상황에 대해 확인하기보다는 직접 추가 구현 페이지를 담당하거나, 레이아웃까지만 작성된 다른 팀원의 코드에 기능 코드를 추가하는 경우도 있었다. 다음 프로젝트 때는 결과에만 집중하기 보다는 좀 더 과정에 대해 생각해보며 프로젝트를 진행할 수 있으면 좋을 것 같았다. 그래서 이번에는 멘토님들의 코드 리뷰를 받기는 했지만 FE 개발자들 간에 peer review를 진행하지 못해 다음에는 기존의 코드에 대한 리팩토링도 동시에 진행될 수 있도록 고민해보고 싶었다.
- 이번 프로젝트에서 느낀 개발자란 : COO님이 개발자는 자기 코드를 지울 수도 있어야 하고, 같이 일하고 싶은 개발자가 되는 것이 중요하다는 말씀을 하셨었는데, 특히나 이번 프로젝트를 진행하며 그 부분에 대한 생각을 많이 하게 되었다. 항상 성장하는 개발자가 되는 동시에 다른 동료들이 같이 일하고 싶은 개발자가 되고 있는가 계속 되돌아봐야겠다고 다짐하게 되었던 프로젝트였다.
