프로젝트의 최종 결과물을 바탕으로 발표를 진행했고, 회고를 진행해보려고 한다.
1. 발표 및 피드백
게임 자체가 사실상 미완성이긴 하지만, 그래도 발표와 성과 발표는 해야할 것이다.
해당 발표를 맡은 건 기획팀장이 하였고 아래와 같이 강사님 피드백 내용을 받을 수 있었다.
요약하자면, 아래와 같은 두 가지로 내용을 요약할 수 있다.
-
구현해야 할 기능의 기술 스택이 간단하지 않았는데, 잘 진행하신 편이다. 하지만 발표 내용에서 해당 내용을 설명하는 부분이 부족했다. 해당 기술을 구성한 방식, 선택 이유, 기대 결과 등을 정리하여 발표하는 것까지 진행해주길 바란다
-
기획자와 프로그래머 사이의 소통이 부족했던 것이 보였다. 버그리포트와 이슈 기록 등의 내용 정리는 잘 되어 있는 것을 확인했다. 하지만 체계와 규칙도 중요하지만 개인적으로든 소통하려는 노력을 하는 게 어땠을까 라는 생각이 든다.
다행히 내용 자체는 잘 봐 준 편이기는 한 것 같다. 하지만 플밍 팀의 기술 스택 설명 부분을 좀 더 상세하게 할 필요가 있다는 사실을 알게 되었다.
2. 회고
2.1 프로그래밍에 대하여
스스로의 프로그래밍 작업(설계·구현 전 과정)에 대한 회고를 진행합니다.
아래 내용을 참고하여 회고를 진행해봅시다.
• 요구사항을 정확히 이해하고 구현하였는가
• 코드 품질(가독성·유지보수성)을 충분히 고려하였는가
• 테스트·디버깅 및 버전 관리 절차를 일관되게 준수하였는가
• 성능, 예외 처리, 문서화 등 비기능 요구사항을 충족하였는가
A)
본인이 담당한 업무는 인벤토리 및 인벤토리와 연계된 다양한 기능 구현이었고, 해당 디자인에 대해 기획팀의 UI 디자인 담당자가 기본적인 틀을 마련해 주었습니다. 해당 UI 디자인에 맞춰 기능 구현을 진행했으며, 코드 컨벤션으로 정한 규칙 중 '영어로 주석을 달 것' 이라는 내용을 준수하며 될 수 있는 많은 부분에 주석을 달고 코드의 사용 방법에 대한 설명을 덧붙였습니다. 또한 코드의 유지보수성을 위해 인벤토리라는 큰 기능의 경우 클래스 다이어그램을 작성하여 해당 내용을 PR과정에서 업로드하여 팀원들이 쉽게 볼 수 있게 정리하였습니다.
테스트와 디버깅의 경우 매 작업마다 메인 씬에서 작업하고 있는 사람을 확인하여 충돌이 일어나지 않게 확인하고, 버그 리포트를 활용하여 실시간으로 피드백과 해결과정을 수행했습니다. 또한 다른 사람의 코드를 고쳐야 하는 경우 해당 팀원에게 요청을 하거나 이렇게 고치겠다고 상황을 공유하면서 진행하였습니다.
UI를 다루는 부분에 대해서 성능 등을 챙기기 위해 Action을 최대한 활용하였고, 작업 효율을 증진시키기 위한 데이터 테이블 변환 작업 등을 진행하여 밸런싱 및 아이템 추가 및 삭제에 대해서 빨리 대응할 수 있도록 하는 노력도 해 보았습니다.
2.2 협업에 대하여
프로젝트의 기본은 협업입니다.
회사에서 사람을 뽑을 때, 가장 중요하게 생각하는 부분은 '함께 일하고 싶은 사람인가'입니다.
특히 신입 기획자에게는 함께 일하고 싶은 사람인지 보여주는 것이 매우 중요합니다.
아래 내용을 참고하며 회고를 진행해봅시다.
• 프로젝트에서 건설적인 대화를 진행하였는가
• 자신의 작업물과 진행 상황을 팀에게 공유하였는가
• 나의 부족한 부분을 부끄러워하지 않고, 남의 부족한 부분을 얕잡아 보지 않았는가
• 프로젝트에 개인적인 감정을 담지 않았는가
A)
인벤토리 담당으로서 작업을 하던 와중에 생긴 버그로 인해 어쩔 수 없이 작업을 처음부터 다시 해야 하는 상황에 놓인 적도 있었습니다. 이 상황에 대해서 면목이 없지만 이런 문제가 생겼다고 팀원에게 해당 내용을 공유했으며, 후에 어떤 조치를 했는지 또한 디스코드를 통해 내용을 남겨놨습니다. 또한 팀장님의 스타일로서 필요할 때 한 명씩 불러서 합치거나 기능에 대해 피드백을 하는 시간을 가졌었는데, 이 부분에서 건설적인 대화를 나누었습니다.
팀장 뿐만 아니라 팀원과 작업을 하는 상황에서도 어떤 식으로 업무 분배를 할지, 연결 과정은 어떻게 진행할지 등의 필요한 대화를 나누었고 혹시나의 상황을 대비하여 같이 합치기 작업을 진행하고 합의를 한 상태로 개발 기능 구현을 했습니다.
감정적인 소모를 할 시간도 없이 너무 바빴기 때문에 개인적인 감정을 담은 대화를 한 적은 없었던 것 같습니다.
2.3 기획자와의 협업에 대하여
이번 프로젝트는 프로그래머와 기획자가 효과적으로 협업을 위한 과정이였습니다.
앞으로도 여러분은 이러한 협업에 가까운 형태로 진행을 하게 될것입니다.
다음 프로젝트와 취업 후 기획자와의 협업을 위하여,
아래 내용을 참고하여 회고를 진행해봅시다.
• 기획서를 충분히 이해하기 위해 기획자와 소통하였는가
• 기획 변경 시 기술적 영향·일정 변화를 기획자에게 명확히 전달하였는가
• 기획자의 피드백을 코드에 반영하며 우선순위를 조율하였는가
• 기획자와 요구사항·제약사항을 효과적으로 합의하였는가
A)
기획자와의 협업 과정이 처음이었다 보니 아무래도 미숙했던 점이 많이 나타났다고 생각합니다.
기획서의 내용은 구글드라이브를 통해 공유되었으며 아무래도 빨리 작업을 들어가든, 기능의 프로토타입을 제작하든지 간에 필요한 기능을 위해 기획서의 내용 공유가 중요했습니다. 다만 기획서가 완성되었다든지, 혹은 변경점이 있었다든지에 대한 소통이 부족하여 일일히 기획서의 내용을 살펴 보고 변동 사항을 확인하거나, 특정 부분을 읽고 의문 사항을 담당자에게 확인하는 과정을 취했다 보니 아무래도 소통과정의 효율성도 떨어지고 변동사항 추적이 어려웠습니다.
비록 초중반에는 이런 이슈가 좀 있었지만, 문제점을 인지하여 변동사항을 꾸준히 공유하고 후반부 작업부터는 원활하게 소통이 진행된 것 같습니다.
2.4 자유로운 한마디
팀 내 이슈, 어려웠던 점, 배운 점, 칭찬, 건의, 근황 토크 등 무엇이든 자유롭게!
A)
이번 프로젝트는 솔직히 말하자면 성공적인 프로젝트라고 말하기는 어려웠던 것 같습니다. 아무래도 기획팀에서의 컨셉 설정 기간이 생각보다 길어져 작업 시작 시기가 늦어졌다는 점과, (물론 미리 공부를 하고 프로토타입을 작업하긴 했지만, 실제로 나온 컨셉이 미리 만들어둔 프로토타입과 전혀 다른 방향으로 나온 경우가 많아 처음부터 만들어야 하는 등의 문제가 발생) 게임의 규모 조절을 계속 하긴 했으나 그럼에도 규모가 커서 플밍 팀의 역량이 해당 기획을 구현할 만큼을 따라가지 못한 문제점 등이 있었다고 생각합니다. 최종적인 결과물이 미흡하게 나온 점이 속상하다고 느끼고 있습니다...
특히나 사적인 감정 없이 최대한 객관적으로 문제를 생각해보고자 한다면, 플밍팀 쪽에서는 거의 개인플레이를 하는 분위기로 가다 보니 서로 구현이 얼마만큼 되어 있는지도 공유가 안 되고, 데일리 스크럼을 써 달라고 부탁했는데 사실 플밍 쪽에서는 저를 포함 두 명 정도밖에 꾸준히 작성을 안 해서 일정 관리 및 구현 상황 추적이 안 되었습니다. 이 결과로서, 특정 (익명)이 맡으셨던 핵심 기능의 구현이 되지 않아 프로젝트 제작에 큰 차질이 생겼습니다. 물론 팀원으로서도 저 또한 상황 공유 및 협업이나 이슈에 관해 이런 소통 이슈가 지속적으로 발생하는 상황에서, 강하게 말하지 못한 것도 잘못이라고 생각하긴 합니다.
이미 프로젝트는 끝이 났고 이번 일은 꽤 씁쓸한 실패 경험으로 남을 것 같습니다. 하지만 이런 실패 경험을 바탕으로 뭐가 부족했는지 스스로에게 질문하고, 소통에 대한 문제 및 작업의 진행 방향에 대해 배우게 되었다고도 생각합니다. 다음 프로젝트 때는 어떻게 성공적으로 프로젝트를 진행할 지 고민해보는 시간을 가지려고 합니다.
