프로젝트 리더로 도전하기, 와글와글 개발기

👨‍👨‍👧‍👧 Week01. 서로를 알아가기

생각이 많은 사람들

• undefined가 모인 배경에는 ‘근거있는 선택’이 있었다. 주제를 먼저 정한 것이 아니라, 프로젝트에 임하는 마음가짐이 같은 사람들이 모였다.

아이디어가 넘쳤습니다.

• 많은 아이디어가 공유되는 것은 좋았지만 그로인해 너무 많은 아이디어가 회의 시간동안 나뉘어졌고, 기획동안 회의가 샌다는 의견이 팀 내에 공유되었다.
• 역할과 규칙이 꼭 필요했다.

역할과 규칙을 만듭시다.

• 프로젝트 리더로써 프로젝트의 전체 리딩을 맡고, 프론트엔드와 백엔드 각각의 파트 리더를 선정하여 각 파트의 진행 역할을 분리했다. 또한 일정과 문서 기록 담당을 한 명 두어서 프로젝트 전체 리딩에 빈틈이 생기지 않도록 했다.
• 규칙을 정했는데, 규칙이 오버엔지니어링이 되지 않도록 첫주차에는 틀을 정하는데에 중점을 두고 세부사항은 이후에 논의하기로 했다. (규칙에도 근거가 필요합니다.)

개발환경과 코딩 컨벤션을 만듭시다.

• 개발환경, 개발 도구, 코딩 컨벤션, Github 규칙 같은 것들을 정했다. (바빠지면 바빠질수록 뼈져리게 느꼈다.)
• 내가 맡은 부분이 아니더라도, 코드 리뷰를 하여 다양한 분야의 지식 공유를 진행하기로 했다. 근거있는 선택에 모두가 함께하기 위해서였다.

🤼 Week02. 협업에 익숙해지기

파트 분리

• 각자의 영역에 도전하고 싶은 부분들이 많았기 때문에, 백엔드와 프론트엔드를 나누어서 개발했다.
• 프로젝트의 리딩을 함에 있어서 어려워질 것은 알았지만, 어렵다고 포기하기에는 모두 바라는 것이 있었고 거기에 대해서 커뮤니케이션을 핸들링하고 개발에 집중하도록 의사결정의 주도권을 잡아서 보조하는 것이 리더의 역할이라고 생각했다.
• 다만 작은 팀에서 일이 너무 분리되지 않도록, 파트별 기록과 진행 상황 공유를 통해서 서로의 진행상황을 꾸준히 공유하기로 했다.

트러블 슈팅을 정리합시다.

• 팀 프로젝트 기간 동안은 특히 더, 단순한 구현보다는 과정이 더 중요하다고 생각했다.
• 각자의 트러블 슈팅을 정리하면 단순히 코드 리뷰 때 읽을 수 없는 과정을 이해할 수 있다고 생각이 들어서 트러블 슈팅을 정리하기 시작했다.

와글와글 트러블 슈팅

구현보다 의사결정이 중요합니다 : 마무리 스크럼

• 시간이 갈수록 협업은 단순한 개인 개발과는 다른 것이라는 걸 느꼈다. 파트가 분리된 것도 영향을 주었고, 이에 따라 구현보다는 의사결정과 그것의 싱크를 맞추는 것이 정말 필요하다는 생각을 했다.
• 이를 위해 하루가 종료되고, 마무리 스크럼을 진행하기로 결정되었다.
• 데일리 스크럼과 유사하게 하루 동안 어떤 작업이 진행되었는지, 내일을 위해 어떤 작업을 추가로 진행할 것인지 나누어 서로가 어떤 작업을 하고 있는지 공유할 수 있도록 했다.

차량은 생산성을 높여줍니다 : 유머와 여유의 탄생

• 어느 날 게더타운에 고카트가 있다는 것을 알게되었는데, 그 뒤로 카트는 우리팀의 슬리퍼가 되었다.
• 단순히 게임 내의 요소보다는 긴장된 회의가 끝난 이후 서로의 긴장을 푸는 장치가 되어주었고, Week03의 커뮤니케이션 트러블 슈팅의 중요한 도움이 되었다.

기술적인 도전이란 무엇일까?

• 나는 부스트캠프가 시작할 때부터 팀 프로젝트때까지 계속 기술적인 도전에 대해 고민했었다. 단순히 남들이 모르는 기술을 사용하는 것보다는 문제를 나의 힘으로 해결할 수 있는 힘을 기르는게 도전이라고 생각했었다.
• 알고보니 팀원들도 다들 크기가 다르지만, 같은 고민을 가지고 있었다. Week02때부터 팀 내에서 기술적인 도전과 탐구는 무엇인지에 대한 이야기를 나누기 시작했다.

💁 Week03. 컨디션 관리, 유머와 여유 챙기기

컨디션 관리의 중요성

• 3주차가 되자, 컨디션 관리의 중요성이 나타나기 시작했다. 다들 긴장이 많이 되었었고, 긴장감은 판단력을 흐리게 만들었다.
• 이건 팀 일정 관리로는 어려웠으며, 멘탈적인 부분이었기 때문에 많은 고민이 되었다.
• 아침에 일부러 TMI를 나누고 낮잠시간을 만들었다.
• 많은 휴식은 긴장을 풀게 만들지만, 너무 딱딱한 경직감도 마찬가지로 생산성을 저하시킨다.

