게임 프로듀서의 역할

프로듀서의 역할은 일단 회사에 따라 다르지만 일반적인 역할로 "프로젝트의 관리"가 가장 크다고 할 수 있다. 내가 한국에서

일했던 경험을 보자면 게임 기획이라는 직책아래 게임 디자이너의 역할과 프로듀서, 어떨 때는 프로젝트 매니저와 마케팅

심지어는 운영의 역할을 동시에 진행했었다. 

가장 큰 이유는 단지 기획자가 게임과 개발에 관해서 가장 잘 알고 있기 때문이었다. 개발 과정을 잘모르는 사장님에게

일반적인 언어로 설명할 수 있고, 팀 내의 사람들과 커뮤니케이션을 하고, 게이머의 입장에서 그들이 원하는 것을 찾아내고,

그들의 요구를 맞추어 줄 수 있는 인물. 기본적으로 기획자라는 이름으로 갖추어야 할 능력이기 때문에 그리고 게임의 기획과

앞으로의 구상에 가장 적합한 사람은 바로 늘 팀원과 커뮤니케이션을 숨쉬듯이 해야 하고, 게임 디자인을 담당하고 있으며,

게임에 대해서는 그래도 잘 알고, 언변과 글빨이 뒤어난 사람. 바로 대부분 이런 사람이 팀에서 기획자 혹은 기획 팀장으로

있기 때문이다. 나도 그 예외일 수는 없었다.

그래서인지 맨 처음 외국 회사에서 일할 때 가장 힘들었던 것이 바로 "프로듀서의 역할"이라는 부분이었다. 게임 디자이너가

따로 있고, 개발 초기인 시점에서 프로듀서가 하는 역할은 무엇인가? 물론 프로듀서도 인력이 딸리면 게임 디자인에 참여하기도

한다.(지금 나도 그렇게 참여는 하고 있다) 그렇지만 결국 문서를 완성하는 사람은 게임 디자이너이다. 프로듀서가 아니다.

어떤 회사는 프로젝트 매니저가 따로 있다. 그럼 프로젝트 매니징도 다른 사람이 하면 프로듀서는 노는 사람인가?라는

생각마저 들었다. 왜냐하면 그런 일을 빼고 무슨 일을 해야 할지 전혀 감이 오지 않았기 때문이다.

기본적으로 프로듀서는 모든 일에 관여를 한다. 그렇지만 관여하는 깊이는 게임 디자이너나 크리에이티브 디렉터, 프로젝트

매니저, 개발 디렉터, 아트 디렉터가 있는 상황에서 깊지는 않다. 그렇지만 중요한 항목의 결정은 모두 프로듀서의 몫이 된다.

현재 일하는 회사에서 프로듀서의 역할은 이러한 각 디렉터들의 커뮤니케이션을 담당하게 된다. 즉 그들의 연락병 노릇이다.

그렇지만 프로듀서냐, 어소시에이트 프로듀서냐 어시스턴트 프로듀서냐에 따라 그 역할은 극명하게 나뉜다.

먼저 어시스턴트 프로듀서는 말 그대로 프로듀서의 조수 역할이다. 프로듀서의 시간을 많이 잡아 먹게 되는 단순 작업을

담당하고, 프로듀서가 시간을 아겨서 더욱 중요한 일에 집중할 수 있도록 보좌하는 일이다. 예를 들자면 프로젝트에 관련하는

문서의 작성, 검토, 수정을 담당하고 완성본을 프로듀서에게 제출하게 된다. 

어시스턴트가 프로듀서의 전반적인 업무의 보좌를 담당한다면, 어소시에이트 프로듀서는 그 중 전문적인 한 부분을 맡아서

간단한 프로듀서의 확인 과정만을 거친 뒤 책임을 지고 일을 진행하는 역할이다. 예를 들자면 프로젝트 매니저의 역할을

맞게 된다.

프로듀서는 전반적으로 모든 것을 관할하지만, 중요한 기술은 자신이 가진 리소스를 어떻게 활용해서 자신의 시간을 중요한

