2007. 1. 16. 00:01
[생각하기]
< 본 글은 전파명색관(http://rakugaki.cafe24.com)을 운영하고 계신 Loppa님의 글입니다! >
동인게임이 실패하는 이유 (4)
4. 프로젝트 관리의 어려움
1부에서, 친구/주변사람이 아닌 신규가입팀원은 컨트롤이 매우 어렵다. 라고 했었죠.
한마디로 관리가 안됩니다. 리더 역할을 맡은 사람은 개발업무보다는 팀 관리 때문에 더 큰 괴로움을 겪습니다.
회사에서 게임을 만든다, 라는 것도 결코 쉬운 일이 아니지만, 프로젝트 관리 측면에서는 동인그룹보다 훨씬 쉽습니다.
동인게임그룹의 팀 운영관리가 훨씬 더 힘든 이유는,
동인활동이 보상이나 댓가가 없는 봉사활동이기 때문입니다.
무보수 자기만족의 행위입니다. 동인게임을 팔아서 수익을 올려보자 !!! 라는 공통목적이 있는 쪽이 차라리 나을지도 모릅니다.
처음부터 "하고싶으니까 해볼래" 라고 시작했으므로, "하기싫어졌으니 그만둘래" 라는 상황도 쉽게 발생합니다.
그러므로, 팀원들의 의욕과 개발동기를 잃지 않도록 하는 테크닉(?)이 늘 중요시됩니다. (이 역할은 주로 리더나 기획자의 몫이 됩니다)
사람마다 동기,목적은 모두 다릅니다. 일치하지 않는 것이 당연합니다.
동상이몽입니다. 같은 프로젝트를 하고 있지만, 각자 서로 딴 생각을 갖고 있습니다.
프로젝트 진행이 자신의 동기, 목적 등과 원치 않는 방향으로 흘러가게 될 경우, 진행하면 할수록 점점 괴로워지므로 오래가지 못하게 됩니다.
4-1. 개발업무 관리 문제
원화가 지망으로 들어왔는데, 인터페이스 도트 찍으라 시킨다거나,
캐릭터 디자인을 원하는 사람에게, 메카닉 디자인을 시킨다거나,
게임시스템디자인을 원하는 사람에게, VN 스크립트 노가다를 시킨다거나,
사운드 분야로 들어왔는데, 번역일을 맡긴다거나,
2D 그래피커에게 3D 를 요구한다거나,
시나리오 지망으로 들어왔더니, 웹 디자인을 시킨다거나,
등등등등 .... 사례는 아주 다양합니다.
뭐, 이런 것들은 동인게임 뿐 아니라 업계에서도 자주 있는 일입니다만. (흔히 '낚시'라고 합니다)
회사에서라면 "뭐, 내키지 않지만 어쩔 수 없지"하고 그냥 할 수도 있는 일이지만,
동인게임은 호락호락하게 넘어가기 힘들어집니다. 노예근성이 박혀있거나, M속성의 인간이라면 모를까..
다재다능하고 뭐든지 다 하고싶어하는 슈퍼맨이 팀원이라면 BEST입니다만, 아직까지 그런 사람을 본 적이 없습니다.
대부분의 팀원은 자기 하고싶은 것만 하려고 한다!! 라고 가정하는 것이 좋습니다. 다들 하기싫은 거 억지로 하려고 참가하는 게 아니니까요.
결국 누군가는 하고싶지 않은 일도 도맡아서 할 필요가 있는데, 대부분의 경우 이것은 리더의 몫이 됩니다.
하기싫은 일을 서로 떠넘기는 사태가 발생한 시점에서 이미 프로젝트는 실패해가고 있는 겁니다.
가장 이상적인 것은 자기가 서로 하겠다고 나서는 분위기지만, 현실과는 거리가 먼 이상론인 것이죠.
동인팀은 무보수 봉사활동이기 때문에 수직구조의 조직이 될 수 없습니다. 즉, "명령하달" 자체가 아예 불가능합니다.
<상사:부하>의 관계도 아니고, <독재왕:신하>의 관계도 아닙니다. 리더라고 해서 팀원에게 명령할 수 있는 권한 따위는 애당초 존재하지 않습니다.
갓 가입한 신입회원이 아닌 한, 지시,명령에 순순히 따라줄 팀원도 그렇게 많지 않습니다.
<책임/권한>의 경계가 모호하며, <권리/의무>를 주장,강요할 수 없습니다.
프로젝트 실패했다고 리더가 손가락을 잘라야 할 필요도 없으며, 리더가 프로젝트를 떡주무르듯 마음대로 할 수 있는 것도 아닙니다.
얼핏 무능무력해보이지만, 그럼에도 불구하고 프로젝트를 이끌어갈 '리더'는 없어서는 안됩니다.
이런 점들은 동인게임개발을 매우 어렵게 만듭니다.
그래서 보통은 마음편하게 대할 수 있는 친한 사람들끼리 그룹을 구성해서 스타트하는 것이 일반적입니다.
(하지만 보통은 거의 실패합니다 ^^; )
팀원들의 작업상황을 감시(?)하는 것은 매우 어려운 일이어서, 결국 팀원의 자율에 맡길 수 밖에 없게 됩니다.
(별바람 교수님의 스토킹 이론도 나름대로 일리있습니다... 충분히 연구가치가 있습니다)
팀원이 각자 자기 맡은 역할의 작업을 충실히 해준다면 좋겠지만 현실은 그렇게 만만하지 않습니다.
피치못할 개인사정으로 작업진행이 어려워졌을 수도 있고,
딩가딩가 놀다가 이런저런 핑계대는 팀원도 있고,
정해진 분량에 턱없이 못미치는 결과물을 제출하는 팀원도 있고,
난데없이 연락끊고 잠적하는 팀원도 있고,
아무튼, 이런저런 이유로 작업결과물이 나오지 않는 상황이 아주 흔하게 발생합니다.
강압적으로 야단치거나 하는 것도 무리. 수직구조의 조직이 아니므로, 강제성을 띤 구속이 불가능합니다.
이런 조건 하에, 프로도 잘 안지키는 일정을 아마추어가 스케쥴대로 움직여줄 리 없습니다.
스케쥴(?) 관리가 어려워짐으로써, [ 기간 연장 - 의욕저하 - 작업진행 부진 - 또 기간연장 ] 등의 악순환이 이어집니다.
팀원의 의욕을 꺾는 행위 1호.
개발도중에 기획을 엎어버려서 액션이 슈팅이 된다거나 하는 경우는 두말할 것도 없고, 사소한 내용변경이라도 팀원에겐 스트레스로 작용합니다.
기획자의 경험부족에 의한 개념미탑재, 단순한 변덕 (최악), 짧은 기획기간으로 인한 고민부족 등이 대부분의 원인.
비젼이나 계획성이 의심되어 불신감이 싹트고 인간관계가 악화되기도 합니다.
회사에서도 자주 있는 일이지만 (상부층, 타 부서의 외압 등) 이런 프로젝트가 잘 마무리되는 경우는 드뭅니다.
팀원의 의욕을 꺾는 행위 2호.
남들이 하는 작업상황을 감시하거나 결과물 확인이 극히 힘든 동인게임 개발에서는 없을 수가 없으면서도, 섣불리 요구하기 난감한 것이 바로 리테이크입니다.
애당초, 기획자가 개념이 없어서 사양서가 애매하게 작성된다거나 하는 문제도 있습니다만. (가령, "중세풍의 갑옷디자인" 이라던가...)
"기획의도와 다르다" 라던가, "생각했던 것과 이미지가 다르다" 등의 시시콜콜한 태클은 매우 흔하게 발생합니다.
아무리 상세하게 잘만든 사양서라 하더라도, 사소한 수정사항은 발생하기 마련입니다.
완성단계에 있는 작업을 '리테이크' 한마디로 엎어버리거나, 없었던 것으로 만드는 일은 쉬운 일입니다.
하지만 돈받고 일하는 회사에서도 팀원의 의욕을 대폭 꺾어버리는 무시무시한 정신적 피해를 입힙니다. (경험많은 개발자는 해탈의 경지에 도달합니다)
회사도 아닌데 연속적인 리테이크를 견뎌가며 근성있게 작업해줄 팀원은 많지 않습니다.
정리
쓸데없이 긴 시리즈도, 다음편이 마지막이 되겠군요.
next 4-2. 팀 관리의 문제
#Loppa
