프로젝트를 통해 학습하고 싶은 기술들이 있었는데, 마침 GDSC에서 프로젝트 할 인원들을 모집하길래 좋은 기회라고 생각했다.
어쩌다보니 팀장..?
프로젝트 신청할 때 팀장으로 지원할 지 팀원으로 지원할 지 선택할 수 있었는데, 팀장은 할 일이 많을것 같았고, 지금 공부할게 너무 많았기에 팀원으로 지원했다. 귀찮음도 한 몫 했다는 점...
팀장이 프로젝트 모집글을 올리는 구조였는데, 며칠이 지나도 프로젝트 모집글이 하나밖에 올라오지 않았다.
내가 프로젝트를 하고싶었던 이유는 기술적인 도전을 하고 싶었다.
이전 프로젝트를 하면서 배운점도 많았지만, 아쉬운 점도 많았다. 그리고 두 번째 프로젝트를 끝내고는 성장했는지에 대한 의문점도 많았다. 그렇기에 도전하고 성장할 수 있는 작업을 하고 싶었다.
RXSwift나 Combine을 학습하고 적용하고 싶었다. 또한 CI/CD, 애자일 방법론을 적용하며 체계적으로 프로젝트를 진행하고 싶었다.
이를 위해서는 '대충 이정도까지'만 하는 사람들이 아닌, 열정이 있는 사람들이 필요했다. 그런데 이대로라면 랜덤으로 팀이 정해지고, 내가 원하는 프로젝트를 하지 못할 가능성도 있었다...ㅠ
나는 친해진 사람들과는 잘 지내지만, 모르는 사람들과의 만남을 힘들어 하는 타입이라... 걱정도 많았고, 고민도 많았다.
'만약 내가 팀 빌딩부터 프로젝트 마감까지 이끌어본다면 이를 극복할 수 있지 않을까?' 라는 생각과 '내가 원하는게 명확하다면 내가 팀장을 하는게 맞지 않을까?'라는 생각에 팀원 모집글을 올리기로 마음 먹었다.
팀원 모집글을 올리다..!
가장 큰 걱정은 '아무도 지원하지 않으면 어떡하지?'라는 생각이었다.
동아리 내에 프로젝트 할 의향이 있는 iOS 인원은 나 포함 두 명이었으나 백엔드 팀원을 구할 수 있을지 걱정이었다.
동아리에 아는 사람들이 많이 없었기에 모집 글에서 나에 대해, 원하는 프로젝트에 대해 설명하는 것이 중요하다고 생각했다.
'내가 만약 팀원으로 지원한다면 어떤 공고 글에 지원하고 싶을까?'에 대해서 고민을 했다.
내가 생각했을 때 지원이 망설여지는 이유는
1. 사람들이 나랑 맞을까?(성격이나 열정 등)
2. 내가 프로젝트 하는 목적과 이 팀의 방향성이 일치할까?
였다.
막상 글을 작성하려하니 너무 어려웠다. 참고할 자료들을 찾아보던 중, 이 블로그에서 도움을 많이 받게 되었다..! 사실 이 분은 네부캠 지원할 때도 정말 많은 도움을 받았는데, 이번에도 도움을 받게되었다.. 또한 프로젝트 관련된 문서화가 너무 잘 되어 있어 다른 많은 부분에서 인사이트를 얻을 수 있었다.(항상 건강하시고 행복하세요ㅠ)
나도 나는 어떤사람인지, 지향점등을 위주로 작성하였고 긴장되는 마음으로 모집글을 올렸다.
그 결과... 정말 감사하게도 모집 공고 중 지원율이 1등이었다...ㅎ
구체적인 방향을 정하기!
전체적인 개발 팀의 팀장을 맡은건 처음이라 너무 막막했다.
일정 관리, 기획, 협업 등 할 일은 많았지만 어떻게 할 지는 전혀 생각이 나지 않았다...
성공적인 사이드 프로젝트를 위한 팀 빌딩과 문제 해결 가이드
자료를 찾아보던 중 인프런에서 아주 좋은 무료 강의를 보게 되었고, 정말 많은 인사이트를 얻었다.
나에게 물어볼 질문
나의 목적과 목표
나의 목적은 기술적 도전, 체계적인 협업의 경험이었다.
- 새로운 라이브러리/프레임워크 사용하며 학습하기(RXSwift, Combine)
- MVVM 적용하며 공부해보기
- 테스트 적용해보기
- CI/CD 적용해보기
- 애자일 방법론을 도입하여 일정 관리, 효율적인 협업 진행하기
사실 위의 내용들은 팀원들에게 추가적인 학습을 요구하기에, 거부감이 들 수도 있었다. 따라서 팀원들을 설득할 필요가 있었다. 기술적인 부분은 쉽게 납득할 수 있지만, 애자일 방법론을 적용하는 것은 '굳이 왜 하는거지?'라는 생각이 들 수도 있었다.
그러나 나도 위의 작업들이 좋다는 것은 알지만 정확히 왜 필요한지에 대해서는 설명할 수 없었다.
따라서 애자일 방법론과 관련해서 팀원들을 설득하는 것이 우선이라고 생각하였고, 이전 프로젝트에서 느꼈던 감정과 불편했던 점들을 생각해보았다.
- 일정 관리: 팀원들간 어떤 작업을 하고 있는지 파악하지 못했고, 매번 물어보기도 쪼으는 것 같아 망설여졌다.
- 팀원들 간의 의지 차이: 열심히 하는 사람, 적당히만 하는 사람, 열심히 안하는 사람이 있었다. 그러나 열심히 안하는 사람이 무조건 나쁜 사람은 아니었다. 다른 일도 많아 프로젝트에 소홀해질 수 밖에 없는 경우도 있었다.
- 팀원들 간의 이해도 차이: 대학교 동아리를 통해 팀 빌딩을 하게 되었을 때 가장 큰 문제였다. 기간은 정해져 있고, 개발을 처음하는 사람들도 있었기에 고민이 정말 많았다.
- 예전에 고민하고 해결했던 문제를 다시 해결하지 못함: 정말 자주 겪었던 문제이다. 또한 새로운 기술을 적용하면서 공부를 많이 했지만, 기록으로 남겨둔게 없어 다음번에 복기하는데 오랜 시간이 걸린 경험도 있었다.
- 팀원의 작업 내용을 파악하기 힘듦: 다른 팀원이 PR을 올려도 코드 이해가 잘 안되어 리뷰를 제대로 하지 못했다. PR도 작업 내용을 기록하는 문서로 잘 활용한다면 좋을 것 같았다. 코드리뷰 - 같이 성장하기 위한, 그리고 성공하기 위한 팀이 되기 위한 도구(김우성) 참고!
따라서 위 사례를 들어 백로그 작성, 문서화, 스프린트 방법, 페어 프로그래밍을 팀원들에게 적용하면 좋을 것 같다고 생각했다.
첫 회의 때 안건이 많고, 시간이 생각보다 오래 걸려 위 내용에 대해서 말을 못했다. 따라서 팀 노션에 문서화와 애자일 방법론 도입을 제안하는 이유에 대해 작성하여 팀원들에게 공유했다.
진행 방향 제안
팀원들 대부분이 납득을 하게되었고, 감사하게도 나의 목표들을 팀의 목표로 옮길 수 있었다!
앞으로는?
현재는 기획을 구체화하는 단계이다. 한 팀원분이 급하게 진행하는 것 보다 기획과 설계에 시간을 더 투자하는게 좋을 것 같다라고 제안해주셨다. 이전 프로젝트를 설계없이 진행했는데, 팀원들과 개발 속도 맞추기도 힘들었고, 초기 단계에 잡을 수 있는 변수들이 너무 많았기에 많은 공감이 되었다.
마무리
얼떨결에 팀장을 맡아 팀빌딩을 진행하게 되었다. 주도적으로 팀을 이끌고 소통할 수 있어 좋은 경험이 되었고, 앞으로도 더 많은 것을 배울 수 있을 것 같다. 아직 진행은 많이 안되었음에도 불구하고, 매번 회의 전에 많은 고민을 하여 쓸 말이 많았던 것 같다...!