안건에 집중할 것인가를 결정하는 것이다. 기본적으로 게임 디자이너의 문서를 검토하고, 이것이 개발팀과 아트 팀에게 잘

전달이 되었는지, 그리고 이들의 문제점은 없는지, 문제점이 있다면 왜 그런 문제가 발생하는 지, 그것을 해결하기 위해서는

어떤 프로세스를 만들지, 그리고 일정에 무슨 영향을 미치는 지를 고려한다. 

조금 더 예를 들어서 설명을 해 보자.
프로듀서는 우선 게임 디자인 회의에서 게임 디자이너의 의견을 수렴하고 그 내용을 바탕으로 그 기능을 집어 넣을 지를

결정한다. 어소시에이트 프로듀서는 이에 따라 리소스를 확인하고 일정에 어떤 영향을 미칠 지 의견을 제시한다. 어시스턴트

프로듀서는 만약 그 기획이 게임에 채용이 된 경우, 여기에 필요한 추가적인 프리젠테이션의 문서나 프로듀서가 지시하는

추가 문서를 작업한다. 이 문서는 게임 디자인 문서나 기술 디자인 문서를 바탕으로 하기도 한다.

프로듀서는 단지 스타 개발자가 아니다. 개발자 대표로 대접을 받는 것은 그가 모든 중요 사항에 대한 결정권자이기 때문이고

그래서 프로젝트가 성공할 경우 스포트라이트를 받게 되는 것이다. 적절한 책임에 따른 보상의 결과이다. 물론 우리 나라의 경우,

대부분 사장님이 스포트 라이트를 받지만 ..

 

EA의 경우는 조금 다른 시스템으로 되어 있다. 기본적으로 EA의 모든 어시스턴트 프로듀서는 게임 디자이너이다. 그리고

어소시에이트는 리드 게임디자이너의 역할만 한다. 그리고 프로듀서는 이들을 총괄하고 리소스 관리와 마케팅, 아웃 소싱 등

좀 더 하이 레벨의 커뮤니케이션을 담당한다. 그리고 실제 개발은 개발 디렉터가 진행을 하고 프로젝트 매니저가 따로 있어서

매일 단위로 팀의 개발 상황을 업 데이트한다. 때문에 EA는 늘 프로듀서와 개발 디렉터 간의 충돌이 있다. 이를 통해서 EA는

이상(프로듀서)과 현실(개발 디랙터)의 절충을 도모한다. 반드시 이 시스템이 좋다는 것은 아니다. 그러나 충분히 어느 정도는

효과가 있다고는 본다. 다만 EA의 시스템은 스타 개발자의 존재를 인정하지 않는다. 그것을 위해서 팀 간의 역할을 분담하고

한 사람에게 권력을 분산하기 보다는 나누어서 일을 시켜서 팀의 주인 정신을 강조한다. 그러나 반면 개인의 주인 정신은 약해져서 출중한 사람들은 어느 정도 시간이 지나면 다 EA를 떠난다. 덕택에 개발 디렉터가 프로젝트 중간에 빠지더라도 프로젝트의

피해는 최소한에 그치고 그대로 진행할 수 있는 시스템이다.

이렇게 프로듀서의 역할을 나름대로 정의는 해 보았지만 아직도 나는 초보 프로듀서다. 게임 기획자, 온갖 역할을 다 짬뽕해서

해온 역할은 경력 10년의 나름대로 베테랑이지만 프로듀서, 전문적인 커뮤니케이션과 결정권자의 역할,은 아직 초보인 셈.

물론 전에도 하던거니 어느 정도는 하고 있지만, 요즘 드는 고민은 내가 과연 맞느냐하는 것이다. 내 위의 26년 경력의 화려한

시니어 프로듀서를 옆에서 보고 배우고는 있지만... 아마도 이 역할에 대한 고찰은 또 나를 지속적으로 괴롭힐 것이다. 마치 

우리나라에서 게임 기획자의 역할과 할 일은 무엇이고 어떻게 해야 하는 가를 늘 고민하게 만든 것 처럼... 
  
이글루스 가든 - 게임 기획자로 성공하기

