팀 프로젝트 회고
최초의 목표 달성
아이디어 회의부터 기획, 설계 개발, QA, 배포 까지 총 12주 소요 되었다. 성공적이었다. 우리의 목표는 계획된 시간 안에 배포하는 것 이었고, 최초 계획된 대로 12주 안에 진행해서 스토어에 배포까지 했기 만족한다.
리더의 시행착오
이번에 프로젝트 전체를 조율을 하고 총 책임자로서 역할을 수행했다. 생각보다 어려운점이 많았고, 시간도 많이 할애할 수 밖에 없었다. 첫 번째, 팀원 들이 작업할 수 있는 그라운드를 만들어주는 것이 손이 많이 갔다. 팀원의 입장에서 당장 이번 주에 무엇을 해야 하는지 명확하지 않으면, 동기부여가 떨어질 수 있다. 이를 방지 하기 위해 매주 방향성에 대한 메시지를 전달해줘야 하고 로드맵을 가지고 있어야 한다. 또한 팀원 간의 소통이 원할하게 이뤄질 수 있도록 환경을 세팅하는 것 또한 생각보다 시간 소모가 많았다.
관찰하는 것에 고충. 각각의 팀원이 프로젝트에 대한 만족도는 어떤지, 혹은 문제점이 있다면 그것이 무엇인지 인지하기가 쉽지 않았다. 그나마 백엔드 쪽은 내가 개발을 참여하기 때문에 전반적인 분위기를 조금 더 잘 캐치할 수 있었지만, 프론트 엔드 상황은 잘 파악하지 못했다. 이럴때면 오히려 내가 개발을 참여하지 않고 조금더 관리적인 측면에 시간을 더 쏟았으면 어땠을까라는 생각이 들곤했다.
문제해결에 집중
프로젝트를 진행하다보면 누군가의 실수, 잘못에 의해 문제가 생기는 일이 종종 발생한다. 순간적으로 왜그랬느냐며 따지고 싶고, 책임을 추궁하려는 마음이 생긴다. 하지만 이러한 행동을 했을 때, 달라지는건 크게 없다. 감정소비만 있을 수 있다. 누구나 실수 할 수 있기 때문에 잘못을 따지는 것이 아닌 문제 해결에 집중했다. 그래서 지금 그 상황을 해결해 나가기 위한 최적의 방법은 무엇인가를 생각했다. 팀원들간의 문제가 발생하여도 이러한 점을 강조했다. 솔직하게 피드백을 하고 과거에 목메지 말고 미래를 생각하자. 우리가 처음부터 잘하는 사람이면 이러한 프로젝트를 시작도 하지 않았을 것이다. 우리는 분명 각자가 부족한 점을 가지고 있고, 이 프로젝트를 통해 하나하나 시행착오를 겪으면서 배우려고 하는 것이다. 본래의 취지가 이 프로젝트를 사업을 하려는 것이 아닌 학습의 목적이 강했다. 갈등이 발생하면 이를 해결하면서 성장하는바가 크기 때문에 이러한 점을 강조하기도 했다. 이러한 점은 내스스로 잘 이끌었다고 생각한다.
선택과 집중이 필요
프로젝트 중반에 들어 섰을때, 프로젝트의 집중하지 못하는 분위기가 느껴졌다. 어느 순간 의무적으로 한다는 것이 느껴지기도 했다. 프로젝트에 대한 회의감이 들거나, 혹은 참여하지 못하는 상황이 길어지는 경우도 발생했다. 이 경우 사실 내가 먼저 참여하지 않아도 괜찮다고 제안을 해도 좋았을 거라는 생각이 들었다. 억지로 프로젝트를 계속 진행하는 것은 결과적으로 봤을 떄 본인이나 다른 팀원이나 그렇게 도움이 되지 않기 떄문이다. 이러한 점은 서로 눈치가 보이고, 개인적으로 친분이 있었기 떄문에 누구도 쉽게 말을 꺼내지 못했다고 생각한다. 조금도 냉철하게 생각하고 판단했다면, 서로에게 더 좋은 결과를 낳았을 거라고 본다. 프로젝트에 빠지는 인원은 자신이 집중하고자 하는 다른 일에 더 집중을 할 수 있고, 신경쓰지 않아도 되기 때문에 오히려 홀가분하고, 다름 팀원도 더이상 기대를 하지 않아도 되기 때문에 앞으로의 계획을 더 예상가능 하게 세울수 있다. 프로젝트가 난이도 자체가 그렇게 헤비 하지 않았기 떄문에,
효율의 함정
너무 시간적인 효율만을 생각했다. 모두가 개발자이다 보니 가장 효율을 높일 수 있는 방법을 생각했던것 같다. 그래서 개발도 모두 각자의 환경에서 하였고, 리뷰도 대면보다는 온라인 화상회의로 모두 대체 했었다. 이동하는 시간을 최소화 하고, 개발할 수 있는 시간을 최대한 더 활용하려는 취지였다. 하지만 이러한 시간적인 효율도 중요하지만, 무엇보다도 이렇게 같이 무언가를 할때는 기세, 분위기도 중요하다. 이는 사실 온라인에서는 채워질 수 없는 부분이다. 그래서 매주 진행했던 온라인 방식의 리뷰와 각자 분리된 개발 공간은 이러한 한계점을 여실이 드러냈다. 마지막에 QA는 시간이 되는 멤버끼리 모여서 진행했는데, 이때 이슈 대응도 빨랐고, 무엇보다 분위기가 우리 어떻게든 이거 끝내자 마무리 해보자, 잘해보자는 분위기가 있어 더 시너지를 낼 수가 있었다.
문서화의 중요성
문서화의 중요성을 인지하고 처음부터 신경을 썼던 부분이다. 그럼에도 불구하고 잘 지켜지지 않았던 부분이 있었다. 특정 중요사항에 대해서 빠뜨렸다던지, 문서의 맥락이 다르다던지 규칙이 다르다든지의 문제다. 설계에 대한 최종 문서화는 한명이 작성하거나 혹은 같이 협의를 한 후에 최종 문서를 만들어야 전체적인 톤을 맞춰나갈 수 있다. 이러한 부분을 각 멤버에게 일정부분을 할당 하니 전체적인 문서가 매끄럽게 되지 않았고, 문서의 규칙이 흐틀어지는 현상이 발견되었다. 예를 들어 A라는 팀원은 유저의 닉네임을 'strUserName' 이라고 쓰고, B라는 팀원은 'strNickName' 이라고 적는 현상이 있다. 물론 별거 아닐수는 있지만, 나중에 개발을 할 때 이러한 사소한 단어의 차이로 인해 문제가 발생할 수 있기 떄문에 이러한 부분은 규칙적으로 가는게 편하다. 따라서 이러한 조율을 할 수 있는 공간이 필요했다.
플랫폼 선택 미스
개발 일정과 학습에 대한 목적성만을 생각하고 프론트엔드는 안드로이드 앱만을 개발 했다. 하지만 서비스에 조금만 더 고민했다면 안드로이드, iOS 모두 개발이 되어야 했다. 왜냐하면, 술자리에서 게임을 하려고 하는데 누군가는 iOS일테고, 누군가는 안드로이드인 상황이 있을 것이다. 그렇다고 iOS 인 사람을 뺴고 게임을 하는 경우는 드물 것이다. 아무리 학습적인 면을 고려했다고 해도 이러한 점은 사실 선택 미스다. 내부에 React Native 개발을 할줄 아는 사람이 2명이 있었기 떄문에 다른 선택을 했을 수도 있지만, 프로젝트 시작단에서 미쳐 고려하지 못했다.
