위코드에 들어온지 거의 한달하고 2주가 지나간다.
1차 프로젝트를 진행하면서 어떤 사건들을 겪었는지 쭉 정리해보고 싶다.
PM
내 성격은 누구에게 지시하는것(조언이든 권유든)을 무서워하는 성격이다.
군대에서도 그랬고 지금도 변하지 않았다.
하지만 여기서 팀 프로젝트를 시작할 때 자발적으로 PM을 맡겠다고 했다.
내가 아는게 더 많다고 생각했고, 전체적인 프로세스를 아는 사람이 더 많은 발언권을 가져야 팀이 더 잘 굴러갈 수 있다고 생각했다.
최대한 개개인들의 의견을 물어보고 취합하려 했다.
최대한 팀원들의 성장을 이끌어내면서, 프로젝트의 결과가 꽤 그럴듯 하게 보일 수 있도록 진행했다.
(협업은 단순 연산이 될 수 없다고 생각한다.
5명이 있어도 결과는 1에 가까울 수 있고 25에 가까울 수 있다고 생각한다.
나는 우리팀이 25처럼 될 수 있기를 바란 것 같다.)
결과는 실패한거 같은데(한 6.5?) 일단 그 과정을 쭉 적어보겠다.
시작
팀이 결정되고, 첫 회의를 시작했을 때,
우리는 클론 프로젝트였기 때문에, 기획이나 디자인에 대한 회의는 필요하지 않았다.
하지만 사이트 전체를 2주안에 개발할 순 없었기 때문에, 기능명세서 작성과 같은 작업이 필요하다고 생각했지만, 팀원들의 현재 상태를 생각해서 의도적으로 느슨하게 진행했다.
물론 나는 그런 작업이 디테일 할 수록 좋다는 것을 알고 있었다.
하지만
처음 개발을 시작하고,
처음 프로젝트를 시작하는 사람들에게
하나하나 짚어가며 가는 것 보단 1차프로젝트에선 그냥 다같이 헤딩하면서
이런 명세 작업의 필요성에 대해 스스로 느낄 수 있는 계기가 되어야 한다고 생각했다.
하지만 개개인의 팀원과 얘기를 나눴을 때 그 부분에 대해 얼마나 느꼈는지는 판단하기 어려웠다.
아직도 2차 프로젝트에서는 어떻게 진행해야 할지 막막하지만,
이번엔 최대한 깐깐하게 작업해 보기로 한다.
(다음 2차에선 어떻게 기능 명세서 작업을 진행할 껀지 적어놔야 겠다.)
느슨한 명세서 작성 과정
최대한 팀원 모두가 이해할 수 있는 형태로 느슨하게(스토브 같은 툴을 사용하지 않고, 칠판만 이용하여)
사이트에 구현할 페이지를 대략적으로 정하고
우선순위를 매기고,
각 페이지당 프론트1, 백1로 사람을 분배하고 작업을 시작했다.
여기에 어떤 기능들이 요구되어질지 꼼꼼히 넣으면 될 것 같다.
(프로젝트를 진행하면서 PR로 받은 지적들을 모두 저장해놓고 싶다. 이동욱 개발자의 이야기에서 그런 후배가 좋았다는 말과 정말 그 모든 것이 내것이 된다면 나는 정말 빠르게 성장했다 말할 수 있을 것이다.)
월요일
은 팀원이 발표되고 초기세팅을 진행했으며,
(초기세팅에서 window라 걸렸던 점들, eslint설정, prettier설정 등을 정리해야 겠다)
간단한 회의를 끝내니 저녁 8시30이 되었고,
최대한 집중해서 맡은 페이지의 레이아웃을 절반가량하고 하루를 마쳤다.
화요일
일찍와서 뭘 했는지 모르겠지만, 무언가를 하고
11시가 되자 데일리 미팅을 진행했다.
아직 어제 한 일, 오늘 할 일, 막힌 일에 대한 명확한 구분 없이 진행했으면 그 과정을 따로 기록하지도 않았다.
(이 부분을 멘토님의 언급을 통해, 노션을 통해 기록하고 팀원 전체의 프로세스를 간단한 표 형태로 정리한 것 만으로도 팀원들이 현 상태를 빠르게 파악할 수 있어서 좋았고, 중간중간 내가 다음에 무엇을 해야할 지 참고할 수 있어서 너무 좋았다. 다음에도 무조건 노션을 적극 활용해서 팀원들과의 상태를 간단하면서 명료하게 정리할 수 있도록 해야겠다.)
그렇게
그런식으로 하루하루가 지나갔다.
백은 목요일?까지 거의 데이터 모델링을 하고 멘토님에게 검사받는 시간을 가졌고,
프론트는, 백이 어떤 형태로 데이터를 줄지 모른체 mock데이터를 만들어 페이지를 완성해 가고 있었다.
(이 부분도 다른 팀들과 차이점을 가지는 중요한 점인것 같다. API명세서가 있으면 mock데이터를 만들기도 편하고 실제 붙여볼 때 크게 차이가 나지 않는다는점, 또 백엔드가 서버를 켤 때까지 기자리지 않는다는점이 개발 속도를 굉장히 증진시킬 수 있었던 중요한 부분이었던거 같다. 나중에 발표할 때도 꼭 넣어야 겠다.)
(하지만 이 부분은 나만 잘 활용한것 같고 팀원들도 그렇게 잘 활용했는지는 의문이다. 팀장으로써 그리고 한명의 팀원으로서 공유해야할 부분 그렇게 하지 못한 잘못이 있는 것 같다. 다음에는 데일리 미팅때 이런 기술들을 잘 공유해야 겠다.)
개발하면서 받은 리뷰들
1. CSS Side Effect문제
해당 주에 CSS Side Effect문제, (flex의 사용을 줄이고 margin 0 auto와 자식이 부모의 크기를 정할 수 있게 해야한다 )등의 문제를 지적받았고,
2. react에서 state로 저장할 변수들이란?
리액트 스테이트에 대해 어떤 필요에 의해 state가 생성되어야 하는지(가령 총합이나 개수 같은 부분을 기존의 값들로 계산할 수 있기 때문에 state로 관리되어선 안된다.) 지적 받았다.
3. react 성능 최적화 기술
또 어떤 형태로 컴포넌트를 만들어야 하는지와, shouldComponentUpdate()를 활용해서 react 메모이제이션 기능으로 좀더 컴포넌트 업데이트를 줄일 수 잇는 생각등 많은 것을 얻게 되었다.
(이 메모이제이션은 시간이 없고 생각하는데 빡셀것 같아서 일단 미뤄놨는데 이번 주말에 꼭 해봐야겠다.🔥🔥🔥)
목요일
그렇게 목요일즘 되었을때, 생각보가 하나의 PR(사이트에서 하나의 페이지)도 머지되기가 어렵다는 사실을 깨닫고, 팀원들과 앞으로의 방향에 대해 이야기를 나누게 되었다.
어떤 팀원은 프로젝트가 제 시간안에 다 할 수 있을 지 걱정했고,
어떤 팀원은 이번 프로젝트에서 잘 안해놓으면 다음 프로젝트에서도 동일하게 못할 것 같아 꼼꼼히 하길 바랬다.
대화를 통해 두 답안 모두 우리에겐 필요하다 느꼈고, 한쪽을 택하기 보단, 모두 해야한다 쪽으로 결론이 났던것 같다.
(달라진게 없는 것 같지만, 서로 어떤 고민을 하고 있는지 확인하고 대화를 통해 우리가 앞으로 어떻게 해야할지 같이 고민하고 어느정도의 합의점을 가지려 노력한 점이 앞으로 팀 프로젝트를 진행할 때 대단히 중요한 부분이지 않을까 싶다.)
우리는 멘토님들의 리뷰를 기다리면서, 앞으로 구현되어야만 하는 페이지들을 다시 정리해보고 우선순위를 매기고, 팀원들에게 하나의 페이지씩 더 할당했다.
이 과정이 지금도 가장 고민이 되었던 부분인데,
백엔드 팀원들은 데이터 모델링이 끝나고 빠른 속도로 치고 나오는 반면,
프론트 팀원들은 페이지 레이아웃을 만드는 것 부터, 작은 이벤트를 다는 것(state와 props활용)도 어려워 했기 때문에 부담되는 양이었다.
물론 나도 그부분은 어느정도 알고 있었고, 하지만 그럼에도 이 방향이 성장과 완성도라는 두 마리의 토끼를 잡을 수 있는 방향이라고 생각했다.
두 마리의 토끼는 잡았나?
이 부분은 그럭저럭 괜찮은 방법이었다고 생각한다.
하지만 문제는 다른 부분이었다.
우리 팀의 가장 큰 문제는 소통의 부재였다.
소통의 부족
나름 한다고 했지만, 대화의 내용을 문서화 시키지 않고 진행했지 때문에,
후에 서로 개발한 부분이 다르거나, 진행사항을 파악하기 어려웠다.
이 부분은 어떻게 했어야 했을까.
노션의 테이블을 통해, 각 페이지 별로, 일을 진행했어야 했을 것 같다.
그리고 데일리 회의 내용을 대력적으로 적고 정리하는 시간을 가졌어야 한 것 같다.
정말로 대화를 적게하는 것 보단 힘들어도 많이 하는게 협업에선 확실히 더 좋다고 생각되어 진다.
마지막 발표때에도 문제가 발생했다.
발표 10분 전까지 버그를 고쳐야 했기에 준비를 하지 못했다.
결과적으로 팀원들의 개발 내용을 잘 소개해주지 못했던 것 같다.
정리
배운점.
1. react에서 state란
2. css의 flex사용에 대한 고민, 다른 레이아웃 방법은 없느지.
3. 프로젝트에서 기능 명세작업의 중요성?
4. 소통의 중요성 적은것 보다 많은게 낫다.
그래서? 다음엔?
1. react에서 정말 필요로 하는 state만 뽑아 쓸 것이며(잘할 자신 있다.)
2. flex을 안쓰고 해보려 할 것이며
3. 이번엔 더 타이트하게 팀원들과 해보려 할 것이며
4. 대화의 내용을 기록하거 정리하고 보기쉽게 노션에 표시