by allen | 2008/04/23 12:27 | Game development | 트랙백 | 덧글(0)

이번에 지른 블루투스 주변기기들...

블루투스 장치들을 피씨에서 쓸 수 있게 해주는 동글입니다. 16500원.


ASUS것이 저렴하고 안정적이라고 하네요.


블루투스 MS 마우스 입니다.
감도도 좋고 뒤로가기 버튼이 있어 편하네요.
디자인도 고급스럽습니다. 가격은 35000원 정도...



자브라 블루투스 헤드셋입니다.
한쪽만 연결할수도 있고 음악들을때는 양쪽으로 연결할 수 있습니다.
미국에 있을때 7만5천원 정도에 산 것인데 국내에 출시되었는지는 모르겠습니다.
다른 블루투스 헤드셋에 비해서 음악들을때 음질이 아주 좋습니다.

by allen | 2008/03/29 17:57 | Allen's daily life | 트랙백 | 덧글(0)

PM(프로젝트 매니저)의 역할

PM(프로젝트 매니저)의 역할 프로젝트 관리

2006/01/24 02:07

복사 http://blog.naver.com/webpd3/70001178535

프로젝트에서 리더인 프로젝트 매니저(Project Manager)에 대해서...

 

PM의 역할은 프로젝트팀의 의욕과 유효성을 최대한 최상으로 끌어 올리고

이런 기조를 과업이 완수될 때까지 유지하는 것이다.

 

분석지향적이며 책임분야내의 각 업무에 대해 세밀한 사항까지 파악하고 있는

전문가인 기능부문 관리자(Functional Manager)와 비교하면,

PM은 광범위한 지식과 경험을 배경으로 하는 제너럴리스트(generalist)라 할 수 있다.

FM은 직접적이고 기술상의 감독자인 반면 PM은 촉진자이자, 매개자 역할을 한다.

그리므로, PM은 지식을 직접 적용하려고 시도하는 대신에 전문적인 지식을 갖춘 다양한 인력을,

이를 필요로 하는 인력과 연결을 짓고 협력을 촉진하는 것이 중요하다.

 

FM은 프로젝트 요원의 선정 및 사용기술의 선택에 영향을 미친다 하더라도 프로젝트 관리는

어디까지나 PM의 몫이다.

 

PM은 프로젝트의 조직화, 충원, 예산수립, 지휘, 계획 및 통제 등의 역할을 한다.

 

1. 모 기업에 대한 책임

   모 기업, 모 조직에 대해서 PM은 자원의 적절한 보전, 프로젝트와 관련하여

   시의적절한 정확한 커뮤니케이션, 용의주도한 프로젝트 관리의 책임을 가진다.

   (상위경영층은 장래 발생할 가능성이 있는 문제에 대해 경고를 미리 받아야 한다.)

 

2. 프로젝트에 대한 책임

   프로젝트와 관련된 여러 이해당사자들로부터의 상반되는 요구에도

   불구하고 프로젝트의 본래의 모습을 유지, 보전하는 것이다.

   PM은 정시에, 예산한도 내에서, 규격에 맞춰 프로젝트를 완수해야 하는 책임을

   조금도 완화해 주지 않는다는 사실을 주지해야 한다.

 

3. 프로젝트 팀원에 대한 책임

   PM은 프로젝트 팀을 위해 일해 온 팀원의 장래에 대해 관심을 갖고 살펴 보아야 한다.




PM(프로젝트 매니저)의 주요 임무 프로젝트 관리

2006/01/25 23:27

복사 http://blog.naver.com/webpd3/70001233833

1. 적정 자원의 확보

   PM은 자원간에 존재하는 교환문제를 잘 이해할 필요가 있다.

   숙련기계공은 범용 기를 다뤄 과업을 끝낼 수 있지만 초보 미숙련공은 그렇지 못하다.

   외부에 하청을 주는 것은 부족한 생산능력이나 기술을 보완해 주기도 하지만 일정상의

   차질을 가져오기도 한다. 생각지도 못한 특수한 자원을 요구하는 상황도 벌어진다.

 