Wiki 작성

• 시간이 지날수록 작업내용이 공유되지 않았고, 프로젝트 초반부에 작업내용이 공유되지 않으니 기획의 싱크가 많지 않는 경우가 종종 생겼다.
• 기획의 싱크를 맞출 때가 한 번 되었다고 생각했고, 다 같이 Wiki를 쓰자는 제안을 했다.
• 다 같이 Wiki의 내용을 읽으며, 기획에 대한 생각이 다른 부분이 있다면 나누고 싱크를 맞추어 개발 목표를 다시 맞출 수 있었다.

절반에서 돌아보기 : 포스트 모템

• 지난 주에 이어 우리는 충분한 기술적 도전을 하고 있는가에 대해서 나뉘어지기도 했다.
• 그렇게 제대로 가지 못하고 있는 부분에 대해서는 남은 시간을 계산하고, 조금 되돌아가기도 더 나아가야할 부분이 있다면 방향을 다잡으며 오버엔지니어링과 매몰을 경계했다.

📒 Week04. 문서 레이아웃 개선

문서 레이아웃 수정

• 컨디션 관리가 어려워지자, 서로의 문서를 읽기 어려워졌다. 이것을 UX적으로 해결할 수 없는 부분이 없을까 고민해보았다.
• 중요한 문서는 depth를 낮추거나 다단을 사용해서 레이아웃이 한 눈에 들어오게 하는 등의 개선안을 간단히 준비해서 문서의 가독성을 높일 수 있었다.

Github을 더 적극적으로 활용합시다.

• Github의 Issue가 Feature만을 관리하기 위해 사용되고 있었다. Github이 아니라 Git처럼 사용되고 있었다.
• Github을 더 적극적으로 활용하면, 서로의 작업 진행상황을 매번 공유하지 않아도 작업 내용을 이해할 수 있다고 생각되었다.
• 따라 매일 하나의 Issue를 닫고, PR을 날리자는 규칙을 만들었다.
• 그 정도로 작업 단위가 나뉘어지지 않고 있다면, 작업 크기가 너무 크지는 않은지 다시 점검하고 서로의 상태와 트러블을 매일 확인할 수 있게하기 위함이었다.
• 또한 단순히 전달만으로는 휘발될 수 있는 트러블들을 Issue에 문서화하면서 전달하여 의사소통이 원활하도록 했다.

문서로 대화하기

• 프로젝트가 진행되고 커뮤니케이션이 원활해지며 문서만 가지고도 대화를 할 수 있는 것들이 많아졌다.
• 이에 따라 이전까지 있던 워크 플로우에 불필요한 부분을 줄여낼 수 있었다.

의사결정에 대해 다시 알리기

• 단순히 구현에 매몰되면 안된다는 것이 공유되었다.
• 현재 이력서 작성등으로 마음이 조급한 상황에서 피곤해지면, 목적과 우선순위를 잃고 구현에 매몰되기도 하기때문에 낮잠을 자서라도 판단력을 명료하게 만들자는 각오를 다졌다.

🏃‍♀️ Week05. 열심히 달리기

커뮤니케이션 적응

• 5주차가 되니, 다들 협업에 조금 익숙해졌다.
• 이전보다 말하는 것이 줄어도 문서와 Github을 통해서 서로의 맥락을 이해할 수 있었고, 지금까지 쌓아놓은 것들 덕분에 커뮤니케이션 비용이 줄어들었다.
• Github의 브랜치 전략에 대해서도 훨씬 익숙해져서 어느 상황에 conflict를 조심해야하는지, PR과 커밋 단위는 어느정도가 되어야 남이 읽기 좋은지에 대해서도 이해하게 되었다.

컨디션과 멘탈관리, 이력서를 같이 씁시다.

• 문제는 할 일은 많다는 것이었다.
• 프로젝트가 막바지에 이르니 원래 설정해둔 기능 구현 뿐만 아니라 프로젝트 소개와 이력서, 컴퍼니 데이 등 추가적으로 해야할 일이 많았다.
• 프로젝트 소개와 이력서를 백로그의 우선순위 최상으로 설정하여 어떤 기능 우선순위보다도 먼저 처리할 수 있도록하였다.
• 이 과정에서 필요하다면 기능 다이어트도 진행하였다. 개인의 문제더라도 팀이 다 같이 겪고 있다면 팀의 문제라고 생각했다.

🏁 Week06. 유종의 미 거두기

리더로써

• 팀원들이 야근을 많이하는게 보이면 일정과 필요한 구현기능의 우선순위 확인하고 내가 할 수 있는 일을 도와서 낮잠시간을 가지도록 했다.
• 프로젝트가 마무리 되어가며, 피곤함과 조급함과 일정관리의 모호함이 섞이면서 판단력이 흐려지고 감정문제가 생기는 것은 정말 큰 문제라는 판단이었다.
• (나도 옆에서 누가 확인하고 피곤해보이면 일 뺏어간다음 낮잠자고 오라고하면 좋겠다고 생각했다. ‘하지만… 그것이, 리더니까’)