협업) 팀프로젝트 회고
팀원들과 개선 및 개발 과정에서의 중요성
회고 요약
- 명확한 커뮤니케이션이 중요하다
- 작업현황을 관리하면 좋다
- 제한 사항이 많을 경우엔 선기능 후개발 지향
- 빠른 학습성장의 필요성
프로젝트 목표는 텍스트를 활용한 RPG 게임 제작을 하는 것뉴비 개발자과의 팀플
처음으로 하나의 목표를 위해 6명의 뉴비들이 일주일 간 머리를 맞대며 프로젝트를 진행했다
프로젝트 목표는 텍스트를 활용한 RPG 게임 제작을 하는 것이었으며
예시와 같은 구조로 C++과 VS도구로 기능을 구현하는 것이 조건이었다
협업) 그래서 우린 어떻게 만들었나?�
사실 우리 팀은…
2명을 제외한 나머지 4명(필자포함)은 기본 학습도가 매우 더딘 상황이었다
모두가 제로베이스로 시작한 비전공자이었기에 누군가의 하드캐리도 기대할 수 없었다
심지어 진짜 뭘 어떻게 시작해야 할지 아무도 감을 잡지 못했다
그렇기 때문에 필자는 우리가 당장 할 수 있는 것들에 집중하기를 권장하였고
서로 팀원에게 어떤 역량을 기대할 수 있을지를 먼저 공유한 뒤
주어진 환경에서 어떤 게임을 만들 수 있을까란 고민을 할 수 있었다
이런 방식으로 각자의 의견을 수렴 하다보니
현 우리팀의 상황과 조건을 인지할 수 있었고, 그 바탕으로 다음 플랜을 세울 수 있었다
작업에 대한 To do list가 부여되니, 자신이 어떤 점에 집중해야 하는가를 쉽게 알 수 있었고
잘 모르는 부분은 추후에 시도해야 되는 영역으로 분배 할 수 있었다
그렇게 작업기간도 제출 날짜에 이틀 앞당겨
최대한 15일 날에 기능을 완수하기로 약속하고
각자 작업한 것을 정해진 시간마다 공유하고, 다음 플랜을 설정하는 방식으로 작업을 진행했다
협업) 작업이 잘 진행되었는가�
초기에는 진행이 잘되는가 싶었지만
기술적인 어려움이 생길 때마다 조금씩 균형을 잃어갔다
결국 이틀 앞당긴 듀레이트 기간까지 맞추지 못하고
데모데이까지 오버 된 컨디션으로 제출하게 되었다
왜...뭐 때문에..
그에 대한 원인들을 분석하자면
먼저 잘 아는 부분에 대해서 집중하고 시작하는 것까진 좋았으나
특정 작업에 마침표가 도달했음에도, 이어서 그 작업에만 몰두하게 되어
잘 모르는 부분, 즉 시도해야 되는 영역의 시간점유율이 줄어든 것이다
우리팀은 기초학습이 약한 사람이 다수였기 때문에
간단한 기능 구현 또한 시도영역에 속해있었다
그렇기 때문에 기본학습에 대한 시간을 별도로 확보한 뒤, 기능 구현에 대한 작업을 보완했어야 했는데
아무도 이러한 문제점에 대해 해결책과 요구하는 사람이 없어서
구현하는 작업 분배가 균등하게 이루어지지 않았다
결국 메인 코드를 담당했던 한 팀원이, 많은 분량의 코드를 작성해야 했으며
그로인해 물리적인 시간 때문에 딜레이가 생기게 된 것이었다
딜레이 이슈�
딜레이 이슈에 좀 더 자세한 이야기를 풀자면
기획자가 설정한 스토리, 아이템, 확률, 컨셉 등
게임 제작함에 있어서 기능 구현이 아닌, 게임 배경을 의미하는 스토리 설정에서
많은 수정요청과 디벨롭하는 과정이 있었다
게임 스토리에 필요 이상으로 힘을 쏟아낸 것
그로인해 기능 구현에 집중하는 시간이 줄게 된 것인데
물론 이 과정은 미스 커뮤니케이션으로 생긴 이유가 가장 컸었다
작업 전, 기획자가 의도한 것과 작업자가 이해하는 포인트가 달랐기 때문에
작업을 끝마치고 나서야, 결과물에 잘못되었음을 서로가 인지하게 된 것이다
- 결국 이러한 문제점은 회의록에 명확히 기재하지 않은 점에서 비롯되기도 한다
-> 더불어 작업자가 이해한 부분이 맞는지 기획자에게 리체크하는 질문이 부족 했었다고 느낀다
그렇게 생겨난 오류들을 최대한 빠르게 해결하며
가까스로 게임 배경 작업을 마무리할 수 있었다
그로인해 사전작업(게임배경)이 늦다보니
어쩔 수 없이 후반작업(기능구현)은 더욱 촉박하게 진행할 수 밖에 없었다
그래서 팀원 모두가 새벽 2시까지 zepp에 남아, 구현하는 것을 기다리며 시간을 보냈다
메인코드를 담당했던 한 팀원이 마무리 작업을 이어갔으며, 그것이 끝 마치기를 모두가 의리상 기다린 것
필자의 생각
지금 작성하면서 드는 생각은
제한된 시간과, 제한된 능력을 고려했을 때
몇가지 포기해야 하는 점들을 결정하고 진행했으면 어땠을까 싶은 생각이 들기도 한다
게임 퀄리티를 놓치고 싶지 않은 마음은 공감하지만
과연 우리가 집중한 파트에서 퀄리티를 올리는 것이 합리적인가 싶은 의문이 있었다
하지만 필자는 새로운 의견을 제시하기 보단, 그저 배움의 영역으로 인식하고 받아들였다
개인적으로 기능을 구현하는 것에 조금 더 초점을 맞췄더라면 더 좋았겠지만
어찌됐든 게임 개발자가 되려면, 기능구현뿐만 아니라
재미포인트 또한 알고 있어야 한다는 관점으로 받아들였다
그래서 필자가 경험한 이번 프로젝트는
꼭 배운것을 활용하여 기능을 구현시키는 미션만이 아닌
주어진 협업환경에서 어떻게하면 목표를 용이하게 달성할 수 있을지에 대한 개념과
게임에 풍미를 더해 줄 스토리를 어떻게 하면 재미를 향상 시킬 수 있는가를 고민해보는 시간이라 느낀다
프로젝트를 통해 나는 무엇을 배웠는가?
1. 커뮤니케이션의 중요성
서로가 이해한 것을 반드시 일치할 수 있게 반드시 싱크를 맞추고 작업을 진행하는 것이 중요하다
→ 이해가 되지 않았다면, 주저하지 말고 이해될 때까지 질문을 푸쉬하는 것
귀찮더라도 소통한 내용은 꼭 문서화로 전환하여 내용을 정의할 것
→ 작업내용이 피봇되지 않기 위함과 모두가 리마인드 할 수 있는 장치
2. 작업현황 관리의 중요성 Status
누가 얼마나 진행했으며, 직관적으로 모니터하여 실시간으로 피드백하기 용이한 환경을 만들자
→ 작업의 진척이 얼마나 진행되었는지를 확인하기 위해, 직관적으로 식별하는 템플릿을 구축하여 빠르게 팔로업 할 수 있는 환경을 만들자
3. 선 기능 후 개발
리소스가 제한적일 경우 최소 형태로 빠르게 구현한 뒤, 디벨롭을 야기하는 것
→ 초기부터 맥시멈을 생각하는 것이 아니라 최소 기능 제품(MVP)을 구현하고, 추가 기능을 구현하는 것
4. 빠른 학습성장의 필요성
학습에 대한 이해도가 낮으면, 아무래도 선택지가 제한적이고, 시도적인 경험은 한정적이게 된다
마치며
처음에는 그저 막막하고, 과연 우리가 시간내 맞춰서 마무리를 지을 수 있을지에 대한 불안감은 상당히 컸었지만, 최대한 팀원간 소통을 통해 해결책을 생각하고 개개인의 힘을 합하는 시간이었다.
충분히 우리가 할 수 있는 부분에선 최대한 노력을 기여했기 때문에 이런 작은 경험이 결코 가볍지 않았고, 팀원 모두가 잘하고싶은 마음이 강했기 때문에 지금처럼 좋은 인사이트를 얻는 경험을 할 수 있었다
앞으로 또 이와같은 프로젝트를 경험하게 된다면, 같은 실수는 일어나지 않게 보완하고, 새로운 인사이트를 얻기 위해 더 많은 실험정신을 다지고 싶다.