2. 인력확보와 동기부여

    프로젝트에 필요한 인원은 어디선가 차용되어 와야만 한다는 사실이

    PM에게 있어서는 가장 큰 문제이다.

    프로젝트 팀원으로 바람직한 사람은 프로젝트 과업에 내재하는 도전과

    다양성에 자연히 이끌리는 사람이기 때문이다.

    팀원이 프로젝트에서 느끼는 도전과 자아성취외에는  별다른 동기부여를

    PM이 느끼게 하기에는 힘들다. 

 

3. 장애 극복

   프로젝트의 특성은 그 독특성에 있다. 그러므로 PM에게는 위기가 연속적으로 닥치고

   이를 늘 슬기롭게 극복해 나가야 할 필요가 있다.

 

4. 프로젝트 목표간의 교환문제(Trade-off) 해결

   PM에게는 비용, 시간, 성과 등 프로젝트 목표 사이에 발생하는 갈등 및 교횐문제를 해결해야 될

   의무가 있다.

 

5. 실패의 위험 그리고 실패에 대한 두려움 극복

 

6. 광범위한 의사소통

   프로젝트를 운영하는 것은 외부인, 최고경영층, 기능부서, 고객, 심지어는 프로젝트 팀원들에게

   프로젝트를 지속적으로 이해시키고 설명하는 일들을 필요로 한다.

   PM은 외부세계와 프로젝트 사이의 연결 핀이다.

 

   * 의사소통 임무를 성공적으로 완수하기 위해 PM이 이해해야 할 3가지

   1) PM은 그 프로젝트가 왜 있게 되었는지? 즉 그 프로젝트의 의도를 충분히 알아야 한다.

   2) PM은 최고경영층의 지원을 획득하는 것이 핵심적이다.  

   3) PM은 공고한 정보망을 구축하고, 유지하여야 한다



PM(프로젝트 관리자) 선정시 고려요인 프로젝트 관리

2006/01/25 23:59

복사 http://blog.naver.com/webpd3/70001234624

1. 신뢰성

 1) 기술적인 면에서의 신뢰성

     프로젝트 기술에 대해서 상위 경영층에게 설명할 수 있어야 하고 발주자의 기술상

     필요(Needs)나 희망사항을 프로젝트 팀에게 중계할 수 있어야 한다.

  2) 관리적인 면에서의 신뢰성

      프로젝트의 모든 관계자(팀, 경영진, 기능부서, 의뢰인)들의 이해관계르 다른 상대방

      관계자에게 대변해야 하는 책임을 지고 있다.

     

 

2. 감각

    PM은 기술상의 문제를 감지하는 센스를 가져야 한다.

    PM은 개인감정과는 상관없이 협조하도록, 그리고 개인적인 호 불호를 개입시키지 말고

    오로지 프로젝트 목표의 성취에 집중하도록 사람들을 설득하여야 한다.

 

3. 리더쉽

    PM은 팀원들의 강점을 부각시키며 적극적으로 활용하고 약점은 덮어 주며,

    언제 자유를 주고 또 언제 의사를 표시하고, 언제 침묵을 지켜야 할지를 알아야 할 것이다.

    성숙도가 낮은 부하들은 인관관계 지향적이기 보다는 과업지향적으로 다루고,

    성숙도가 높은 부하들에게는 인간관계에 대해서 큰 관심을 보일 필요가 없으며,

    과업의 수행을 엄격하게 감독할 필요가 없다.

 

    *PM은 실무자도 아니고, 관리자도 아니고 리더가 되어야 한다.



성공적인 프로젝트 관리(CEO를 위한) 프로젝트 관리

2006/02/07 22:03

복사 http://blog.naver.com/webpd3/70001568655

프로젝트 관리가 새로이 모든 경영자에게 요구되는 핵심역량 가운데 핵심이 되고 있다.

 

모든 조직은 정체하면 그 생명력을 잃는다. 그러므로 부단히 변신하고 변화해야 한다.

그런데 문제는 변화의 관리에 있다.

