프로젝트 소개
프로젝트와 비슷한 포지션의 비시바시(좌) 컴온 베이비(우)
프로젝트는 베타 릴리즈 상태로 사내에서 잠정 중단 된 상태이다-현재 해당 프로젝트를 진행했던 인원 전원이 다른 프로젝트에 배속, 퇴사 등으로 인하여 팀이 흩어져 있으며, 사실상 프로젝트가 와해되어있는 상황이다.
- 프로젝트: A Project
- 플랫폼: 아케이드 업소용 - 윈도우즈Windows / PC 플랫폼
- 기기: 커스텀 PC / 터치 스크린Touch Screen
- 개발 기간: 2009. 06. ~ 2010. 05. (12 개월)
- 개발 인력: 약 110 M/M (월 평균 약 9 M/M, 최대 인원 Full Time: 9, Part Time: 3)
- 상태: 베타 릴리즈Beta Release / 프로젝트 잠정 중단Hold
잘 된 부분
프로젝트 초창기에는 개발 프로세스라는 형태가 공식적으로 존재하지는 않았다. 나름 게임 개발 업계에서 십 수년간 몸 담은 사람들이 경영진에 포진하고 있고, 마니아 층을 형성한 게임을 제작하고 판매, 온라인 게임 개발 발매도 한 견실한 업체였음에도 불구하고, 프로젝트 관리에 대한 부분은 거의 전무하였으며, 초창기 개발 현장에서 보여지는 주먹구구식 개발 환경이 난립하는 회사 상황에서 팀 내의 개발 프로세스를 확립하는 일은 그리 쉬운 일은 아니었다.
팀 내에 개발 프로세스를 도입 할 때의 팀원들의 저항(그런 것 없이도 우린 잘 해왔는데? 라는 식의 오만)이 있을 것이라 쉽게 예상되었기 때문에, 팀 내에서 뜻을 가지고 있는 프로그램 - 게임 디자인 파트에서 먼저 프로젝트에 필요한 의사소통 라인을 만들었다. 회의 및 개별 면담 후, 개발 문서를 제작 이를 SVN을 이용하여 일괄 배포하였고, 지속적으로 수정하고 재배포 함으로써 개발 중 발생하는 커뮤니케이션 문제를 억제할 수 있는 환경을 만들었다. 그리고 개발 중 발생하는 이슈를 이슈 트래커Issue Tracker인 맨티스Mantis를 이용하여 모든 이슈 사항을 기록하였다.
개발 중 이슈 트래커로 이용한 맨티스
프로세스에 대한 전체적인 관리는 각 개발 파트(게임 디자인, 프로그래밍, 그래픽)의 팀장들이 각 팀원들에 대한 업무 관리를 진행하였다. 이를 뒷받침하기 위한 협업 개발 툴(개발 페이지, SVN,맨티스)에 대하여 별도 관리 담당자를 지정하여 팀원들이 개발 툴을 100% 활용 할 수 있도록 서포트 하였다. 별도로 제작된 개발 페이지에서는 개발 일정, 최신 개발 이슈 현황, 일일 빌드 현황을 개발 팀원 누구라도 손쉽게 확인 할 수 있도록 하였다. 매 주 정기 회의에서는 통계 처리된 업무 진척 상황을 보여줌으로써 객관화 된 프로젝트 진척 상황의 공유가 가능하도록 하였다.
리소스 관리 및 배포
프로젝트 진행 중 발생하는 모든 리소스는 SVNSubversion을 이용하여 관리/배포 하였다-팀 내 SVN을 도입 하기 이전에는 메일과 공유 폴더를 이용하여 리소스가 관리되고 있었다. SVN에서 프로그램 소스 뿐만 아니라 모든 문서, 그래픽 및 사운드 리소스, 심지어 일일 빌드 결과물까지 통합적으로 관리하여 개발 도중 리소스를 분실하여 시간을 버리는 일이 없도록 하였다-물론 모든 리소스를 SVN에 관리하다 보니 개발 후반부에 SVN이 점차 느려지는 현상이 발생하기도 하였다.
개발 문서의 경우 수정 사항이 발생 할 경우, 해당 수정 사항을 반영한 문서를 바로 커밋Commit 하여 팀원들이 항상 최신의 문서에 접근 할 수 있도록 하였다. SVN의 기록Log 기능과 문서 상에 수정 이력, 그리고 해당 이슈Issue에 기록을 통하여 수정 사항에 대해서 팀원들이 놓치지 않도록 주의를 기울였다.
그래픽 리소스에 대해서도 기존 개인 작업 폴더 - 공유 폴더로 유지 되면서 버전관리 및 리소스 관리가 되지 않았던 부분을 SVN에 통합시키므로써, 리소스 분실, 중복, 과거 내용을 덮어 씌우는 사고 발생이 줄어들었으며, 이는 프로젝트 수행 시간을 절약하는데 많은 역할을 하였다.
SVN을 관리하는 담당자가 배정되어, 팀원들에 대한 SVN 이용법 교육, 사용자 문제 해결, SVN 저장소 관리 등의 업무를 진행하였으며, SVN 이용에 대한 가이드라인을 만들어 공유하고, 해당 가이드라인에 맞게 관리 함으로써, 효율적인 업무 진행을 이끌어내었다.
또한 빌드 자동화 시스템을 도입하여, 전날 작업 된 결과물을 바로 다음 날 확인 할 수 있도록 하였다. 게임 디자인 담당이 매일 아침 빌드 된 게임을 테스트 하면서 일반적인 버그 및 실행 오류 등의 문제를 잡아내고, 이를 즉시 처리했기 때문에 프로젝트 후반까지 자잘한 버그로 인하여 고생하는 경우는 거의 존재하지 않았다. 모든 팀원들은 매일 새로운 빌드를 가지고 30분 ~ 1시간씩 이른바 ‘개밥 먹기’에 동원 되어 게임을 테스트 하고 문제 사항을 수정하는 과정을 거쳤다.
빌드 자동화 프로그램으로 유명한 CC.net을 사용했다
프로토타이핑
미니 게임 제작 시의 기본 제작 프로세스는 제안 - 게임 디자인 검수 - 프로토타이핑 - 사내 테스트 - 실 제작의 형태로 진행되었다. 게임 1종 당 보통 1~3개월의 개발 기간이 소요 되었다. 미니 게임에 대한 프로토타이핑은 ‘재미있는 게임’과 ‘재미없는 게임’을 사전에 걸러내는 필터 역할을 충실하게 하였다. 제안서 상 재미있을 것 같은 게임이 막상 구현 시 재미없다는 사실을 사전에 알 수 있는 방법은 빠른 프로토타이핑 뿐이며, 덕분에 난립하는 제안서 중에서 제대로 된 미니 게임들을 선택하여 게임 내에 포함 시킬 수 있었다.
초기 미니게임 프로토타입 중 하나
잘 되지 못한 부분
일관된 프로젝트 목표 부재
처음 프로젝트가 킥 오프Kick off 될 당시의 제품 목표는 아케이드 업소를 찾는 라이트 유저-게임 소비 시간이 한정적이고 캐주얼 게임을 즐기는 층을 시장 목표로 잡고 이에 어필 할 수 있는 제품을 만드는 것이었다. 시장 목표의 특성으로 여성과 어린이, 그리고 복잡한 게임에 익숙하지 않고 경쟁보다는 즐거움을 소비하는 것으로 자체 리서치 결과 판단되었고, 이에 대한 팀원들의 이해와 공유가 이뤄진 상태에서 프로젝트는 진행되고 있었다.
파국이 찾아온 것은 게임 개발이 어느 정도 완료된 이후 제품에 대한 포커스 그룹 테스트Focus Group Test 가 진행된 이후였다. 테스트 결과 주요 항목 평균이 10점 만점에 7~8점을 기록했기 때문에 최종 발매 결정에 별 다른 장애가 없을 것으로 예상되었지만, 경영진을 포함한 프로젝트 팀장은 갑작스럽게 프로젝트 목표를 라이트 유저 및 헤비 유저(대전 액션 등의 게임을 즐기는 하드 코어 유저) 성향의 소비자들이 사용할 수 있는 게임으로 일방적으로 변경 통보를 내렸다. 이미 제품의 개발이 막바지에 다다른 상황에서 있을 수 없는 일이지만, 결국 무리한 설계 변경과 게임 난이도 변경을 통하여 게임은 애초의 기획과는 다르게 색이 불분명한 게임이 되어버리고 말았다-게임은 지나치게 어려웠지만, 그렇다고 이를 지속적으로 즐기기 위한 도전 욕구를 불러일으키는 것도 아닌 형태가 되었고, 애초 프로젝트 목표였던 라이트 유저에게는 다가가기 힘든, 그리고 헤비 유저들에게는 난이도만 높고 따분한 게임이 되어버린 것이다.
비 상식적인 일정과 몰아붙이기 식 팀 관리
프로젝트를 시작 할 때 제안서 상에 의하면 개발 예상 기간, 개발 예산, 소요 인력, 예상 매출액 등이 존재했지만, 사실 어느 항목 하나 제대로 된 ‘근거 자료’는 전무했다. 때문에 말도 안되는 개발 일정이 팀원들에게 떨어졌다. 초기 개발 예상 기간은 실제 실무자들의 예측에 비하여 반 이상 짧게 잡혀 있었고, 이에 대한 어필을 하더라도, 개발 팀장은 개발 기간 연장은 관행인 것 마냥 이 문제를 대수롭지 않게 생각하고 있었다-결국 이런 태도가 경영진의 프로젝트에 대한 불신을 부채질 한 원인 중 하나였다.
이런 책이 괜히 있는 것은 아니다 - 맨먼스 미신
제품 개발을 위한 연구/개발 활동이 일정상 불가능 한 상황에서 어처구니 없는 개발 스펙을 요구하는 일도 비일비재 했다-그리고 그러한 요구 사항은 거의 대부분 팀과 프로젝트의 상태를 관리해야 하는 팀장에게서 나왔다. 개발 팀의 역량, 현재 상태, 필요 자원 등에 대한 고려는 일절 무시 한 체, 안되면 말지 식의 제안이 나오는 경우도 허다 했다. 개발 팀은 현실적인 개발 스펙 제시 및 이에 대한 수정 일정을 제시하고 이를 철저하게 지키는 데 역량을 집중했다. 때문에 최소한 ‘본인 입에서 나온 일정’은 지킬 수 있었다.
프로젝트 관리 능력 부재 및 프로젝트 관리자 부재
평균 10여명이 안 되는 팀 안에 팀장과 부팀장이 존재했지만, 정작 팀과 프로젝트를 관리하는 사람은 존재하지 않았다는 것은 프로젝트를 절음발이로 만든 가장 큰 원인이었다. 전체적인 프로젝트 관리 및 조율은 실무진이었던 각 파트 대표-프로그램, 그래픽, 게임 디자인-가 모여 조율하고 조정함으로써 이루어졌다. 덕분에 개발 팀 내 단합은 좋아졌지만, 최종적으로 팀장은 팀 외부에서 겉도는 좋지 않은 모양새가 되어버렸다는 점은 그리 좋은 평가를 내릴 수 없을 것이다.
프로젝트 관리 능력이 없는 사람이 프로젝트 관리자로 있는 것은 팀원들에게는 엄청난 고역이다. 해당 팀장은 종종 프로젝트의 현재 상황에 대한 정보를 놓치고 있었으며 때문에 이미 처리된 이슈에 대해서 다시 언급한다거나, 이미 논의된 사항을 수시로 번복하는 일이 잦았다. 때문에 각 팀원들과 프로젝트에 대해서 부딪치는 경우가 더욱 빈번하게 발생 할 수 밖에 없었고, 이럴 때 마다 프로젝트는 일관성을 잃고 엉뚱한 방향으로 지그재그로 움직여왔던 것이다. 때문에 팀원들은 팀장을 불신하게 되고, 팀장은 또 팀원들을 불신하는 악순환의 반복이었다.
위기 관리 능력 부재
어떠한 프로젝트든 마찬가지로 위험Risk은 존재하는 법이며, 이 프로젝트에서도 각종 위험 요소들이 존재하고 있었다. 가장 큰 문제는 프로젝트에 대한 경영진의 신뢰 여부였는데, 사실상 경영진과 팀원들의 중간 다리 역할을 하고 있어야 할 팀장의 커뮤니케이션 능력이 상당 부분 모자랐기 때문에 프로젝트는 항상 살얼음판을 걷는 형국이었다-최종적으로 베타 릴리즈에서 프로젝트가 잠정 중단 된 것도 같은 맥락의 일이었다. 나중에 확인 된 일이었지만, 경영진이 알고 있는 프로젝트와 개발 팀이 알고 있는 프로젝트는 전혀 다른 종류의 것이었다.
인적자원과 관련한 문제도 존재했다. 프로그램 팀장의 병역특례와 관련하여 훈련소 입소 문제는 프로젝트 시작 전부터 확인 된 문제였고 이를 회피 할 수 있는 상황이었음에도 불구하고, 아무런 조치를 취하지 않은 체 가장 중요한 프로젝트 막바지에 이르러 입소하게 하는 상황을 자초했다-덕분에 프로젝트는 프로그램 팀장의 군사 훈련 기간인 한 달 동안 진척 없이 표류하기만 했다.
잘못 설정한 프로젝트 진행 기간으로 인하여 제작 필수 인력을 타 팀에 빼앗기는 상황이 발생하기도 했다. 팀장이 무리한 일정을 가지고 다른 팀과 인력 교류를 약속했다가, 역시 프로젝트 막바지에 해당 인력이 팀을 옮기는 상황이 발생하였는데도, 이에 대한 저지, 혹은 대체 인력 충원 등의 대책은 나오지 않았고 프로젝트는 그냥 속행 되었다.
결과
프로젝트는 정상적으로 진행되지 않았고, 사실상 실패(게임 업계에서 ‘잠정 중단’은 ‘영구 폐기’와 유의어)하였다. 팀 내/외에서 많은 문제점들이 있었기 때문에 당연한 결과였을지 모르지만, 덕분에 프로젝트 관리와 리더십에 대한 반면교사가 될 수 있었다고 생각한다. 프로젝트의 목표 설정, 관리, 리더십에 관하여 성찰을 하는 데 더 없는 기회가 되었다는 것은 이 성공하지 못한 프로젝트가 가진 가장 큰 성공이 아닐까.
어떠한 프로젝트든 마찬가지로 위험Risk은 존재하는 법이며, 이 프로젝트에서도 각종 위험 요소들이 존재하고 있었다. 가장 큰 문제는 프로젝트에 대한 경영진의 신뢰 여부였는데, 사실상 경영진과 팀원들의 중간 다리 역할을 하고 있어야 할 팀장의 커뮤니케이션 능력이 상당 부분 모자랐기 때문에 프로젝트는 항상 살얼음판을 걷는 형국이었다-최종적으로 베타 릴리즈에서 프로젝트가 잠정 중단 된 것도 같은 맥락의 일이었다. 나중에 확인 된 일이었지만, 경영진이 알고 있는 프로젝트와 개발 팀이 알고 있는 프로젝트는 전혀 다른 종류의 것이었다.
인적자원과 관련한 문제도 존재했다. 프로그램 팀장의 병역특례와 관련하여 훈련소 입소 문제는 프로젝트 시작 전부터 확인 된 문제였고 이를 회피 할 수 있는 상황이었음에도 불구하고, 아무런 조치를 취하지 않은 체 가장 중요한 프로젝트 막바지에 이르러 입소하게 하는 상황을 자초했다-덕분에 프로젝트는 프로그램 팀장의 군사 훈련 기간인 한 달 동안 진척 없이 표류하기만 했다.
잘못 설정한 프로젝트 진행 기간으로 인하여 제작 필수 인력을 타 팀에 빼앗기는 상황이 발생하기도 했다. 팀장이 무리한 일정을 가지고 다른 팀과 인력 교류를 약속했다가, 역시 프로젝트 막바지에 해당 인력이 팀을 옮기는 상황이 발생하였는데도, 이에 대한 저지, 혹은 대체 인력 충원 등의 대책은 나오지 않았고 프로젝트는 그냥 속행 되었다.
결과
Posted by Irene