멋있는 말로 하자면 변화경영관리라 할 수 있겠다.

 

 

변신 실패의 근본적인 두가지 원인은 무엇일까?

첫째. 변화를 시도하기 위해 무엇을 해야 할지 몰라서 실패하게 된다.

두번째. 변화를 어떻게 주도해야 할 지 몰라서 실패하게 된다.

 

프로젝트 관리의 주요 원칙

 

1) 프로젝트 선정은 전략의 큰 테두리 안에서 이루어져야 한다.

 

2) 단계 별 접근을 시도하라.

 

3) 이해관계자를 참여시켜라.

 

4) 계획에 대비하여 실적을 지속적으로 점검하라.

 

5) 진도를 검토하는 회합도 공식화되어야 한다.

 

6) 프로젝트의 성패요인에 늘 유의하라.

 

2)=> 프로젝트의 마지막 즉 결과에 대해서 큰 그림을 그리고 있어야 한다.

프로젝트는 기본적으로 다음의 단계를 거치게 된다.

제안 - 아이디어 또는 필요성 확인

기초조사 - 가능한 소요자원과 솔루션에 대한 개략적 검토

상세조사 - 여러 대안에 대한 타당성 검토와 선택된 솔루션 정의

개발 및 검사 - 솔루션 구축

시험실행 - 실제 상황에서 솔루션 시험 적용

운영 및 종료 - 실무에의 적용 및 프로젝트 종결

 

프로젝트 초기 단계에 중점을 둔다고 함은 최종 결과가 조금이라도 실제적으로 형성되기

전인 조사 단계에서 프로젝트 전체 기간의 30~50%에 해당하는 시간을 쓴다는 말이다.

초기단계에서 철저히 준비를 하는 경우 마지막 실용화 단계가 상당히 단축된다는 사싫은

여러 연구에서 실증된 바 있다.

초기에 옳은 결정을 내리면, 프로젝트 기간을 절반으로 줄일 수도 있고, 비용도 대폭 절감할 수 있다.

 

3) => 이해관계자라면 프로젝트에 개입되거나, 프로젝트로 인한 영향을 받게 되는 사람을 일컫는다. 프로젝트의 결과물을 활용하게 될 사용자나 고객과 같은 이해 당사자를 관여시키면 프로젝트

수행 단계마다 결과물의 가치를 높일 수 있다.

일찌감치 이들을 개입시키면 변화의 강한 동력을 제공하지만, 이들을 무시하면 실패를 자초하게

된다. (광범위한 이해관계자를 참여시키라.)

 

프로젝트 팀원 사이의 팀웍과 부단한 헌신이 프로젝트가 수행되는 기간 내에 일관되게 유지되도록

노력하는 일도 중요하다.

 

5) => 첫째, 회의의 성과에 기여할 수 있는 사람만으로 회합 참석 대상자를 국한하라.

둘째, 보고와 관련한 기준이 정해져 있어야 한다.

셌째, 보고회의는 정기적으로 열어야 한다.

실적 점검을 통해 통제가 제대로 이루어지려면 프로젝트 매니저에게 책임도 주어지고 권한도 주어져야 한다.

 

6) => 조직의 성공은 프로젝트를 얼마나 효율적으로, 또 효과적으로 관리할 수 있는가에 달려 있다.

 리스크는 무시하는 것이 아니라  이를 인정하고 적극적으로 관리해야 한다.

개별 부서 관점에서의 최적화는 진정한 최적화가 아니다. 기업전체 관점에서 사고가 이루어져야 한다.

 

고위 경영자가의 아이디어라도 그리 좋지 않으면 다른 것과 마찬가지로 검토되어야 한다.

 

by allen | 2008/03/28 17:56 | Project management | 트랙백 | 덧글(0)

VTune 사용법

 
초간단 VTune 세팅법 #
프로젝트설정에서 다음을 확인한다.
- 프로젝트/속성/CC++/일반/디버깅정보형식 -> 프로그램 데이터베이스(/Zi) (/Zi이상이면 된다.)
- 프로젝트/속성/링커/디버깅/디버그정보생성 -> 예(/DEBUG)
- 프로젝트/속성/링커/디버깅/프로그램데이터베이스파일생성 -> $(?OutDir)/$(targetName).pdb
- 프로젝트/속성/링커/명령줄 -> /fixed:no 를 추가



VTune 사용법 #


VTune 돌리기위한 준비


pdb생성 - VTune에서 함수이름을 알아내기 위해서 pdb가 필요하다.
release 프로젝트에서 pbd생성
프로젝트/속성/CC++/일반/디버깅정보형식 -> 프로그램 데이터벵스(/Zi)
프로젝트/속성/링커/디버깅/디버그정보생성 -> 예(/DEBUG)
프로젝트/속성/링커/디버깅/프로그램데이터베이스파일생성 -> $(?OutDir)/$(targetName).pdb


debug 프로젝트는 이미 위의 것들이 설정되어 있다.
하지만 debug설정으로 profile할 일은 없겠지.



라이브러리 경로 및 이름 확인
프로젝트/속성/링커/입력/추가종속성 -> 입력될라이브러리들이 VTune을 위해서 컴파일 된것인지 확인
프로젝트/속성/링커/일반/추가라이브러리디렉토리 -> 라이브러리경로가 VTune을 위한 라이브러리가 존재하는 곳인지 확인



링커 옵션
프로젝트/속성/링커/명령줄 -> /fixed:no 를 추가



참고
mk:@MSITStore:?C:\Program%20Files\Intel\VTune\Help\SymbolInfo.chm::/Micorsoft__Developer_Studio_7.0.htm



측정종류 3가지
- sampling
: 모든 프로세스, 디바이스드라이버, 시스템 모듈들의 이벤트들을 측정한다. (별로 쓸일 없을듯, '이벤트'에 대한 조사가 더 필요하다.)

- counter monitor
: 특정 응용프로그램과는 관계없이 원하는 시간동안 cpu, memory, network io, 등의 수치를 모니터링한다. (별로 쓸일 없을듯)

- call graph
: 특정 프로그램을 수행해서 함수호출관계그래프를 그리고 함수별 부하를 모니터링한다.



용어설명

callee - 호출당하는 함수
site - 코드덩어리(함수)
call site - callee를 호출하는 지점
self time - 함수에서 call site부분의 실행시간을 제외한 순수 실행시간. 즉, callee의 실행시간을 포함하지 않는다.
total time - 함수의 총 실행시간, 함수의 Self time과 모든 callee들의 Total time의 합과 같다.
edge calls - 이 함수의 외부에서 이 함수를 호출하는 것. 즉 이 함수가 호출대상으로 불려지는 것
edge time - 이 함수의 특정 외부에서 이 함수를 호출한 시간.
이 함수를 호출하는 모든 call site로부터의 edge time을 합한것이 total time이 된다.

wait time - thread가 suspend 되어있을 동안의 시간 (이 값은 정확한 측정값이 아니다.)
self wait time - self time 참조
total wait time - total time 참조


출처 : djmilk님

by allen | 2008/02/29 04:03 | Computer programming | 트랙백 | 덧글(0)

숙소 옆에 있는 카트장

LA로 출장온지도 어언 보름째...
숙소에서 한블럭 거리에 카트장이 있더군요.
회사-집 하는 무료한 일상인지라 동료들과 가봤습니다.


대략 이런 곳입니다.
카트와 트랙이 마련되어 있고 카트는 가드가 있어서 충돌에도 안전합니다.
사람이 꽤 많더군요.
저녁까지 줄이 길어서 오래 기다려야 합니다.
가격은 5분에 7$ ... 꽤 비싸네요 ㅎㄷㄷ


타기전에 카트에 앉아서 한 방 찍었습니다.
이거 찍고 카메라 사망 -_-;; 어찌나 과격하게 탔던지... ㅠ.ㅠ
버켓시트의 효용성을 절실히 알게 되었죠!

by allen | 2008/02/14 12:47 | Allen's daily life | 트랙백 | 덧글(2)

◀ 이전 페이지          다음 페이지 ▶